Technology
MQTT Integration
MQTT is the de-facto message protocol for IoT device-to-cloud communication - lightweight enough for constrained devices, robust enough for unreliable links, and well-supported enough to be a safe long-term choice. We design MQTT-based device firmware, deploy brokers, and integrate MQTT Sparkplug B into industrial OT/IT bridges.
What it is
What MQTT is and when to reach for it.
MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol designed for constrained devices over unreliable networks. Version 3.1.1 is the default for most IoT; version 5.0 adds properties, response topics and improved error semantics for applications that want them. MQTT Sparkplug B is a specification layer on top of MQTT for industrial OT/IT integration, adding structured payloads, state semantics and store-and-forward primitives.
We reach for MQTT when devices need reliable delivery over sometimes-bad links with modest bandwidth overhead. We use HTTPS + REST when the traffic pattern is request/response rather than telemetry-first, and we use CoAP for the rare deeply-constrained cases where MQTT’s TCP requirement is too heavy. Sparkplug B is our default for industrial OT/IT bridging where the source data comes from PLCs and the destination is a historian or SCADA.
Where we use it
MQTT Integration in shipped programs.
- Fleet telemetry pipelines - devices publishing sensor readings and status to AWS IoT Core or Azure IoT Hub over MQTT-TLS
- Industrial OT/IT bridges - Ignition or FactoryTalk pushing PLC data via Sparkplug B to cloud historians and dashboards
- Multi-tenant IoT platforms - ChirpStack or ThingsBoard broker deployments with per-tenant ACLs and shared topic namespaces
Patterns and gotchas
Design decisions that shape whether MQTT scales cleanly.
Design the topic namespace like it is a database schema. Topic hierarchies are the API for everything downstream (subscriptions, ACLs, wildcards, storage keys). We design the namespace up front (typically tenant/site/asset/metric) and stick to it; late-stage topic redesigns are expensive.
QoS 1 is usually right; QoS 2 rarely is. QoS 0 loses messages on link drops; QoS 2 doubles the handshake cost and rarely delivers meaningful reliability improvement over QoS 1 with idempotent handlers. Default to QoS 1 with idempotency at the consumer.
Retained messages are for state, not history. Using retained messages for the last-known-value of a device is what they are designed for; using them for historical telemetry breaks brokers at scale. Historical data goes to a time-series store, not the retained topic space.
Related
How this fits our practices.
MQTT Integration is a lens on our IoT development practice. Adjacent tools and services: cloud software development, industrial automation, LoRaWAN development, PLC/SCADA integration.
Tell us what you’re building.
Send the constraint that worries you most - a latency budget, a power budget, a certification date. We’ll tell you straight whether we’re the right team.