MQTT’s three QoS levels define the message handshake complexity: QoS 0 sends a single PUBLISH with no acknowledgment, QoS 1 adds a PUBACK for confirmed delivery (2 messages), and QoS 2 uses a 4-step handshake (PUBLISH/PUBREC/PUBREL/PUBCOMP) guaranteeing exactly-once delivery. Choosing QoS 0 over QoS 2 for battery-powered sensors can extend battery life from 6 days to over 500 days.
Analyze QoS Handshakes: Trace the message flow for QoS 0, 1, and 2 including all acknowledgment packets
Calculate Battery Impact: Quantify the power consumption differences between QoS levels using energy-per-message formulas
Select Optimal QoS: Apply systematic decision frameworks to choose the correct QoS level for any IoT message type
Diagnose Configuration Errors: Identify and prevent QoS mismatch and session configuration errors in production deployments
Evaluate Trade-offs: Assess the cost, latency, and reliability implications of each QoS level for a given deployment scenario
For Beginners: MQTT QoS Levels
MQTT offers three QoS levels to match different needs. QoS 0 is like shouting a message across a room – fast but unreliable. QoS 1 is like sending a text and waiting for a thumbs up. QoS 2 is like a signed, witnessed contract – nothing is missed or duplicated. Each level costs more network resources but provides stronger guarantees.
Sensor Squad: The QoS Level Tour
“Let me show you each QoS level in action!” said Max the Microcontroller. “Sammy, send a temperature reading at QoS 0.” Sammy transmitted: “25.3 degrees!” Max nodded. “Done. One message sent. If the broker was busy and missed it – oh well, gone forever. That’s QoS 0: at most once.”
“Now QoS 1,” said Sammy, sending again. This time the broker replied with PUBACK. “See? The broker confirmed it arrived,” explained Max. “But what if the PUBACK got lost? Sammy would think the broker missed it and resend. Now the broker has TWO copies. That’s QoS 1: at least once – guaranteed delivery, possible duplicates.”
“For QoS 2, watch carefully,” said Lila the LED. The exchange went: PUBLISH, PUBREC, PUBREL, PUBCOMP. “Four messages, but the two-phase handshake makes it impossible to get duplicates. The broker and client agree on the exact state at each step. That’s QoS 2: exactly once.”
Bella the Battery concluded: “QoS 0 for weather data. QoS 1 for alarm triggers. QoS 2 for financial transactions. Match the level to the stakes!”
Message Ordering: MQTT guarantees ordered delivery within a client session but not across sessions or publishers
MQTT provides three QoS levels that balance reliability, performance, and resource consumption. Each level offers different delivery guarantees and overhead characteristics.
22.3 QoS Message Flow Comparison
The following diagrams illustrate the message handshake patterns for each QoS level, showing how reliability increases with complexity:
Sequence diagram comparing MQTT QoS 0, 1, and 2 message flows between publisher, broker, and subscriber. QoS 0 shows single PUBLISH with no acknowledgment. QoS 1 shows PUBLISH followed by PUBACK acknowledgment from broker and subscriber. QoS 2 shows four-way handshake with PUBLISH, PUBREC, PUBREL, and PUBCOMP messages ensuring exactly-once delivery.
Figure 22.1: MQTT QoS level message flows showing increasing reliability guarantees. QoS 0 provides no acknowledgment (fastest, may lose messages), QoS 1 uses PUBACK for confirmed delivery (may create duplicates if ACK is lost), and QoS 2 employs a four-way handshake (PUBREC->PUBREL->PUBCOMP) ensuring exactly-once delivery with no duplicates.
22.4 QoS 0: At Most Once (Fire and Forget)
Sequence diagram showing MQTT QoS 0 message flow. Publisher sends PUBLISH to Broker, Broker forwards PUBLISH to Subscriber. No acknowledgment messages are exchanged. Note indicates message may be lost.
Figure 22.2: QoS 0 message flow showing fire-and-forget delivery. The publisher sends a single PUBLISH message to the broker, which forwards it to subscribers. No acknowledgment is exchanged, making this the fastest but least reliable option.
Use case: Sensor data where occasional loss is acceptable (temperature readings every 10 seconds).
Putting Numbers to It
QoS 0’s “fire and forget” approach minimizes overhead. For a typical IoT sensor:
This means 38% of each transmission carries actual data. With 288 messages per day (every 5 minutes), that is 7,488 bytes per day. Compare to QoS 2 which would send 4 messages per reading, increasing daily transmission to 29,952 bytes – a 4x increase that directly impacts battery life.
22.5 QoS 1: At Least Once (Acknowledged Delivery)
Sequence diagram showing MQTT QoS 1 message flow. Publisher sends PUBLISH to Broker, Broker responds with PUBACK. Broker sends PUBLISH to Subscriber, Subscriber responds with PUBACK. Note indicates guaranteed delivery but may duplicate if ACK lost.
Figure 22.3: QoS 1 message flow showing acknowledged delivery. The publisher sends PUBLISH and waits for PUBACK acknowledgment from the broker. The broker then forwards to subscribers who also acknowledge. If PUBACK is lost, the publisher retransmits, potentially causing duplicates.
Use case: Commands where delivery matters but duplicates are harmless (motion sensor alerts, door open/close events).
Figure 22.4: QoS 2 message flow showing the four-way handshake between publisher and broker. PUBLISH initiates the exchange, PUBREC confirms receipt, PUBREL signals the publisher is releasing the message, and PUBCOMP confirms completion. This same handshake occurs between broker and subscriber.
Message ordering and exactly-once semantics are required
Default recommendation: QoS 0 for telemetry (90% of IoT traffic), QoS 1 for events/alerts, QoS 2 only for critical commands where duplicates cause harm
Common Misconception: “QoS 2 is Always Better Than QoS 0”
The Misconception: Higher QoS numbers mean better quality, so always use QoS 2 for important data.
LoRaWAN solves the same reliability problem as MQTT QoS but at the network layer. LoRaWAN unconfirmed messages are analogous to MQTT QoS 0 (fire-and-forget), while confirmed messages resemble QoS 1 (acknowledged delivery). However, LoRaWAN has no QoS 2 equivalent – exactly-once semantics must be handled at the application layer. See LoRaWAN Architecture for confirmed vs unconfirmed message details.
22.9 QoS Decision Tree
This decision flowchart provides an alternative approach to selecting the appropriate MQTT QoS level based on application requirements:
Figure 22.5: MQTT QoS decision flowchart guiding selection based on message loss tolerance, duplicate handling, device power constraints, and data frequency. QoS 0 suits frequent, loss-tolerant telemetry from battery devices. QoS 1 handles important alerts where duplicates are acceptable. QoS 2 is reserved for critical commands requiring exactly-once delivery.
22.10 Interactive: MQTT QoS Visualizer
Explore the differences between MQTT QoS levels interactively. Select a QoS level and click “Send Message” to see the message flow animation, including potential message duplication (QoS 1) and the latency trade-off (QoS 2).
Show code
viewof qosLevel = Inputs.radio( ["QoS 0: Fire and Forget","QoS 1: At Least Once","QoS 2: Exactly Once"], {value:"QoS 0: Fire and Forget",label:"Select QoS Level" })// Send Message Buttonviewof sendMessage = Inputs.button("Send Message", {reduce: () =>Date.now()})// Animation statemutable animationStep =0mutable isAnimating =falsemutable showDuplicate =false// Reset animation when QoS changes or button clicked{ qosLevel; sendMessage; mutable animationStep =0; mutable isAnimating =true; mutable showDuplicate =false;}
Click “Send Message” to see the animated message flow
Observe the differences: QoS 0 is fastest (1 message), QoS 1 adds acknowledgment (2 messages), QoS 2 uses a 4-way handshake (4 messages)
Watch for duplicates: QoS 1 may show a duplicate warning (30% chance) demonstrating the “at least once” behavior
Compare the metrics table to understand trade-offs between reliability, latency, and message overhead
QoS Doesn’t Guarantee End-to-End Delivery
A common misconception: QoS 2 means the message reaches the subscriber. Wrong! QoS only guarantees delivery between publisher-to-broker and broker-to-subscriber independently. If the subscriber is offline, QoS 2 ensures the broker stores the message (with Clean Session=false), but the subscriber might never come back online. For true end-to-end confirmation, implement application-level acknowledgments where the subscriber publishes a response message confirming it processed the data.
Knowledge Check: QoS Levels Quick Check
Concept: MQTT supports three Quality of Service (QoS) levels that balance reliability, performance, and network overhead. Choosing the right QoS level is crucial for IoT system design.
Practice Quizzes: Match and Sequence
Concept Matching: Match each MQTT QoS term or concept to its correct definition or use case.
Process Ordering: Arrange the steps of a complete QoS 2 message delivery (publisher to broker leg) in the correct sequence.
22.11 Visual Reference Gallery
🏷️ Label the Diagram
💻 Code Challenge
22.12 Summary
This chapter covered the technical details of MQTT Quality of Service levels:
QoS 0 uses a single message with no acknowledgment, providing the fastest and most battery-efficient delivery at the cost of potential message loss
QoS 1 adds a PUBACK acknowledgment ensuring delivery, but retransmissions when ACKs are lost can create duplicates
QoS 2 uses a four-way handshake (PUBLISH->PUBREC->PUBREL->PUBCOMP) guaranteeing exactly-once delivery at the highest overhead cost
Decision frameworks help systematically select QoS: loss acceptable = QoS 0, duplicates OK = QoS 1, exactly-once required = QoS 2
Production checklist: Evaluate each topic individually – most deployments use QoS 0 for 70-80% of topics
Battery impact is significant: QoS 2 uses 4x more messages than QoS 0, reducing battery life proportionally
End-to-end delivery is not guaranteed by QoS alone; subscriber must be online or use persistent sessions
