MQTT is a publish-subscribe messaging protocol designed for constrained devices and unreliable networks, making it ideal for IoT applications where HTTP’s request-response model often falls short.
Let’s see MQTT in action. Imagine a smart thermostat. Instead of constantly polling a server with HTTP requests like "What’s the temperature?", it subscribes to a topic like thermostat/123/temperature. When the temperature changes, a sensor publishes the new reading to that topic. The thermostat receives this update instantly, without needing to ask.
// Publishing a message
{
"topic": "thermostat/123/temperature",
"payload": "22.5",
"qos": 1
}
// A device subscribed to the above topic receives:
{
"topic": "thermostat/123/temperature",
"payload": "22.5",
"qos": 1
}
This publish-subscribe model is the core of MQTT’s efficiency. Publishers send messages to a central broker without knowing who, if anyone, is listening. Subscribers declare their interest in specific topics to the broker and receive messages published to those topics. This decouples devices and the server, allowing for flexible and scalable communication.
The problem MQTT solves is the inherent inefficiency of HTTP for event-driven, low-bandwidth, and intermittently connected devices. HTTP’s overhead of establishing a connection, sending headers for every request and response, and its request-response nature mean devices would constantly be sending data and waiting for a reply, even when nothing has changed. This consumes precious battery power and network bandwidth.
MQTT’s internal workings are simple but powerful. A broker acts as the central hub. Devices connect to the broker, declaring themselves as either publishers or subscribers. Publishers send messages to specific topics (hierarchical strings like building/floor/room/sensor). Subscribers express interest in topics using topic filters, which can include wildcards (e.g., building/floor/# to get all messages from a floor). The broker then forwards messages from publishers to all subscribers interested in that topic.
Key to its reliability are the Quality of Service (QoS) levels:
- QoS 0 (At most once): Fire and forget. Messages are sent once. No guarantee of delivery.
- QoS 1 (At least once): The sender ensures the message is received by the broker, and the broker ensures it’s delivered to the subscriber at least once. This involves acknowledgments.
- QoS 2 (Exactly once): The most reliable, ensuring a message is delivered precisely one time. This involves a four-way handshake between sender, broker, and receiver.
The levers you control are primarily the topics you define and the QoS levels you choose for publishing and subscribing. A well-designed topic hierarchy is crucial for organizing data and managing subscriptions efficiently. For instance, sensors/buildingA/floor3/temperature is more organized than tempA3. QoS levels are a trade-off between reliability and overhead; for critical data, QoS 1 or 2 is essential, while for non-critical status updates, QoS 0 might suffice.
The WILL message feature in MQTT is a powerful, often overlooked, mechanism for handling disconnections gracefully. When a client connects to the broker, it can specify a WILL message. If the client disconnects unexpectedly (not through a clean disconnect), the broker will publish this WILL message to a designated topic. This allows other devices to be notified of the client’s failure. For example, a sensor device could set its WILL message to indicate it’s offline, and a dashboard could subscribe to this WILL topic to show the sensor as unavailable.
The next concept you’ll encounter is how to manage a large number of devices and topics efficiently with an MQTT broker, including load balancing and clustering.