Implementing MQTT Quality of Service Levels

Apply different QoS levels to ensure message delivery reliability based on the criticality of data in your IoT application architecture.

In this lesson, you will learn how to strategically select MQTT Quality of Service (QoS) levels to balance data reliability against the resource constraints of your embedded system.

Understanding the QoS Hierarchy

In MQTT, QoS levels determine the delivery guarantee between the client and the broker. When you are operating in an embedded environment, choosing the right level is a trade-off between power consumption, bandwidth, and the criticality of your data.

QoS 0: At Most Once (Fire and Forget)

This is the lowest overhead option. The client sends a PUBLISH packet and assumes it arrives. No acknowledgment is expected.

Use case: Periodic sensor telemetry (e.g., room temperature) where losing a single packet is inconsequential because a newer reading will arrive shortly.
Resource impact: Minimal; it uses the least amount of memory and bandwidth.

QoS 1: At Least Once (Acknowledged Delivery)

The broker must send a PUBACK to confirm receipt. If the client doesn't receive this within a timeout period, it retransmits the message.

Use case: Critical events (e.g., "Motion Detected" alerts). You must ensure the event reaches the broker, but you can tolerate potential duplicate messages if the network glitches during the acknowledgment.
Resource impact: Moderate; requires the client to buffer outgoing messages until the PUBACK is received.

QoS 2: Exactly Once (Assured Delivery)

This involves a four-part handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). It ensures the message is delivered exactly once, removing the risk of duplicates.

Use case: Financial transactions or critical state changes (e.g., "Firmware Update Ready").
Resource impact: High; it requires the most network traffic and state management, which can impact battery life and buffer memory on resource-constrained microcontrollers.

// Example snippet for setting QoS during publication
mqtt_publish(client, "sensor/data", payload, payload_len, QoS_1, retain_flag);

When implementing these, always consider your local memory constraints. If your device is experiencing high latency or jitter, frequent retransmissions (QoS 1 or 2) can quickly exhaust your memory buffers if the broker does not respond in time. Use QoS 0 whenever your application architecture allows for "eventual consistency."

Key Takeaway: Use QoS 0 for transient telemetry to save power, QoS 1 for critical events needing delivery confirmation, and reserve QoS 2 strictly for operations where duplication would cause logic errors.