MQTT
ProtocolLightweight publish-subscribe messaging protocol designed for constrained devices — the default choice for IIoT sensor-to-broker communication.
What is MQTT?
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol originally developed by IBM in 1999 for connecting oil pipeline sensors over unreliable satellite links. It became an OASIS standard in 2014 (v3.1.1) and received a major update in 2019 (v5.0). With packet headers as small as 2 bytes, it's designed for constrained devices on networks with limited bandwidth and high latency.
The protocol uses a broker-based architecture: devices (clients) publish messages to topics, and the broker distributes them to all subscribers of that topic. There's no direct device-to-device connection — the broker handles all routing, which makes it simple to add or remove devices without reconfiguring the network.
Why It Matters for Manufacturing
MQTT is the de facto transport layer for IIoT data. When a temperature sensor on a packaging line needs to send readings to a dashboard, historian, or analytics engine, MQTT is almost always the protocol carrying those messages. It's the "M" in the MING stack (Mosquitto + InfluxDB + Node-RED + Grafana) — the most common open-source IIoT architecture.
Three reasons it dominates factory floors:
- Runs on anything — From a Raspberry Pi Zero to a 10,000-device factory. The same Mosquitto broker binary handles both.
- Fire-and-forget simplicity — Sensors publish; consumers subscribe. No handshakes, no connection management, no complex configuration.
- Works on bad networks — Designed for satellite links with 50%+ packet loss. Industrial WiFi and cellular backhaul are easy by comparison.
How It Works
Publish/Subscribe model:
Sensor → publishes to topic "factory/line1/temp" → Broker → delivers to all subscribers
- Topics are hierarchical strings (e.g.,
factory/line1/machine3/vibration). Subscribers can use wildcards:factory/line1/+/vibration(single level) orfactory/#(all subtopics). - QoS levels control delivery guarantees:
- QoS 0: At most once (fire-and-forget, fastest)
- QoS 1: At least once (acknowledged, may duplicate)
- QoS 2: Exactly once (two-phase handshake, slowest)
- Retained messages: The broker stores the last message on each topic. New subscribers immediately get the current value — critical for dashboard displays.
- Last Will and Testament (LWT): Clients register a "will" message that the broker publishes if the client disconnects unexpectedly. Used for device health monitoring.
MQTT 3.1.1 vs 5.0
Most manufacturing deployments still run 3.1.1, but 5.0 adds features that matter at scale:
| Feature | 3.1.1 | 5.0 |
|---|---|---|
| Error reporting | Generic return codes | Detailed reason codes per packet |
| Shared subscriptions | Broker-specific extensions | Standard — load-balance across consumers |
| Session expiry | Persistent or clean only | Configurable TTL per session |
| Message properties | None | Custom key-value metadata headers |
| Flow control | None | Client-specified receive maximum |
| Topic aliases | No | Yes — reduces bandwidth for repeated topics |
Recommendation: Use 5.0 for new deployments. Shared subscriptions and reason codes alone justify the upgrade. 3.1.1 clients can connect to 5.0 brokers — backward compatible.
Protocol Comparison
| Feature | MQTT | OPC-UA | Modbus TCP |
|---|---|---|---|
| Architecture | Pub/sub via broker | Client/server | Client/server (master/slave) |
| Overhead | 2-byte header minimum | Heavy (XML/binary encoding) | 8-byte header |
| Scalability | Thousands of devices via single broker | Point-to-point, complex at scale | 247 devices per network |
| Data model | None (raw payload) | Rich object model, typed data | Register-based, no semantics |
| Security | TLS + username/password | Built-in certificates, encryption | None built-in |
| Best for | Sensor telemetry, event streaming | PLC-to-PLC, SCADA integration | Legacy device polling |
| Firewall friendly | Yes (outbound TCP only) | No (requires inbound port) | Depends on deployment |
MQTT + OPC-UA together: OPC-UA PubSub mode can transport messages over MQTT, combining OPC-UA's rich data model with MQTT's lightweight transport. Sparkplug B adds a standardized payload format to MQTT, solving the "no data model" problem without requiring OPC-UA.
Common Pairings
- Sparkplug B — Payload specification that adds device/metric semantics on top of MQTT. Standardizes how devices report birth/death certificates and metric values. Used heavily in Unified Namespace architectures.
- Mosquitto — The most common open-source MQTT broker. Lightweight, single binary, handles millions of messages/sec.
- HiveMQ / EMQX — Enterprise MQTT brokers with clustering, persistence, and management UIs for large-scale deployments.
- Node-RED — Flow-based tool with native MQTT nodes for wiring up data pipelines. The typical glue layer between MQTT and everything else.
- InfluxDB / TimescaleDB — Time-series databases that ingest MQTT data via Telegraf or direct subscription.
Getting Started
- Install Mosquitto:
docker run -p 1883:1883 eclipse-mosquitto— you have a broker running in seconds. - Publish a test message:
mosquitto_pub -t "test/hello" -m "world"from any machine on the network. - Subscribe:
mosquitto_sub -t "test/#"— see messages arrive in real time. - Connect a sensor: Most IIoT gateways and PLCs with Ethernet support MQTT out of the box. Configure the broker address and topic structure.
- Add a consumer: Point Node-RED, Grafana (via MQTT data source plugin), or your historian at the broker.
The entire MING stack (Mosquitto + InfluxDB + Node-RED + Grafana) can be running in under 30 minutes with Docker Compose.
Tools supporting MQTT
32
