1197  MQTT Quality of Service (QoS) Levels

1197.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.

1197.2 Learning Objectives

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

• Compare QoS Levels: Understand the trade-offs between QoS 0, 1, and 2
• Choose Appropriate QoS: Select the right level for different IoT scenarios
• Optimize Battery Life: Minimize power consumption through QoS selection
• Handle Delivery Guarantees: Design systems that work with QoS limitations

1197.3 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

Figure 1197.1: MQTT QoS 0: At most once delivery (fire and forget)

Figure 1197.2: MQTT QoS 1: At least once delivery with acknowledgment

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

1197.4 Deep Dive: QoS Implementation Details

NoteDeep 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 (6 messages total):

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

• Four-way handshake guarantees exactly-once delivery
• Broker and publisher maintain state until PUBCOMP
• Latency: ~40-80ms
• Packet overhead: 6 bytes
• Battery impact: 3x transmissions
• State overhead: Both sides store transaction state (memory cost)

Real-World Performance Measurements:

On ESP32 with Wi-Fi (2.4GHz, -60 dBm signal strength):

Metric	QoS 0	QoS 1	QoS 2
Latency (avg)	8ms	24ms	67ms
Messages/sec	5000	2000	800
Battery life (CR2032, 1 msg/min)	520 days	260 days	173 days
Reliability (stable Wi-Fi)	99.8%	99.99%	100%
Reliability (unstable Wi-Fi)	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.

1197.5 Knowledge Checks

{
  const container = document.getElementById('kc-mqtt-7');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A battery-powered soil moisture sensor in a farm field publishes readings every 30 seconds. The current battery lasts only 3 weeks. After investigation, the developer discovers QoS 1 is being used. If they switch to QoS 0, approximately how much longer will the battery last?",
      options: [
        {text: "No significant difference - QoS levels don't affect battery life", correct: false, feedback: "Incorrect. QoS levels significantly impact battery consumption. QoS 1 requires waiting for PUBACK acknowledgment (keeping radio on longer), while QoS 0 is fire-and-forget with minimal radio time."},
        {text: "About 2x longer (6 weeks) because QoS 0 doesn't wait for acknowledgment", correct: true, feedback: "Correct! QoS 0 requires only one transmission and no waiting for acknowledgment, roughly halving the radio-on time per message. Real-world measurements show QoS 0 can extend battery life 2-3x compared to QoS 1. For non-critical telemetry like soil moisture (where the next reading comes in 30 seconds anyway), QoS 0 is the right choice."},
        {text: "About 10x longer because QoS 0 uses 10% of the bandwidth", correct: false, feedback: "While QoS 0 does use less bandwidth (no acknowledgment packets), the battery savings are typically 2-3x, not 10x. Most of the energy is consumed by the radio transmission itself, which still occurs for each message."},
        {text: "Slightly longer, but the risk of lost data isn't worth it", correct: false, feedback: "For redundant telemetry data like soil moisture readings every 30 seconds, occasional message loss is acceptable - the next reading arrives shortly anyway. The 2-3x battery improvement is definitely worth it for this use case."}
      ],
      difficulty: "medium",
      topic: "mqtt-qos"
    }));
  }
}

{
  const container = document.getElementById('kc-mqtt-8');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A smart irrigation system sends 'open_valve' commands to water crops. Using QoS 1, sometimes the valve opens twice in quick succession (receiving the command twice), wasting water. A developer suggests switching to QoS 2 to fix this. What is the BEST solution?",
      options: [
        {text: "Switch to QoS 2 - it guarantees exactly-once delivery and will prevent duplicates", correct: false, feedback: "While QoS 2 does prevent protocol-level duplicates, it adds significant latency (4-way handshake) and complexity. The better solution is designing idempotent commands that are safe to receive multiple times."},
        {text: "Keep QoS 1 but redesign the command to be idempotent: 'set_valve_state: open' instead of 'open_valve'", correct: true, feedback: "Correct! Idempotent commands are safe to receive multiple times - setting valve state to 'open' twice still results in an open valve. This is simpler, faster (no 4-way handshake), and works even if application-level retries occur. QoS 2 adds overhead without addressing the root design issue."},
        {text: "Switch to QoS 0 - faster delivery means less chance of duplicates", correct: false, feedback: "Incorrect. QoS 0 doesn't cause duplicates (no retries), but it also provides no delivery guarantee. For critical commands like irrigation control, you need some reliability. The issue isn't the QoS level - it's the command design."},
        {text: "Add a sequence number to each command and have the valve ignore duplicates", correct: false, feedback: "While this could work, it adds unnecessary complexity. Idempotent command design (set_valve_state: open) is simpler and doesn't require state tracking on the device side."}
      ],
      difficulty: "hard",
      topic: "mqtt-qos"
    }));
  }
}

1197.6 Battery Life Considerations

TipChoosing the Right QoS Level for Battery Life

QoS level dramatically affects battery consumption. For a sensor sending data every 60 seconds:

• QoS 0: ~10 days battery life (minimal radio time)
• QoS 1: ~3 days battery life (waits for PUBACK acknowledgment)
• QoS 2: ~1.7 days battery life (four-way handshake overhead)

Best practice: Use QoS 0 for frequent, replaceable data (temperature every minute). Use QoS 1 only for important events (door opened, alarm triggered). Reserve QoS 2 for critical, non-idempotent commands (unlock door, dispense medication) where duplicates would cause serious problems.

WarningQoS 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.

WarningWhat 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: 1. Publishers keep trying to connect with exponential backoff (1s, 2s, 4s, 8s…) 2. Messages are lost unless devices implement local buffering (QoS 1/2 don’t help if broker is unreachable) 3. Subscribers disconnect and enter retry loop, showing stale data in dashboards 4. Critical alerts missed: Fire alarm sensor can’t notify emergency system 5. 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.

1197.7 Interactive MQTT Message Flow Simulator

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

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 = {
  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" : ""}`

NoteKey Insights from the Visualization

• QoS 0 offers highest throughput (5000 msg/sec) with minimal overhead
• QoS 1 balances reliability (99%) with reasonable performance (2000 msg/sec)
• QoS 2 guarantees 100% reliability but at significant cost to throughput (800 msg/sec) and battery life (1.7 days)

Recommendation: Use QoS 0 for frequent, replaceable sensor readings. Use QoS 1 for important events. Reserve QoS 2 only for critical, non-idempotent commands.

1197.8 QoS Decision Framework

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'fontSize': '12px'}}}%%
flowchart TD
    Start(["What type of<br/>message?"]) --> Q1{"Is data<br/>replaceable?"}

    Q1 -->|"Yes - next reading<br/>comes soon"| Q2{"Battery<br/>constrained?"}
    Q1 -->|"No - each message<br/>is important"| Q3{"Can handle<br/>duplicates?"}

    Q2 -->|"Yes"| QoS0["Use QoS 0<br/>Fire-and-forget"]
    Q2 -->|"No"| Q4{"Network<br/>unreliable?"}

    Q4 -->|"Yes (>5% loss)"| QoS1a["Use QoS 1<br/>At-least-once"]
    Q4 -->|"No (<5% loss)"| QoS0

    Q3 -->|"Yes - idempotent<br/>operations"| QoS1b["Use QoS 1<br/>At-least-once"]
    Q3 -->|"No - exactly-once<br/>required"| QoS2["Use QoS 2<br/>Exactly-once"]

    subgraph Examples["Use Case Examples"]
        Ex0["QoS 0: Temperature readings<br/>every 30 seconds"]
        Ex1["QoS 1: Door lock commands<br/>(can retry safely)"]
        Ex2["QoS 2: Payment transactions<br/>billing events"]
    end

    QoS0 -.-> Ex0
    QoS1a -.-> Ex1
    QoS1b -.-> Ex1
    QoS2 -.-> Ex2

    style Start fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style Q1 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Q2 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Q3 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Q4 fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style QoS0 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style QoS1a fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style QoS1b fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style QoS2 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Ex0 fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style Ex1 fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff
    style Ex2 fill:#7F8C8D,stroke:#2C3E50,stroke-width:1px,color:#fff

Figure 1197.4: Decision tree for selecting MQTT QoS levels based on message characteristics. Start by asking if data is replaceable (telemetry vs commands), then consider battery constraints and network reliability. Most IoT sensor data uses QoS 0, commands use QoS 1, and financial/critical operations use QoS 2.

1197.9 Battery Life Optimization Tips

TipBattery Life Optimization Tips

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

Example: Changing from QoS 2 @ 30s interval to QoS 0 @ 5min interval extends battery life from 6 days to 520 days!

1197.10 Retained Messages and Last Will Testament

{
  const container = document.getElementById('kc-mqtt-9');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A fleet management system monitors 500 delivery trucks. Each truck publishes its GPS location every 10 seconds to 'fleet/truck_XXX/location'. A new monitoring dashboard connects to the broker and needs to immediately display all trucks on a map. Without any special configuration, what will the dashboard see?",
      options: [
        {text: "All 500 truck locations immediately, because MQTT queues messages for new subscribers", correct: false, feedback: "Incorrect. MQTT doesn't automatically queue messages for future subscribers. New subscribers only receive messages published AFTER they subscribe - unless retained messages are used."},
        {text: "Nothing until each truck publishes its next location update (up to 10 seconds wait per truck)", correct: true, feedback: "Correct! Without retained messages, new subscribers only receive messages published after they subscribe. The dashboard would have to wait up to 10 seconds for each truck to publish its next update. This is why retained messages are valuable for state data."},
        {text: "The last 100 messages from the broker's message history", correct: false, feedback: "Incorrect. MQTT brokers don't automatically maintain message history for replay. You need retained messages (one per topic) or a separate message storage solution like a time-series database."},
        {text: "All messages from the last 24 hours if using QoS 1 or higher", correct: false, feedback: "Incorrect. QoS levels control delivery guarantees for connected subscribers, not message history. QoS 1/2 with persistent sessions only queue messages while a previously-connected client is offline."}
      ],
      difficulty: "medium",
      topic: "mqtt-retained"
    }));
  }
}

{
  const container = document.getElementById('kc-mqtt-10');
  if (container && typeof InlineKnowledgeCheck !== 'undefined') {
    container.innerHTML = '';
    container.appendChild(InlineKnowledgeCheck.create({
      question: "A factory has 100 temperature sensors. Each sensor's status (online/offline) is critical for maintenance planning. A sensor's Last Will Testament is configured to publish 'offline' to its status topic when it disconnects unexpectedly. One morning, a sensor crashes due to a power outage. What must be TRUE for the monitoring system to receive the 'offline' notification?",
      options: [
        {text: "The sensor must have set the LWT message as retained=true", correct: false, feedback: "While using retain=true is a best practice (so new subscribers see the status), it's not required for the LWT to be published. The broker will publish the LWT regardless of the retain flag - the question is about RECEIVING the notification."},
        {text: "The monitoring system must be connected and subscribed to the status topic when the broker publishes the LWT", correct: true, feedback: "Correct! The LWT is a regular MQTT message - it's only delivered to subscribers who are connected at the time. If the monitoring system is offline when the LWT fires, it won't receive the notification (unless the LWT is retained AND the system reconnects later)."},
        {text: "The sensor must have been using QoS 2 for all its messages", correct: false, feedback: "Incorrect. The QoS level of the sensor's regular messages doesn't affect LWT delivery. The LWT has its own QoS setting. The key requirement is that subscribers must be connected to receive non-retained messages."},
        {text: "The broker must have persistent sessions enabled for all clients", correct: false, feedback: "Incorrect. Persistent sessions help clients receive missed QoS 1/2 messages when reconnecting, but the monitoring system must still be subscribed. LWT publication happens once - if missed and not retained, it's gone."}
      ],
      difficulty: "hard",
      topic: "mqtt-lwt"
    }));
  }
}

1197.11 What’s Next

Continue to MQTT Security to learn about securing MQTT communications with TLS, authentication, and access control lists.

1197.12 See Also

• MQTT Architecture: Broker architecture and pub-sub pattern
• MQTT Topics & Wildcards: Topic design best practices
• MQTT Labs: Hands-on QoS experiments