MQTT with QoS levels in Raspberry Pi - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does MQTT stand for and what is its main use?

MQTT stands for Message Queuing Telemetry Transport. It is a lightweight messaging protocol used for sending data between devices, especially in IoT (Internet of Things) systems like Raspberry Pi projects.

beginner

What are the three QoS levels in MQTT?

The three QoS (Quality of Service) levels in MQTT are:
1. QoS 0 - At most once delivery (fire and forget)
2. QoS 1 - At least once delivery (message is retried until acknowledged)
3. QoS 2 - Exactly once delivery (ensures message is received only once)

beginner

Explain QoS 0 in MQTT with a real-life example.

QoS 0 means the message is sent once without waiting for confirmation. It's like sending a postcard: you drop it in the mailbox but don't know if it arrives. This is good for non-critical data where occasional loss is okay.

intermediate

How does QoS 1 ensure message delivery?

QoS 1 makes sure the message arrives at least once by resending it until the receiver sends an acknowledgment. It's like calling a friend and leaving a voicemail until they confirm they got your message.

intermediate

Why is QoS 2 the most reliable but also the slowest QoS level?

QoS 2 guarantees the message is received exactly once by using a four-step handshake between sender and receiver. This extra checking makes it very reliable but slower, like sending a registered letter that requires a signature on delivery.

Which MQTT QoS level sends a message only once without confirmation?

A QoS 2

B QoS 1

C QoS 0

D QoS 3

QoS 0 sends the message once without waiting for any acknowledgment.

What does QoS 1 guarantee in MQTT?

A Message is sent at least once

B Message is sent at most once

C Message is sent exactly once

D Message is sent twice

QoS 1 guarantees the message is delivered at least once, possibly more if retries happen.

Which QoS level uses a four-step handshake to ensure message delivery?

A QoS 2

B QoS 1

C QoS 3

D QoS 0

QoS 2 uses a four-step handshake to guarantee exactly once delivery.

In MQTT, which QoS level is best for critical messages that must not be lost or duplicated?

A QoS 1

B QoS 2

C QoS 0

D None

QoS 2 ensures messages are delivered exactly once, making it best for critical data.

What is a downside of using QoS 2 in MQTT?

A Messages may be lost

B It does not guarantee delivery

C Messages are not acknowledged

D It is slower due to extra handshakes

QoS 2 is slower because it uses multiple steps to ensure exactly once delivery.

Describe the three MQTT QoS levels and when you might use each one.

Think about message delivery guarantees and real-life examples.

Explain why QoS 2 is more reliable but slower than QoS 0 and QoS 1 in MQTT.

Compare the delivery process and message confirmation.

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