MQTT with QoS levels in Raspberry Pi - Step-by-Step Execution

Concept Flow - MQTT with QoS levels

Client publishes message

↓

Check QoS level

↓

QoS0

↓

Done

Shows how MQTT handles message delivery differently based on QoS levels 0, 1, and 2.

Execution Sample

Raspberry Pi

client.publish(topic, message, qos=1)
# QoS 1: message sent, waits for PUBACK
# Resends if no PUBACK received
# Ensures message delivered at least once

Publishes a message with QoS 1, ensuring it is delivered at least once by waiting for acknowledgment.

Execution Table

Step	Action	QoS Level	Message State	Acknowledgment	Next Step
1	Client sends message	0	Sent once	No ack expected	Done
2	Client sends message	1	Sent once	Wait for PUBACK	If no PUBACK, resend
3	Client receives PUBACK	1	Message acknowledged	PUBACK received	Done
4	Client sends message	2	Sent once	Wait for PUBREC	Send PUBREL after PUBREC
5	Client receives PUBREC	2	Message received by broker	PUBREC received	Send PUBREL
6	Client sends PUBREL	2	PUBREL sent	Wait for PUBCOMP	Wait for PUBCOMP
7	Client receives PUBCOMP	2	Delivery complete	PUBCOMP received	Done
8	No ack received in QoS1 or QoS2	1 or 2	Resend message or PUBREL	Retry until ack	Repeat steps as needed

💡 Message delivery completes when expected acknowledgments are received or no ack is expected (QoS 0).

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7	Final
Message State	Not sent	Sent once	Acknowledged (QoS1)	Received by broker (QoS2)	Delivery complete (QoS2)	Done
Acknowledgment	None	None	PUBACK received	PUBREC received	PUBCOMP received	Complete
Retries	0	0	0	0	0	0 or more if no ack

Key Moments - 3 Insights

Why does QoS 1 resend the message sometimes?

Because QoS 1 waits for a PUBACK acknowledgment. If it doesn't arrive (see step 2 and 8 in execution_table), the client resends to ensure delivery.

What makes QoS 2 different from QoS 1 in message delivery?

QoS 2 uses a four-step handshake (steps 4 to 7) with PUBREC, PUBREL, and PUBCOMP to guarantee exactly once delivery, unlike QoS 1 which only waits for PUBACK.

Does QoS 0 wait for any acknowledgment?

No, QoS 0 sends the message once without waiting for any acknowledgment (step 1), so delivery is not guaranteed.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the client receive PUBACK for QoS 1?

A Step 5

B Step 3

C Step 7

D Step 1

💡 Hint

Check the 'Acknowledgment' column for QoS 1 in execution_table row 3.

At which step does the client send PUBREL in QoS 2 delivery?

A Step 6

B Step 5

C Step 4

D Step 7

💡 Hint

Look for 'Client sends PUBREL' action in execution_table.

If no PUBACK is received in QoS 1, what happens according to the execution_table?

A Message is dropped

B Client sends PUBREL

C Client resends message

D No action

💡 Hint

See step 8 about retries when no acknowledgment is received.

Concept Snapshot

MQTT QoS levels control message delivery:
QoS 0: Send once, no ack, no guarantee.
QoS 1: Send, wait PUBACK, resend if needed (at least once).
QoS 2: Four-step handshake (PUBREC, PUBREL, PUBCOMP) for exactly once.
Higher QoS means more reliability but more overhead.

Full Transcript

This visual execution shows how MQTT handles message delivery with different Quality of Service (QoS) levels. When a client publishes a message, it checks the QoS level. For QoS 0, the message is sent once without waiting for acknowledgment. For QoS 1, the client sends the message and waits for a PUBACK acknowledgment; if none arrives, it resends the message to ensure delivery at least once. For QoS 2, a four-step handshake occurs: the client sends the message, waits for PUBREC, then sends PUBREL, and finally waits for PUBCOMP to guarantee exactly once delivery. Variables like message state and acknowledgments change step by step, showing how the client tracks delivery progress. Key moments clarify why QoS 1 resends messages, how QoS 2 differs with its handshake, and that QoS 0 does not wait for any acknowledgment. The quiz tests understanding of these steps and behaviors.

Practice

1. What does QoS level 1 guarantee in MQTT communication?

easy

A. At least once delivery of the message

B. Exactly once delivery of the message

C. At most once delivery of the message

D. No delivery guarantee

Solution

1. Step 1: Understand QoS levels in MQTT

   QoS 0 means no guarantee, QoS 1 means at least once, QoS 2 means exactly once.

2. Step 2: Identify QoS 1 guarantee

   QoS 1 ensures the message is delivered at least once, but duplicates may occur.

3. Final Answer:

   At least once delivery of the message -> Option A

4. Quick Check:

   QoS 1 = At least once delivery [OK]

Hint: QoS 1 means message arrives at least once [OK]

Common Mistakes:

• Confusing QoS 1 with exactly once delivery
• Thinking QoS 1 has no delivery guarantee
• Mixing QoS 0 and QoS 1 guarantees

2. Which of the following is the correct way to publish a message with QoS 2 using the Paho MQTT Python client?

easy

A. client.publish(topic, payload, qos=1)

B. client.publish(topic, payload, qos=3)

C. client.publish(topic, payload, qos=2)

D. client.publish(topic, payload, qos=0)

Solution

1. Step 1: Recall valid QoS values in MQTT

   MQTT QoS levels are 0, 1, and 2 only; 3 is invalid.

2. Step 2: Check syntax for publishing with QoS 2

   The Paho client uses qos parameter in publish method; qos=2 is valid.

3. Final Answer:

   client.publish(topic, payload, qos=2) -> Option C

4. Quick Check:

   QoS 2 publish syntax = client.publish(..., qos=2) [OK]

Hint: QoS must be 0, 1, or 2; 2 is highest reliability [OK]

Common Mistakes:

• Using qos=3 which is invalid
• Omitting qos parameter defaults to 0
• Confusing qos=1 with qos=2 syntax

3. Consider this Python code snippet using Paho MQTT client:

client.publish('sensor/data', 'temp=22', qos=0)
client.publish('sensor/data', 'temp=23', qos=1)
client.publish('sensor/data', 'temp=24', qos=2)

What is the expected behavior regarding message delivery?

medium

A. All messages are delivered exactly once

B. First message may be lost, second delivered at least once, third exactly once

C. All messages may be lost without retry

D. First message delivered at least once, others may be duplicated

Solution

1. Step 1: Analyze QoS 0 message delivery

   QoS 0 means message sent once, no retry, may be lost.

2. Step 2: Analyze QoS 1 and QoS 2 messages

   QoS 1 guarantees at least once delivery (may duplicate), QoS 2 guarantees exactly once delivery.

3. Final Answer:

   First message may be lost, second delivered at least once, third exactly once -> Option B

4. Quick Check:

   QoS 0=may lose, QoS 1=at least once, QoS 2=exactly once [OK]

Hint: Remember QoS 0 no retry, QoS 1 retry, QoS 2 handshake [OK]

Common Mistakes:

• Assuming QoS 0 always delivers
• Confusing QoS 1 with exactly once
• Ignoring possible duplicates at QoS 1

4. You wrote this code to publish a message with QoS 2:

client.publish('home/lights', 'ON', qos=2)

But the message is sometimes duplicated on the subscriber side. What is the likely cause?

medium

A. The client.publish syntax is incorrect

B. QoS 2 does not guarantee no duplicates

C. QoS 2 is not supported by the broker

D. The subscriber is not handling duplicate messages properly

Solution

1. Step 1: Understand QoS 2 guarantees

   QoS 2 guarantees exactly once delivery, so duplicates should not occur in transmission.

2. Step 2: Identify cause of duplicates

   If duplicates appear, likely the subscriber application is not filtering duplicates properly.

3. Final Answer:

   The subscriber is not handling duplicate messages properly -> Option D

4. Quick Check:

   QoS 2 = no duplicates in network, subscriber must handle duplicates [OK]

Hint: Duplicates often come from subscriber logic, not QoS 2 itself [OK]

Common Mistakes:

• Blaming QoS 2 for duplicates
• Assuming broker always supports QoS 2
• Thinking publish syntax is wrong

5. You want to design a Raspberry Pi sensor system that sends temperature data reliably without duplicates, but network is unstable. Which MQTT QoS level should you choose and why?

hard

A. QoS 2, to guarantee exactly once delivery with no duplicates

B. QoS 1, to ensure message arrives at least once

C. QoS 1, because QoS 2 is not supported on Raspberry Pi

D. QoS 0, for fastest delivery without retries

Solution

1. Step 1: Analyze requirements for reliability and no duplicates

   The system needs reliable delivery and no duplicate messages despite unstable network.

2. Step 2: Match QoS levels to requirements

   QoS 0 is fastest but unreliable, QoS 1 may duplicate, QoS 2 guarantees exactly once delivery.

3. Step 3: Confirm Raspberry Pi supports QoS 2

   MQTT clients on Raspberry Pi support QoS 2, so it is suitable.

4. Final Answer:

   QoS 2, to guarantee exactly once delivery with no duplicates -> Option A

5. Quick Check:

   Reliable + no duplicates = QoS 2 [OK]

Hint: Choose QoS 2 for no duplicates and reliable delivery [OK]

Common Mistakes:

• Choosing QoS 1 and ignoring duplicates
• Thinking QoS 0 is reliable
• Assuming Raspberry Pi can't use QoS 2