Understanding MQTT QoS Levels: A Detailed Guide

In the world of IoT, ensuring reliable communication between devices is paramount. MQTT (Message Queuing Telemetry Transport), a lightweight messaging protocol, offers a mechanism to control message delivery reliability through Quality of Service (QoS) levels. Understanding how these QoS levels work can help developers fine-tune their IoT systems to balance performance, reliability, and resource efficiency.

In this blog post, we’ll dive deep into MQTT QoS levels, explaining their mechanics, showcasing code snippets, and illustrating what you might see in logs during message transactions.

What is QoS in MQTT?

Quality of Service (QoS) in MQTT defines how messages are delivered between the sender (publisher) and the receiver (subscriber). MQTT provides three QoS levels:

1. QoS 0: At Most Once

2. QoS 1: At Least Once

3. QoS 2: Exactly Once

Each level offers a trade-off between delivery guarantee and network/resource usage.

1. QoS 0: At Most Once

Description: QoS 0 is the simplest level of service. Messages are delivered once at most, with no guarantee of delivery. This is often called "fire and forget." The message is sent, and no acknowledgment is expected from the receiver. If the network connection is unreliable, messages might get lost.

Use Case: Suitable for non-critical data where occasional message loss is acceptable, such as temperature readings from a non-vital sensor.

How It Works:

• Publisher sends a message to the broker.

• The broker delivers the message to subscribers without acknowledgment.

Code Example:

import paho.mqtt.client as mqtt

broker_address = "broker.hivemq.com"
client = mqtt.Client("QoS0_Publisher")
client.connect(broker_address)

client.publish("home/temperature", "22.5C", qos=0)

Log Output:

[INFO] Connected to broker.hivemq.com
[INFO]

Important Notes:

• No retries are attempted.

• If the client disconnects or the network fails, the message may never arrive.

2. QoS 1: At Least Once

Description: With QoS 1, the message is delivered at least once. The publisher sends the message, and the broker must acknowledge receipt with a PUBACK message. If the acknowledgment isn’t received, the publisher will resend the message until it gets confirmed. This can lead to duplicate messages on the subscriber side.

Use Case: Best for scenarios where message delivery is critical, but occasional duplicates can be tolerated, such as sending commands to devices.

How It Works:

• Publisher sends a message to the broker.

• Broker responds with a PUBACK acknowledgment.

• If PUBACK is not received, the publisher resends the message.

Code Example:

import paho.mqtt.client as mqtt

broker_address = "broker.hivemq.com"
client = mqtt.Client("QoS1_Publisher")
client.connect(broker_address)

client.publish("home/lights", "ON", qos=1)

Log Output:

[INFO] Connected to broker.hivemq.com
[INFO] Published message to topic 'home/lights' with QoS 1
[INFO]

Handling Duplicates on Subscriber Side: To handle possible duplicates, subscribers should implement idempotent operations—ensuring that processing the same message multiple times doesn’t have unintended effects.

3. QoS 2: Exactly Once

Description: QoS 2 ensures that a message is delivered exactly once to the intended recipient. This is the highest level of service and involves a four-step handshake between the publisher and broker to guarantee no duplication.

Use Case: Ideal for scenarios where duplicate messages are unacceptable, such as financial transactions or critical system commands.

How It Works:

1. Publisher sends PUBLISH message with QoS 2.

2. Broker responds with PUBREC (publish received).

3. Publisher replies with PUBREL (publish release).

4. Broker confirms with PUBCOMP (publish complete).

Code Example:

import paho.mqtt.client as mqtt

broker_address = "broker.hivemq.com"
client = mqtt.Client("QoS2_Publisher")
client.connect(broker_address)

client.publish("home/security", "ALARM", qos=2)

Log Output:

[INFO] Connected to broker.hivemq.com
[INFO] Published message to topic 'home/security' with QoS 2
[INFO] PUBREC received for message on topic 'home/security'
[INFO] PUBREL sent for message on topic 'home/security'
[INFO]

Trade-offs:

• Performance Overhead: The four-step handshake introduces latency and higher resource consumption.

• Reliability: Ensures absolute message integrity.

Choosing the Right QoS Level

Selecting the appropriate QoS level depends on the specific requirements of your application:

• QoS 0: Best for high-frequency, low-importance data (e.g., sensor readings).

• QoS 1: Suitable for critical messages where duplication is acceptable (e.g., device control commands).

• QoS 2: Reserved for mission-critical data where exactly-once delivery is mandatory (e.g., financial transactions).

Conclusion

MQTT's QoS levels provide a flexible way to balance reliability and performance in IoT applications. Understanding these levels allows developers to optimize their systems for various use cases—whether it's ensuring that a security alarm is never missed or sending lightweight temperature readings from a sensor.

Recommendations: In most IoT scenarios, QoS 1 is the most commonly used level because it offers a good balance between reliability and performance. It ensures messages are delivered at least once, which is often sufficient for many control and monitoring applications. QoS 0 is preferred for non-critical data to conserve bandwidth and reduce latency, while QoS 2 is typically reserved for high-stakes operations due to its overhead.

By carefully choosing the right QoS level for each scenario, you can build more efficient, robust, and reliable IoT solutions.