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.