20 MQTT Quality of Service (QoS) Levels

In 60 Seconds

MQTT QoS levels trade reliability for battery life: QoS 0 (fire-and-forget) uses minimal power but may lose messages, QoS 1 (acknowledged) guarantees delivery but may duplicate, and QoS 2 (exactly-once) prevents both loss and duplication at 3x the battery cost. Most sensor telemetry is replaceable, so QoS 0 is usually correct; reserve QoS 1/2 for critical alerts and commands.

20.1 Quality of Service (QoS) Levels

MQTT provides three Quality of Service levels that control message delivery guarantees. This chapter explores each level’s characteristics, use cases, and impact on battery life and performance.

20.2 Learning Objectives

By the end of this chapter, you will be able to:

Compare QoS Levels: Analyze the trade-offs between QoS 0, 1, and 2 in terms of reliability, latency, and energy cost
Select Appropriate QoS: Evaluate IoT scenarios and justify the choice of QoS level for each
Calculate Battery Impact: Apply the energy cost formulas to calculate battery life for different QoS configurations
Design Reliable Systems: Construct IoT architectures that correctly configure QoS levels and handle delivery limitations
Distinguish Delivery Semantics: Explain the difference between hop-by-hop and end-to-end delivery guarantees
Diagnose QoS Pitfalls: Identify and fix common misconfigurations such as using QoS 2 unnecessarily or ignoring cleanSession behavior

Key Concepts

QoS 0 (At Most Once): Fire-and-forget delivery with no acknowledgment — lowest overhead, message loss possible
QoS 1 (At Least Once): ACK-based delivery ensuring message arrives at least once — duplicate possible if PUBACK lost
QoS 2 (Exactly Once): Four-message handshake (PUBLISH/PUBREC/PUBREL/PUBCOMP) guaranteeing exactly one delivery
PUBACK: Broker acknowledgment for QoS 1 publish — triggers publisher to remove message from retry queue
QoS Downgrade: Broker silently delivers at subscriber’s QoS level if lower than publisher’s — common source of unexpected behavior
In-flight Messages: QoS 1/2 messages awaiting acknowledgment — window size limits concurrent unacknowledged messages
Message Ordering: MQTT guarantees ordered delivery within a client session but not across sessions or publishers

20.3 Most Valuable Understanding (MVU)

For battery-powered IoT sensors sending data every few seconds, choosing QoS 0 instead of QoS 2 can extend battery life by 3x or more. The key insight is that most sensor telemetry is replaceable (the next reading comes soon anyway), so QoS 0 is usually correct. Reserve QoS 1/2 only for critical commands or events.

Remember: QoS guarantees delivery between publisher-to-broker and broker-to-subscriber independently - it does NOT guarantee end-to-end delivery if the subscriber is offline.

Related Chapters

This is part of a series on MQTT:

MQTT Architecture - Broker architecture and pub-sub pattern
MQTT Topics & Wildcards - Topic design best practices
MQTT QoS Levels (this chapter) - Delivery guarantees and battery trade-offs
MQTT Security - TLS, authentication, and access control
MQTT Labs - Hands-on QoS experiments

Related Protocols:

CoAP Fundamentals - Alternative lightweight protocol with similar reliability options
LoRaWAN - Low-power wide-area network often used with MQTT

20.4 Prerequisites

Before starting this chapter, you should be familiar with:

MQTT Architecture: Understanding the publish-subscribe pattern
IoT Networking Basics: Network reliability concepts

Sensor Squad: The Three Magic Delivery Spells!

Hey there, future IoT wizard! Let’s learn about MQTT QoS with the Sensor Squad!

Sammy the Sensor needs to send temperature readings to Cloudy the Cloud Server. But Sammy lives far away, and sometimes messages get lost on the journey!

Think of it like sending a letter:

QoS 0 - The Paper Airplane Spell: Sammy folds the message into a paper airplane and throws it toward Cloudy. Maybe it arrives, maybe the wind blows it away. Super fast, barely uses any energy! “Fire and forget!”
QoS 1 - The Carrier Pigeon Spell: Sammy sends a carrier pigeon. The pigeon flies to Cloudy, and when Cloudy gets the message, the pigeon flies back with a “Got it!” note. If Sammy doesn’t get the note, the pigeon goes again! Sometimes Cloudy gets TWO copies, but at least it arrives!
QoS 2 - The Magic Portal Spell: Sammy creates a special magic portal. First, Sammy says “Ready to send!” Cloudy says “Ready to receive!” Then Sammy says “Sending now!” and Cloudy says “Got it exactly once!” Four messages total, but guaranteed perfect delivery!

The Sensor Squad Energy Challenge:

Spell	Energy Used	Delivery Guarantee	Best For
Paper Airplane (QoS 0)	1 battery bar	Maybe arrives	Temperature every minute
Carrier Pigeon (QoS 1)	2 battery bars	Definitely arrives (maybe twice)	“Door opened!” alerts
Magic Portal (QoS 2)	3 battery bars	Arrives exactly once	“Unlock the door!” commands

Lila the Light says: “I use QoS 0 to tell everyone my brightness level every second. If one message gets lost, another comes right away!”

Max the Motor adds: “But when I get a ‘STOP!’ command, I need QoS 2! If I get ‘STOP’ twice, I might get confused. If I miss ‘STOP’, something might break!”

Fun Fact: With the same battery and the same publish rate, QoS 0 can last about 3 times longer than QoS 2 — because QoS 2 needs 4 times as many radio messages per publish! That can mean months of extra battery life on a real sensor.

Try This: Think about your favorite smart device at home. What kind of messages does it send? Would missing a message matter? Which QoS spell would YOU choose?

For Beginners: Understanding Message Delivery Guarantees

Analogy: QoS is Like Shipping Options

Imagine you’re running an online store that ships packages:

Shipping Option	MQTT Equivalent	How It Works	When to Use
Standard Mail	QoS 0	Drop in mailbox, hope it arrives. No tracking.	Catalogs, flyers (replaceable)
Tracked Delivery	QoS 1	Delivery confirmation. Might accidentally ship twice if tracking glitches.	Most packages (duplicates annoying but OK)
Certified with Signature	QoS 2	Full handshake: “Ready?” “Yes!” “Sending!” “Received!”	Legal documents (exactly once critical)

Key Terms:

Term	Definition
QoS	Quality of Service - the level of delivery guarantee
PUBACK	The acknowledgment message for QoS 1
Handshake	Exchange of messages to confirm delivery
Idempotent	An operation that produces the same result even if repeated
Fire-and-forget	Sending without waiting for confirmation
Retained message	A message stored by the broker for new subscribers

Why does this matter in IoT?

Challenge	QoS Solution
Battery life	Use QoS 0 for telemetry to minimize radio time
Network reliability	Use QoS 1/2 on unreliable connections
Critical commands	Use QoS 2 to prevent duplicate execution
High-frequency data	Use QoS 0 - missing one sample is OK

20.5 QoS Level Summary

QoS	Name	Guarantee	Use Case
0	At most once	Fire and forget	Frequent sensor readings
1	At least once	Acknowledged delivery	Important alerts
2	Exactly once	Guaranteed once	Critical commands

20.5.1 QoS 0: At Most Once (Fire and Forget)

QoS 0 fire-and-forget flow — Figure 20.1: MQTT QoS 0: At most once delivery

20.5.2 QoS 1: At Least Once (Acknowledged)

QoS 1 acknowledged delivery — Figure 20.2: MQTT QoS 1: At least once delivery with acknowledgment

20.5.3 QoS 2: Exactly Once (Four-Way Handshake)

QoS 2 four-way handshake — Figure 20.3: MQTT QoS 2: Exactly once delivery with four-way handshake

20.5.4 QoS Comparison Overview

QoS 0, 1, 2 comparison — Figure 20.4: Side-by-side comparison of all three QoS levels

Deep Dive: QoS Implementation Details

Understanding how QoS levels work under the hood helps you make informed design decisions for production IoT systems.

QoS 0 Message Flow (2 messages total):

Publisher -> PUBLISH -> Broker -> PUBLISH -> Subscriber

No acknowledgment, no retry
Latency: ~5-10ms
Packet overhead: 2 bytes (minimum MQTT header)
Battery impact: Minimal (1 transmission)

QoS 1 Message Flow (4 messages total):

Publisher -> PUBLISH (with Message ID) -> Broker
Broker -> PUBACK (acknowledges receipt) -> Publisher
Broker -> PUBLISH -> Subscriber
Subscriber -> PUBACK -> Broker

Publisher retransmits if no PUBACK within timeout (typically 5 seconds)
Broker stores message until subscriber acknowledges
Latency: ~15-30ms
Packet overhead: 4 bytes (header + Message ID)
Battery impact: 2x transmissions
Duplicate detection: Message ID allows subscriber to detect duplicates (but doesn’t prevent them)

QoS 2 Message Flow (8 messages total):

Publisher -> PUBLISH (Message ID) -> Broker
Broker -> PUBREC (receipt confirmed) -> Publisher
Publisher -> PUBREL (release for delivery) -> Broker
Broker -> PUBCOMP (complete) -> Publisher
Broker -> PUBLISH (Message ID) -> Subscriber
Subscriber -> PUBREC -> Broker
Broker -> PUBREL -> Subscriber
Subscriber -> PUBCOMP -> Broker

Four-way handshake on both the publisher-to-broker AND broker-to-subscriber legs = 8 packets total
Broker and publisher maintain state until PUBCOMP
Latency: ~40-80ms
Packet overhead: 4 bytes (header + Message ID, same as QoS 1)
Battery impact: 3x transmissions (publisher side: 2 TX + 2 RX)
State overhead: Both sides store transaction state (memory cost)

Putting Numbers to It: QoS Battery Life Impact

Scenario: Sensor publishes every 10 seconds using CR2032 (220 mAh @ 3V).

QoS 0 (Fire-and-forget): \[ \begin{align} \text{TX PUBLISH (1 packet @ 20 ms, 20 mA)} &= 20 \times 10^{-3} \times 20 \times 10^{-3} = 0.4 \text{ mAs} \\ \text{Messages/day} &= \frac{86{,}400}{10} = 8{,}640 \\ \text{Daily energy} &= 8{,}640 \times 0.4 = 3{,}456 \text{ mAs} = 0.96 \text{ mAh} \\ \text{Battery life} &= \frac{220}{0.96} = 229 \text{ days} \end{align} \]

QoS 1 (At-least-once): \[ \begin{align} \text{TX PUBLISH} &= 0.4 \text{ mAs} \\ \text{RX PUBACK (15 ms, 15 mA)} &= 15 \times 10^{-3} \times 15 \times 10^{-3} = 0.225 \text{ mAs} \\ \text{Per message} &= 0.625 \text{ mAs} \\ \text{Daily energy} &= 8{,}640 \times 0.625 = 5{,}400 \text{ mAs} = 1.5 \text{ mAh} \\ \text{Battery life} &= \frac{220}{1.5} = 147 \text{ days} \end{align} \]

QoS 2 (Exactly-once): \[ \begin{align} \text{4-way handshake} &: \\ \text{TX PUBLISH} &= 0.4 \text{ mAs} \\ \text{RX PUBREC} &= 0.225 \text{ mAs} \\ \text{TX PUBREL} &= 0.4 \text{ mAs} \\ \text{RX PUBCOMP} &= 0.225 \text{ mAs} \\ \text{Per message} &= 1.25 \text{ mAs} \\ \text{Daily energy} &= 8{,}640 \times 1.25 = 10{,}800 \text{ mAs} = 3.0 \text{ mAh} \\ \text{Battery life} &= \frac{220}{3.0} = 73 \text{ days} \end{align} \]

Life comparison: \[ \text{QoS 0 : QoS 1 : QoS 2} = 229 : 147 : 73 = 3.1 : 2.0 : 1.0 \]

Conclusion: QoS 0 lasts 3.1x longer than QoS 2. Choose based on message criticality, not default to QoS 2.

Real-World Performance Measurements:

On a dedicated MQTT broker (Mosquitto) connected via a stable TCP/IP network:

Metric	QoS 0	QoS 1	QoS 2
Latency (avg)	8ms	24ms	67ms
Messages/sec	5000	2000	800
Battery life ratio (same device, same rate)	3x longer	1.5x longer	1x (baseline)
Reliability (stable network)	99.8%	99.99%	100%
Reliability (unstable network)	95%	99.5%	100%

When to Use Each QoS:

QoS 0: Temperature readings every 30 seconds (occasional loss acceptable), device heartbeats, non-critical telemetry
QoS 1: Door/window open alerts, motion detection events, battery low warnings (duplicates acceptable)
QoS 2: Financial transactions (vending machine payments), medication dispensing commands, door lock/unlock commands (duplicates dangerous)

Common Misconception: “QoS 2 ensures the subscriber receives the message.” False! QoS guarantees delivery from publisher->broker and broker->subscriber independently. If subscriber is offline, broker queues the message (with Clean Session=0), but subscriber may never reconnect. For true end-to-end confirmation, implement application-level acknowledgments.

Hybrid Approach: Use QoS 0 for periodic telemetry + QoS 1 for critical events. This optimizes both battery life and reliability.

20.6 Knowledge Checks

Interactive Quizzes: Match and Order

Matching Quiz — Match each MQTT QoS concept to its correct definition or use case.

Ordering Quiz — Arrange the steps of the MQTT QoS 2 four-way handshake in the correct sequence.

Worked Example: Battery Life Optimization for Weather Station

Scenario: You’re deploying 200 solar-powered weather stations across a nature reserve. Each station has a 2000 mAh battery and 5W solar panel. Stations publish 4 metrics (temperature, humidity, wind speed, pressure) and must survive 7 consecutive cloudy days with minimal solar input.

Current Design (Failing):

Publish interval: Every 30 seconds
QoS level: QoS 2 (team wanted “guaranteed delivery”)
Message rate: 4 metrics x (60 min x 24 hr / 0.5 min) = 11,520 messages/day

Step 1: Measure Current Battery Drain

ESP32 power consumption: - Deep sleep: 0.01 mA - Wake + WiFi connect: 120 mA for 2 seconds = 0.067 mAh - Read 4 sensors: 50 mA for 0.5 seconds = 0.007 mAh - MQTT QoS 2 publish (4 messages): 120 mA for 1.2 seconds (4 x 300ms) = 0.040 mAh - Total per cycle: 0.067 + 0.007 + 0.040 = 0.114 mAh

Daily consumption: - Wake cycles: 2880 per day (every 30 seconds) - Battery drain: 2880 x 0.114 = 328 mAh/day

Result: Battery lasts 2000 / 328 = 6.1 days – fails 7-day requirement!

Step 2: Optimize QoS Selection

Weather data is not critical – missing a few readings is acceptable. Change to QoS 0: - MQTT QoS 0 publish (4 messages): 120 mA for 0.4 seconds (4 x 100ms) = 0.013 mAh - New total per cycle: 0.067 + 0.007 + 0.013 = 0.087 mAh

Daily consumption: 2880 x 0.087 = 251 mAh/day Battery life: 2000 / 251 = 8.0 days – now meets requirement!

Step 3: Further Optimization (Publish Interval)

Reduce publish frequency to every 5 minutes (weather doesn’t change that fast): - Wake cycles: 288 per day - Daily consumption: 288 x 0.087 = 25 mAh/day - Battery life: 2000 / 25 = 80 days – 10x improvement!

Step 4: Add Smart Publishing

Only publish when data changes significantly:

float lastTemp = 0, lastHum = 0, lastWind = 0, lastPres = 0;
const float TEMP_THRESHOLD = 0.5;  // 0.5 deg C change
const float HUM_THRESHOLD = 2.0;   // 2% change
const unsigned long HEARTBEAT = 300000;  // 5 min max

void loop() {
    float temp = readTemp(), hum = readHum(), wind = readWind(), pres = readPres();

    // Only publish changed metrics
    if (abs(temp - lastTemp) >= TEMP_THRESHOLD) {
        client.publish("station/temp", String(temp).c_str(), false);
        lastTemp = temp;
    }
    // Repeat for other sensors...

    // Heartbeat: publish all every 5 minutes regardless
    if (millis() - lastPublish >= HEARTBEAT) {
        publishAll();
    }

    esp_sleep_enable_timer_wakeup(60 * 1000000);  // Sleep 60 seconds
    esp_deep_sleep_start();
}

Expected change-based messages: ~50/day (weather is relatively stable) - Daily consumption: 50 x 0.087 = 4.35 mAh/day - Battery life: 2000 / 4.35 = 460 days (15 months)!

Summary Table:

Configuration	Messages/Day	Battery Drain	Battery Life	Cost Savings
QoS 2, 30s	11,520	328 mAh	6.1 days	Baseline
QoS 0, 30s	11,520	251 mAh	8.0 days	31% longer
QoS 0, 5min	1,152	25 mAh	80 days	13x longer
QoS 0, on-change	~50	4.35 mAh	460 days	75x longer!

Key Lessons:

QoS 0 vs QoS 2: 31% battery savings for replaceable telemetry
Reduce frequency: 10x improvement by publishing every 5 min instead of 30 sec
Publish on change: 75x improvement by only transmitting meaningful updates
Combined impact: 6 days to 460 days = practical solar-powered deployment

20.7 Battery Life Optimization Tips

Optimizing Battery Through QoS and Publish Strategy

Increase publish interval: Publishing every 5 minutes instead of every minute gives 5x battery life
Use QoS 0 for sensor data: Non-critical readings don’t need guaranteed delivery
Batch messages: Collect multiple readings and publish together
Adjust keep-alive: Longer keep-alive intervals reduce heartbeat overhead
Optimize payload: Smaller JSON payloads = less transmission time = longer battery life

20.8 Interactive MQTT Message Flow Simulator

Experience how different QoS levels handle message delivery under varying network conditions:

Show code

viewof qosLevel = Inputs.radio(
  ["QoS 0 (At most once)", "QoS 1 (At least once)", "QoS 2 (Exactly once)"],
  {label: "Select QoS Level:", value: "QoS 0 (At most once)"}
)

viewof networkReliability = Inputs.range([50, 100], {value: 90, step: 5, label: "Network reliability (%):"})

viewof messageCount = Inputs.range([1, 20], {value: 5, step: 1, label: "Messages to send:"})

viewof simulateBtn = Inputs.button("Simulate Message Flow")

simulation = {
  simulateBtn;
  const qos = qosLevel.startsWith("QoS 0") ? 0 : qosLevel.startsWith("QoS 1") ? 1 : 2;
  const results = [];
  let delivered = 0;
  let duplicates = 0;
  let lost = 0;

  for (let i = 1; i <= messageCount; i++) {
    const success = Math.random() * 100 < networkReliability;

    if (qos === 0) {
      if (success) { delivered++; results.push(`Msg ${i}: Delivered`); }
      else { lost++; results.push(`Msg ${i}: Lost (no retry)`); }
    } else if (qos === 1) {
      if (success) { delivered++; results.push(`Msg ${i}: Delivered + ACK`); }
      else {
        // Retry
        const retry = Math.random() * 100 < networkReliability;
        if (retry) {
          delivered++;
          if (Math.random() > 0.7) { duplicates++; results.push(`Msg ${i}: Delivered (retry, possible duplicate)`); }
          else { results.push(`Msg ${i}: Delivered (after retry)`); }
        }
        else { lost++; results.push(`Msg ${i}: Lost after retry`); }
      }
    } else { // QoS 2
      delivered++;
      results.push(`Msg ${i}: Exactly once (4-way handshake)`);
    }
  }

  return {results, delivered, duplicates, lost, total: messageCount};
}

md`### Simulation Results (${qosLevel})

**Summary:** ${simulation.delivered}/${simulation.total} delivered, ${simulation.duplicates} duplicates, ${simulation.lost} lost

| Message Flow |
|--------------|
${simulation.results.map(r => `| ${r} |`).join('\n')}

**QoS Trade-offs:**
${qosLevel.includes("QoS 0") ? "- Fastest, lowest overhead\n- Messages can be lost\n- No acknowledgment" : ""}
${qosLevel.includes("QoS 1") ? "- Guaranteed delivery\n- Possible duplicates\n- Requires PUBACK" : ""}
${qosLevel.includes("QoS 2") ? "- Exactly once delivery\n- Highest latency (4 messages)\n- Most overhead" : ""}`

20.9 QoS Battery Life Calculator

Use this calculator to estimate how QoS level and publish interval affect battery life for your IoT device:

Show code

viewof batteryCapacity = Inputs.range([100, 10000], {
  value: 220, step: 10, label: "Battery capacity (mAh):",
  width: 400
})

viewof publishInterval = Inputs.range([1, 3600], {
  value: 10, step: 1, label: "Publish interval (seconds):",
  width: 400
})

viewof txPower = Inputs.range([5, 200], {
  value: 20, step: 1, label: "TX current draw (mA):",
  width: 400
})

viewof txDuration = Inputs.range([5, 200], {
  value: 20, step: 1, label: "TX duration per packet (ms):",
  width: 400
})

viewof rxPower = Inputs.range([5, 200], {
  value: 15, step: 1, label: "RX current draw (mA):",
  width: 400
})

viewof rxDuration = Inputs.range([5, 200], {
  value: 15, step: 1, label: "RX duration per packet (ms):",
  width: 400
})

batteryResults = {
  const txEnergy = txPower * txDuration / 1000;
  const rxEnergy = rxPower * rxDuration / 1000;
  const msgsPerDay = Math.floor(86400 / publishInterval);

  const qos0Energy = txEnergy;
  const qos1Energy = txEnergy + rxEnergy;
  const qos2Energy = 2 * txEnergy + 2 * rxEnergy;

  const qos0Daily = msgsPerDay * qos0Energy / 3600;
  const qos1Daily = msgsPerDay * qos1Energy / 3600;
  const qos2Daily = msgsPerDay * qos2Energy / 3600;

  const qos0Life = qos0Daily > 0 ? batteryCapacity / qos0Daily : Infinity;
  const qos1Life = qos1Daily > 0 ? batteryCapacity / qos1Daily : Infinity;
  const qos2Life = qos2Daily > 0 ? batteryCapacity / qos2Daily : Infinity;

  return {
    msgsPerDay,
    qos0: { energyPerMsg: qos0Energy.toFixed(3), dailyMah: qos0Daily.toFixed(2), lifeDays: qos0Life.toFixed(1) },
    qos1: { energyPerMsg: qos1Energy.toFixed(3), dailyMah: qos1Daily.toFixed(2), lifeDays: qos1Life.toFixed(1) },
    qos2: { energyPerMsg: qos2Energy.toFixed(3), dailyMah: qos2Daily.toFixed(2), lifeDays: qos2Life.toFixed(1) },
    ratio: (qos0Life / qos2Life).toFixed(1)
  };
}

html`<div style="background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-radius: 8px; padding: 20px; margin: 10px 0; border-left: 4px solid #16A085;">
<h4 style="color: #2C3E50; margin-top: 0;">Battery Life Estimates (${batteryResults.msgsPerDay.toLocaleString()} messages/day)</h4>
<table style="width: 100%; border-collapse: collapse; font-size: 14px;">
<thead>
<tr style="border-bottom: 2px solid #2C3E50;">
<th style="text-align: left; padding: 8px; color: #2C3E50;">QoS Level</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Energy/Msg (mAs)</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Daily Drain (mAh)</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Battery Life (days)</th>
</tr>
</thead>
<tbody>
<tr style="background: rgba(22, 160, 133, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #16A085;">QoS 0 (Fire-and-forget)</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos0.energyPerMsg}</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos0.dailyMah}</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #16A085;">${batteryResults.qos0.lifeDays}</td>
</tr>
<tr style="background: rgba(230, 126, 34, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #E67E22;">QoS 1 (At least once)</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos1.energyPerMsg}</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos1.dailyMah}</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #E67E22;">${batteryResults.qos1.lifeDays}</td>
</tr>
<tr style="background: rgba(231, 76, 60, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #E74C3C;">QoS 2 (Exactly once)</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos2.energyPerMsg}</td>
<td style="text-align: right; padding: 8px;">${batteryResults.qos2.dailyMah}</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #E74C3C;">${batteryResults.qos2.lifeDays}</td>
</tr>
</tbody>
</table>
<p style="margin: 10px 0 0 0; color: #7F8C8D; font-size: 13px;">QoS 0 lasts <strong style="color: #2C3E50;">${batteryResults.ratio}x</strong> longer than QoS 2 at the same publish rate.</p>
</div>`

20.10 MQTT Throughput and Latency Estimator

Estimate the maximum throughput and expected latency for each QoS level based on your network conditions:

Show code

viewof rtt = Inputs.range([1, 500], {
  value: 20, step: 1, label: "Network RTT (ms):",
  width: 400
})

viewof bandwidth = Inputs.range([1, 1000], {
  value: 100, step: 1, label: "Available bandwidth (Kbps):",
  width: 400
})

viewof payloadSize = Inputs.range([1, 1024], {
  value: 50, step: 1, label: "Message payload size (bytes):",
  width: 400
})

viewof concurrentPubs = Inputs.range([1, 100], {
  value: 10, step: 1, label: "Concurrent publishers:",
  width: 400
})

throughputResults = {
  const headerBytes = 2;
  const msgIdBytes = 2;
  const totalQ0 = payloadSize + headerBytes;
  const totalQ1 = payloadSize + headerBytes + msgIdBytes;
  const totalQ2 = payloadSize + headerBytes + msgIdBytes;

  const bitsPerSec = bandwidth * 1000;

  const q0Latency = rtt / 2;
  const q1Latency = rtt;
  const q2Latency = 2 * rtt;

  const q0MaxPerSec = Math.min(
    Math.floor(bitsPerSec / (totalQ0 * 8)),
    Math.floor(1000 / Math.max(q0Latency, 1))
  );
  const q1MaxPerSec = Math.min(
    Math.floor(bitsPerSec / ((totalQ1 + 4) * 8)),
    Math.floor(1000 / Math.max(q1Latency, 1))
  );
  const q2MaxPerSec = Math.min(
    Math.floor(bitsPerSec / ((totalQ2 + 12) * 8)),
    Math.floor(1000 / Math.max(q2Latency, 1))
  );

  const perPubQ0 = Math.floor(q0MaxPerSec / concurrentPubs);
  const perPubQ1 = Math.floor(q1MaxPerSec / concurrentPubs);
  const perPubQ2 = Math.floor(q2MaxPerSec / concurrentPubs);

  return {
    q0: { latency: q0Latency.toFixed(0), maxMsg: q0MaxPerSec, perPub: perPubQ0 },
    q1: { latency: q1Latency.toFixed(0), maxMsg: q1MaxPerSec, perPub: perPubQ1 },
    q2: { latency: q2Latency.toFixed(0), maxMsg: q2MaxPerSec, perPub: perPubQ2 }
  };
}

html`<div style="background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-radius: 8px; padding: 20px; margin: 10px 0; border-left: 4px solid #3498DB;">
<h4 style="color: #2C3E50; margin-top: 0;">Throughput & Latency Estimates</h4>
<table style="width: 100%; border-collapse: collapse; font-size: 14px;">
<thead>
<tr style="border-bottom: 2px solid #2C3E50;">
<th style="text-align: left; padding: 8px; color: #2C3E50;">QoS Level</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Expected Latency</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Max Broker Msgs/sec</th>
<th style="text-align: right; padding: 8px; color: #2C3E50;">Per Publisher Msgs/sec</th>
</tr>
</thead>
<tbody>
<tr style="background: rgba(22, 160, 133, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #16A085;">QoS 0</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q0.latency} ms</td>
<td style="text-align: right; padding: 8px; font-weight: bold;">${throughputResults.q0.maxMsg.toLocaleString()}</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q0.perPub.toLocaleString()}</td>
</tr>
<tr style="background: rgba(230, 126, 34, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #E67E22;">QoS 1</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q1.latency} ms</td>
<td style="text-align: right; padding: 8px; font-weight: bold;">${throughputResults.q1.maxMsg.toLocaleString()}</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q1.perPub.toLocaleString()}</td>
</tr>
<tr style="background: rgba(231, 76, 60, 0.1);">
<td style="padding: 8px; font-weight: bold; color: #E74C3C;">QoS 2</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q2.latency} ms</td>
<td style="text-align: right; padding: 8px; font-weight: bold;">${throughputResults.q2.maxMsg.toLocaleString()}</td>
<td style="text-align: right; padding: 8px;">${throughputResults.q2.perPub.toLocaleString()}</td>
</tr>
</tbody>
</table>
<p style="margin: 10px 0 0 0; color: #7F8C8D; font-size: 13px;">Based on ${rtt} ms RTT, ${bandwidth} Kbps bandwidth, ${payloadSize}-byte payloads, ${concurrentPubs} publishers.</p>
</div>`

20.11 QoS Selection Advisor

Answer a few questions about your IoT scenario to get a QoS recommendation:

Show code

viewof dataType = Inputs.radio(
  ["Periodic telemetry (temperature, humidity, etc.)", "Event-driven alerts (door open, motion)", "Device commands (lock, unlock, dispense)", "Financial transactions (payments, billing)"],
  {label: "What type of data are you sending?", value: "Periodic telemetry (temperature, humidity, etc.)"}
)

viewof frequency = Inputs.radio(
  ["High frequency (< 1 minute)", "Medium frequency (1-10 minutes)", "Low frequency (> 10 minutes)", "On-demand only"],
  {label: "How often is data sent?", value: "High frequency (< 1 minute)"}
)

viewof dupTolerance = Inputs.radio(
  ["Duplicates are harmless", "Duplicates are annoying but manageable", "Duplicates cause real problems"],
  {label: "How tolerant is your system of duplicate messages?", value: "Duplicates are harmless"}
)

viewof batteryPowered = Inputs.toggle({label: "Device is battery-powered?", value: true})

viewof networkQuality = Inputs.radio(
  ["Stable (WiFi, Ethernet)", "Variable (cellular, satellite)", "Unreliable (LoRa, remote sites)"],
  {label: "Network quality:", value: "Stable (WiFi, Ethernet)"}
)

recommendation = {
  let score = 0;

  if (dataType.includes("Periodic")) score += 0;
  else if (dataType.includes("Event")) score += 1;
  else if (dataType.includes("commands")) score += 2;
  else score += 3;

  if (frequency.includes("High")) score += 0;
  else if (frequency.includes("Medium")) score += 0;
  else if (frequency.includes("Low")) score += 1;
  else score += 1;

  if (dupTolerance.includes("harmless")) score += 0;
  else if (dupTolerance.includes("annoying")) score += 1;
  else score += 3;

  if (batteryPowered) score -= 1;
  if (networkQuality.includes("Unreliable")) score += 1;

  let qos, color, reasoning;
  if (score <= 1) {
    qos = "QoS 0 (Fire-and-forget)";
    color = "#16A085";
    reasoning = "Your data is replaceable, sent frequently, and duplicates are tolerable. QoS 0 maximizes battery life and throughput with minimal overhead.";
  } else if (score <= 4) {
    qos = "QoS 1 (At least once)";
    color = "#E67E22";
    reasoning = "Your messages are important enough to require delivery confirmation but duplicates can be handled. QoS 1 provides a good balance of reliability and efficiency.";
  } else {
    qos = "QoS 2 (Exactly once)";
    color = "#E74C3C";
    reasoning = "Your use case involves critical, non-idempotent operations where duplicates could cause real problems. QoS 2 guarantees exactly-once delivery at the cost of higher latency and battery consumption.";
  }

  return { qos, color, reasoning, score };
}

html`<div style="background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-radius: 8px; padding: 20px; margin: 10px 0; border-left: 4px solid ${recommendation.color};">
<h4 style="color: ${recommendation.color}; margin-top: 0;">Recommended: ${recommendation.qos}</h4>
<p style="color: #2C3E50; margin: 8px 0;">${recommendation.reasoning}</p>
${recommendation.score <= 4 ? `<p style="color: #7F8C8D; font-size: 13px; margin: 8px 0 0 0;"><strong>Tip:</strong> Consider designing your commands to be idempotent (safe to repeat). This lets you use QoS 1 instead of QoS 2 in most cases, saving battery and reducing latency.</p>` : `<p style="color: #7F8C8D; font-size: 13px; margin: 8px 0 0 0;"><strong>Important:</strong> QoS 2 guarantees delivery between publisher-broker and broker-subscriber independently. For true end-to-end confirmation, add application-level acknowledgments.</p>`}
</div>`

20.12 Broker Message Queue Size Estimator

Estimate broker memory requirements for offline message queuing with persistent sessions:

Show code

viewof numDevices = Inputs.range([1, 10000], {
  value: 100, step: 1, label: "Number of devices:",
  width: 400
})

viewof avgPayloadBytes = Inputs.range([10, 2048], {
  value: 100, step: 10, label: "Average payload size (bytes):",
  width: 400
})

viewof msgPerMinute = Inputs.range([0.1, 60], {
  value: 1, step: 0.1, label: "Messages per device per minute:",
  width: 400
})

viewof offlinePct = Inputs.range([0, 100], {
  value: 10, step: 1, label: "% devices offline at any time:",
  width: 400
})

viewof maxOfflineHours = Inputs.range([0.5, 168], {
  value: 2, step: 0.5, label: "Max offline duration (hours):",
  width: 400
})

viewof brokerQos = Inputs.radio(
  ["QoS 0 (no queuing)", "QoS 1", "QoS 2"],
  {label: "QoS level for queued messages:", value: "QoS 1"}
)

brokerResults = {
  const offlineDevices = Math.ceil(numDevices * offlinePct / 100);
  const mqttOverhead = brokerQos.includes("QoS 0") ? 2 : brokerQos.includes("QoS 1") ? 4 : 6;
  const totalMsgSize = avgPayloadBytes + mqttOverhead + 8;
  const msgsQueued = brokerQos.includes("QoS 0") ? 0 : offlineDevices * msgPerMinute * maxOfflineHours * 60;
  const totalBytes = msgsQueued * totalMsgSize;
  const totalMB = totalBytes / (1024 * 1024);
  const totalGB = totalBytes / (1024 * 1024 * 1024);

  const allDevicesMsgsPerSec = numDevices * msgPerMinute / 60;

  return {
    offlineDevices,
    msgsQueued: Math.ceil(msgsQueued),
    totalMB: totalMB.toFixed(1),
    totalGB: totalGB.toFixed(3),
    allDevicesMsgsPerSec: allDevicesMsgsPerSec.toFixed(1),
    isQos0: brokerQos.includes("QoS 0")
  };
}

html`<div style="background: linear-gradient(135deg, #f8f9fa 0%, #e9ecef 100%); border-radius: 8px; padding: 20px; margin: 10px 0; border-left: 4px solid #9B59B6;">
<h4 style="color: #2C3E50; margin-top: 0;">Broker Queue Estimate</h4>
${brokerResults.isQos0
  ? `<p style="color: #E74C3C; font-weight: bold;">With QoS 0 and persistent sessions, the broker does NOT queue messages for offline devices. Messages published while a device is offline are permanently lost.</p>`
  : `<table style="width: 100%; border-collapse: collapse; font-size: 14px;">
<tr style="border-bottom: 1px solid #dee2e6;">
<td style="padding: 8px; color: #7F8C8D;">Offline devices (${offlinePct}% of ${numDevices})</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #2C3E50;">${brokerResults.offlineDevices}</td>
</tr>
<tr style="border-bottom: 1px solid #dee2e6;">
<td style="padding: 8px; color: #7F8C8D;">Messages queued (${maxOfflineHours}h offline)</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #2C3E50;">${brokerResults.msgsQueued.toLocaleString()}</td>
</tr>
<tr style="border-bottom: 1px solid #dee2e6;">
<td style="padding: 8px; color: #7F8C8D;">Broker memory required</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #9B59B6;">${Number(brokerResults.totalMB) > 1024 ? brokerResults.totalGB + ' GB' : brokerResults.totalMB + ' MB'}</td>
</tr>
<tr>
<td style="padding: 8px; color: #7F8C8D;">Total broker message rate</td>
<td style="text-align: right; padding: 8px; font-weight: bold; color: #2C3E50;">${brokerResults.allDevicesMsgsPerSec} msgs/sec</td>
</tr>
</table>`}
<p style="margin: 10px 0 0 0; color: #7F8C8D; font-size: 13px;"><strong>Note:</strong> Requires <code>cleanSession=false</code> for broker to queue messages for offline clients. With <code>cleanSession=true</code> (default), no queuing occurs regardless of QoS.</p>
</div>`

20.13 QoS Decision Framework

Use this decision tree to select the appropriate QoS level for your IoT use case:

Decision Criteria Summary:

Scenario	Recommended QoS	Reasoning
Temperature readings every 30s	QoS 0	Replaceable, battery matters
Door/window open alert	QoS 1	Important event, duplicate OK
Payment transaction	QoS 2	Non-idempotent, duplicates dangerous
Motor speed command	QoS 1 + Idempotent design	“Set speed to X” is safe to repeat
Unlock door command	QoS 2	Toggle action, duplicate = re-lock

MQTT QoS decision tree — Figure 20.5: Decision tree for selecting MQTT QoS levels

20.14 Retained Messages and Last Will Testament

20.15 Common Pitfalls

Pitfall 1: Assuming QoS 2 Guarantees End-to-End Delivery

Mistake: Developers often assume that QoS 2 means “the subscriber definitely receives the message.”

Reality: QoS guarantees are hop-by-hop, not end-to-end: - Publisher to Broker: Guaranteed - Broker to Subscriber: Guaranteed only if subscriber is connected

If the subscriber is offline, the message waits in the broker (with Clean Session=false). But if the broker crashes, or the subscriber never reconnects, the message is lost.

Solution: Implement application-level acknowledgments where subscribers publish a “received” message back to the publisher for critical workflows.

Pitfall 2: Using QoS 2 for All Critical Data

Mistake: “This data is important, so I’ll use QoS 2 for everything.”

Reality: QoS 2 adds significant overhead (3x latency, 3x battery consumption) and should rarely be needed.

Better approach:

Make commands idempotent (safe to receive multiple times)
Use QoS 1 with idempotent design instead of QoS 2
Reserve QoS 2 only for truly non-idempotent operations (financial transactions, medication dispensing)

Example: Instead of toggle_light (dangerous to duplicate), use set_light_state: on (safe to repeat).

Pitfall 3: Ignoring Clean Session Impact

Mistake: Setting cleanSession=true (the default in many clients) and expecting messages to be queued while offline.

Reality: With cleanSession=true: - Broker discards all session state on disconnect - QoS 1/2 messages published while you’re offline are lost - Subscriptions are forgotten

Solution: Use cleanSession=false for devices that may disconnect and reconnect:

client.connect(host, cleanSession=False)  # Keep session state

Caveat: This increases broker memory usage - the broker stores messages for offline clients.

Pitfall 4: Wrong QoS on Retained Messages

Mistake: Publishing a retained message with QoS 0, then wondering why new subscribers sometimes don’t get it.

Reality: Retained messages with QoS 0 can be lost during broker restarts or when storage limits are reached.

Solution: Use at least QoS 1 for retained messages that must persist:

client.publish("sensors/status", "online", qos=1, retain=True)

MQTT QoS pitfalls summary — Common MQTT QoS pitfalls

What If: Your MQTT Broker Goes Down?

Scenario: You’re running a critical smart factory with 500 sensors publishing to a single MQTT broker. At 2 AM, the broker server crashes due to a power failure.

What happens:

Publishers keep trying to connect with exponential backoff (1s, 2s, 4s, 8s…)
Messages are lost unless devices implement local buffering (QoS 1/2 don’t help if broker is unreachable)
Subscribers disconnect and enter retry loop, showing stale data in dashboards
Critical alerts missed: Fire alarm sensor can’t notify emergency system
Recovery surge: When broker restarts, 500 devices reconnect simultaneously, potentially overwhelming it again

Lessons learned:

For critical IoT: Use clustered brokers with high availability (HiveMQ, AWS IoT Core, Azure IoT Hub)
Local buffering: Implement client-side message queues that store-and-forward when connection restores
Hybrid approach: Run a local backup broker that syncs with cloud when available
Graceful degradation: Design devices to work autonomously when disconnected
Monitoring: Set up broker health checks and automatic failover

Best practice: For production systems, never rely on a single broker. Use at least 2 brokers behind a load balancer, or a managed cloud service with built-in redundancy.

🏷️ Label the Diagram

💻 Code Challenge

20.16 Summary and Key Takeaways

20.16.1 What You Learned

This chapter covered MQTT Quality of Service levels - the mechanism that controls message delivery guarantees between publishers, brokers, and subscribers.

MQTT QoS level summary — MQTT QoS summary

20.16.2 Key Takeaways

One-Sentence Summary

MQTT QoS levels let you trade message reliability for battery life: use QoS 0 for replaceable telemetry (95% of IoT), QoS 1 for important events, and QoS 2 only for critical non-idempotent commands.

Essential Points to Remember:

QoS 0 (“fire and forget”) - Fastest, lowest battery, but messages may be lost. Use for frequent, replaceable sensor data.
QoS 1 (“at least once”) - Guaranteed delivery with possible duplicates. Use for important events where duplicates are acceptable.
QoS 2 (“exactly once”) - Perfect delivery with four-way handshake. Use only when duplicates cause real problems (payments, medication dispensing).
Battery impact is dramatic - QoS 0 gives ~3x longer battery life than QoS 2 on the same message rate.
QoS guarantees are hop-by-hop - Publisher to Broker and Broker to Subscriber are independent. Offline subscribers miss messages unless retained.
Design for idempotency - Most QoS 2 needs can be avoided by designing commands that are safe to receive multiple times (set_state: on instead of toggle).

20.16.3 Quick Reference

QoS	Messages	Latency	Battery Impact	Use Case
0	2	~8ms	1x (baseline)	Temperature every minute
1	4	~24ms	2x	Door opened alert
2	8	~67ms	3x	Payment transaction

20.16.4 Practical Recommendations

For most IoT deployments:

Start with QoS 0 for all telemetry data
Use QoS 1 only for events that trigger human action (alerts, alarms)
Avoid QoS 2 unless you’ve confirmed the operation is truly non-idempotent
Implement application-level acknowledgments for true end-to-end confirmation
Use clustered brokers or managed cloud services for production systems

20.17 What’s Next

Chapter	Focus	Why Read It
MQTT Security	TLS encryption, client authentication, and access control lists	Apply QoS knowledge to secure channels — delivery guarantees are meaningless if messages can be intercepted
MQTT Architecture	Broker internals, pub-sub topology, and session management	Understand how the broker stores retained messages and persistent sessions that QoS levels depend on
MQTT Topics & Wildcards	Topic hierarchy design and wildcard subscriptions	Well-designed topic trees let you apply different QoS levels per topic type (telemetry vs. commands)
MQTT Labs	Hands-on QoS experiments with Mosquitto and ESP32	Measure battery impact and message loss directly on hardware using the scenarios from this chapter
CoAP Fundamentals	Alternative lightweight protocol with confirmable and non-confirmable message modes	Compare MQTT QoS with CoAP’s reliability model to select the right protocol for constrained devices
Transport Protocols Overview	TCP, UDP, and DTLS as the underlying transport for MQTT and CoAP	Understand how the transport layer interacts with application-layer QoS guarantees