MQTT is the unsung hero of industrial IoT, not because it’s fast, but because it’s remarkably good at not breaking when things go sideways.
Let’s watch this in action. Imagine a sensor on a remote pump reporting its pressure.
{
"timestamp": "2023-10-27T10:30:00Z",
"device_id": "pump-01-alpha",
"metric": "pressure",
"value": 15.2,
"unit": "bar"
}
This tiny JSON payload, published to a topic like site/factory-a/pumps/pump-01-alpha/pressure, is the core of an MQTT exchange. The crucial part isn’t the data itself, but how it gets there and what happens if the network connection flickers.
The problem MQTT solves in industrial settings is the sheer unreliability of typical network infrastructure. Think flaky Wi-Fi in a factory, intermittent cellular connections to remote sites, or even just the sheer volume of devices that need to report in. Traditional request/response protocols choke and fail under these conditions. MQTT, with its publish/subscribe model and Quality of Service (QoS) levels, is designed to handle this.
Here’s how it works under the hood:
- Broker: This is the central hub. Devices (clients) don’t talk to each other directly. They publish messages to the broker, and the broker forwards those messages to any clients that have subscribed to the relevant "topics." Topics are hierarchical strings, like file paths, that categorize the data.
- Publish/Subscribe: A sensor publishes its pressure reading to a topic. A SCADA system or a dashboard subscribes to that topic. The broker sees the publication and delivers it to the subscriber. If no one is subscribed, the message is simply dropped (unless configured otherwise).
- Quality of Service (QoS): This is where MQTT shines for IIoT.
- QoS 0 (At most once): Fire and forget. The message is sent, but there’s no guarantee of delivery. Fastest, but least reliable. Good for non-critical, high-frequency data where a lost reading isn’t a disaster.
- QoS 1 (At least once): The sender gets an acknowledgment (PUBACK) from the broker. If no ACK is received, the sender retries. This guarantees the message arrives at least once, but it might arrive multiple times if the ACK is lost.
- QoS 2 (Exactly once): The most robust. This involves a multi-step handshake between publisher, broker, and subscriber to ensure delivery exactly once. It’s slower but essential for critical data like control commands or financial transactions.
- Last Will and Testament (LWT): A client can specify a "will" message to be published by the broker if the client disconnects unexpectedly. This is invaluable for monitoring device health. If a PLC goes offline, its LWT message ("status: offline") is published to a designated topic, alerting the monitoring system.
Consider a scenario where a PLC needs to adjust a valve based on flow rate. The flow meter publishes its reading to site/plant-b/lines/line-05/flow. The PLC subscribes to this topic. If the PLC publishes a command to site/plant-b/lines/line-05/valve/setpoint with QoS 2, and the network drops after the PLC sends the command but before it receives confirmation, the PLC will retry until it gets that confirmation. If the flow meter stops publishing, its LWT message (status: disconnected) will be sent to site/plant-b/lines/line-05/flow/status, immediately notifying operators of the sensor failure.
The actual configuration for an MQTT client might look something like this (using Mosquitto client syntax):
mosquitto_pub -h mqtt.internal.example.com -p 1883 -t "site/factory-a/pumps/pump-01-alpha/pressure" -m '{"timestamp": "2023-10-27T10:30:00Z", "device_id": "pump-01-alpha", "metric": "pressure", "value": 15.2, "unit": "bar"}' -q 1
And a subscriber:
mosquitto_sub -h mqtt.internal.example.com -p 1883 -t "site/factory-a/pumps/pump-01-alpha/pressure"
The most surprising thing about LWT is that it’s often implemented on the broker side, not the client. The client, when connecting, tells the broker, "If I disappear without saying goodbye, publish this message to this topic." This is incredibly efficient for detecting dead devices.
The next architectural pattern you’ll encounter is how to manage the sheer scale of topics and clients, often involving message routing and filtering beyond the basic broker’s capabilities.