MQTT Protocol for IoT: QoS, Retained Messages and Last Will Explained
MQTT broker routing device telemetry to cloud subscribers — publish-subscribe at the heart of IoT
MQTT is the protocol of record for IoT communication. Lightweight, binary, designed for unreliable networks — it runs on microcontrollers with 64KB RAM and scales to millions of connections on Azure IoT Hub.
QoS Levels
- QoS 0 — At most once: Fire and forget. No ACK. For high-frequency telemetry where occasional missed readings are acceptable.
- QoS 1 — At least once: Broker sends PUBACK; device retransmits until ACK. May deliver duplicates — design cloud processing to be idempotent.
- QoS 2 — Exactly once: Four-way handshake. Use only when duplicates cause real harm (financial transactions).
Last Will and Testament (LWT)
// On connect: configure LWT (sent on unexpected disconnect)
.lwt_topic = "devices/dev-001/status",
.lwt_msg = "{"online":false,"reason":"unexpected"}",
.lwt_qos = 1,
.lwt_retain = 1,
// After connect: publish online status (retained)
mqtt_publish("devices/dev-001/status",
"{"online":true,"firmware":"2.1.0"}", QOS_1, RETAIN);
Topic Design for Scale
A well-designed topic hierarchy makes routing, filtering, and access control straightforward. A poorly designed one becomes a maintenance burden as your fleet grows. Our recommended structure uses device ID as the primary key, with message type as a sub-topic:
devices/{deviceId}/telemetry # sensor readings (QoS 0/1)
devices/{deviceId}/status # online/offline (retained, QoS 1)
devices/{deviceId}/commands/{cmd} # cloud to device commands
devices/{deviceId}/responses/{cmd} # device command responses
fleet/{productLine}/config # fleet-wide config broadcast
Avoid deep topic hierarchies beyond 4–5 levels. Avoid using payload content in topic paths — keep the topic structure static and put variable data in the payload. This makes routing rules simpler and broker performance better.
MQTT vs HTTPS for IoT
Some IoT devices use HTTPS instead of MQTT — typically when the device only ever sends data (no commands needed) and simplicity is valued over efficiency. HTTPS has a larger per-message overhead (TLS handshake + HTTP headers) but works through firewalls that block port 8883. MQTT over WebSockets (port 443) combines MQTT semantics with firewall-friendliness.
Azure IoT Hub supports both MQTT and HTTPS, plus AMQP for high-throughput scenarios. For most connected products, MQTT on port 8883 with mTLS authentication is the right choice — it is efficient, well-supported, and semantically rich enough to handle telemetry, commands, OTA triggers, and device presence tracking in a single connection.
Broker Selection
For development and on-premises deployments, Mosquitto is the industry-standard open-source MQTT broker — lightweight, reliable, and easy to configure. For production cloud deployments, managed services like Azure IoT Hub, AWS IoT Core, or HiveMQ Cloud handle TLS termination, authentication, and horizontal scaling automatically. We recommend managed services for production — operating your own MQTT broker at scale introduces operational complexity that rarely justifies the cost savings.
When evaluating brokers, check: maximum connections, retained message storage limits, QoS 2 support (if needed), message size limits, and per-device access control (can device A read device B’s topics?). Azure IoT Hub enforces per-device topic namespacing by default — devices can only publish to their own topic path, which eliminates an entire class of security vulnerabilities.
Building an IoT product?
FSS is a full-stack IoT engineering team — hardware, firmware, cloud, and mobile in one place.