25  MQTT QoS Worked Examples

In 60 Seconds

Selecting the right MQTT QoS level requires analyzing each message type’s criticality, replacement frequency, and power budget. This chapter walks through real-world worked examples including fleet tracking (GPS at QoS 0, delivery confirmations at QoS 2), calculates the battery and bandwidth impact of each choice, and demonstrates adaptive QoS patterns that adjust reliability dynamically based on network conditions.

Prerequisites: MQTT QoS Fundamentals | MQTT QoS Levels | MQTT Session Management

This enables: MQTT Comprehensive Review | MQTT Labs and Implementation

25.1 Learning Objectives

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

  • Apply QoS Selection Frameworks: Apply systematic decision criteria to assign QoS levels to real-world message types based on criticality and duplicate tolerance
  • Calculate Resource Impact: Calculate battery consumption, bandwidth overhead, and broker data costs for each QoS level across fleet-scale deployments
  • Design Session Strategies: Design and configure persistent MQTT sessions for sleeping and intermittently connected IoT devices
  • Implement Adaptive QoS Patterns: Implement store-and-forward and adaptive QoS strategies that respond to network conditions and device duty cycles
  • Evaluate Trade-offs: Evaluate and justify QoS selections by comparing reliability guarantees against energy and bandwidth costs with worked numerical examples
  • Distinguish QoS Semantics: Distinguish between publisher-to-broker and broker-to-subscriber QoS segments, and diagnose mismatches that silently downgrade delivery guarantees
  • 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

25.2 For Beginners: MQTT QoS Examples

Worked examples show MQTT QoS in action with realistic scenarios – a temperature sensor that can afford to miss occasional readings (QoS 0), a door lock that must confirm every command (QoS 1), and a billing system that cannot process the same transaction twice (QoS 2). Seeing the concepts in context makes them click.

“Let me walk through three real scenarios,” said Max the Microcontroller. “Scenario 1: Sammy reports outdoor temperature every 5 minutes. If one reading gets lost, the next one comes 5 minutes later. Use QoS 0 – no acknowledgments needed, minimum battery drain.”

“Scenario 2,” said Sammy the Sensor. “A smart door lock receives ‘LOCK’ and ‘UNLOCK’ commands. Missing a command means the door stays in the wrong state. Use QoS 1 – the broker retries until the lock acknowledges. Getting ‘LOCK’ twice on an already-locked door? Harmless. Missing ‘LOCK’ entirely? Dangerous.”

Lila the LED presented the toughest case: “Scenario 3: an electric meter reports energy usage for billing. If the message arrives twice, the customer gets charged double. If it doesn’t arrive, the utility loses revenue. This demands QoS 2 – the four-step handshake guarantees exactly one delivery. Yes, it’s slower. But when money is on the line, you need that guarantee.”

Bella the Battery summarized: “Weather data = QoS 0. Safety commands = QoS 1. Financial transactions = QoS 2. The worked examples in this chapter show you exactly what happens at each step, with real packet diagrams!”

Foundations:

Hands-On:

25.3 Worked Example: Fleet Tracking QoS Selection

25.4 Fleet Tracking Scenario

Scenario: You are designing the messaging system for a logistics company tracking 500 delivery trucks. Each truck sends various message types: GPS location updates, delivery confirmations, driver alerts, and fuel level readings. The system uses cellular connectivity which has variable reliability (3G/4G coverage varies by location).

Goal: Select the optimal QoS level for each message type, balancing reliability, battery consumption, and data costs.

What we do: List all message types and their characteristics.

Why: Different messages have different reliability requirements and tolerance for duplicates.

Message inventory:

Message Type Frequency Critical? Duplicate Impact Loss Impact
GPS location Every 30s No OK (shows same position) Minor (next update in 30s)
Delivery confirmed Per delivery Yes Bad (double billing possible) Bad (customer not notified)
Driver panic alert Rare (emergency) Critical OK (better safe than sorry) Catastrophic (safety at risk)
Fuel level Every 10 min No OK (harmless) Minor (trend data only)
Speed violation When detected Yes Minor (alarm duplication) Bad (safety compliance)

For 500 trucks sending messages over cellular (100ms RTT, $0.10/MB data):

GPS location (1 msg/30s per truck):

  • Message size: 40 bytes payload + 12 bytes MQTT header = 52 bytes
  • QoS 0: 1 packet = 52 bytes
  • QoS 1: 2 packets (PUBLISH + PUBACK) = 104 bytes
  • Daily cost QoS 0: \(500 \times 2,880 \times 52 / 1,000,000 \times \$0.10 = \$7.49\)
  • Daily cost QoS 1: \(500 \times 2,880 \times 104 / 1,000,000 \times \$0.10 = \$14.98\)

Delivery confirmation (8 deliveries/truck/day):

  • Message size: 120 bytes payload + 12 bytes header = 132 bytes
  • QoS 2: 4 packets = 528 bytes per confirmation
  • Daily cost: \(500 \times 8 \times 528 / 1,000,000 \times \$0.10 = \$0.21\)

Total monthly cost comparison:

  • GPS at QoS 0 + confirmations at QoS 2: \((7.49 + 0.21) \times 30 = \$231\)
  • GPS at QoS 1 + confirmations at QoS 2: \((14.98 + 0.21) \times 30 = \$456\)
  • All QoS 2: \(((500 \times 2,880 \times 208) + (500 \times 8 \times 528)) / 1,000,000 \times 0.10 \times 30 = \$906\)

Energy comparison (GPS messages only, 3000 mAh battery):

  • QoS 0: \(2,880 \times 0.4\text{ mAs} = 0.32\text{ mAh/day}\) → 9,375 days
  • QoS 1: \(2,880 \times 0.65\text{ mAs} = 0.52\text{ mAh/day}\) → 5,769 days
  • QoS 2: \(2,880 \times 1.3\text{ mAs} = 1.04\text{ mAh/day}\) → 2,885 days

Takeaway: Using QoS 0 for GPS and QoS 2 only for critical confirmations saves $225/month ($2,700/year) and doubles battery life vs all-QoS-2.

What we do: Match each message type to the appropriate QoS level using the decision criteria.

Why: The framework ensures consistent, justified decisions rather than guessing.

Decision questions:

  1. Can we afford to lose this message? (Yes -> QoS 0, No -> Continue)
  2. Would duplicates cause problems? (No -> QoS 1, Yes -> QoS 2)

Analysis per message type:

GPS QoS decision flow

What we do: Quantify the battery, bandwidth, and cost impact of our QoS choices.

Why: Understanding the trade-offs helps justify decisions and optimize where possible.

Message overhead calculation:

Message Type Count/Day QoS Messages/Msg Total Msgs/Day
GPS location 2,880 0 1 2,880
Delivery confirmed 50 2 4 200
Panic alert ~0.1 1 2 ~0.2
Fuel level 144 0 1 144
Speed violation ~10 1 2 20
Total 3,084 - - 3,244

Overhead analysis:

  • If everything were QoS 0: 3,084 messages/day
  • With our QoS choices: 3,244 messages/day (+5.2% overhead)
  • If everything were QoS 2: 12,336 messages/day (+300% overhead)

Cellular data impact (assuming 100 bytes/message): - Our design: 3,244 x 100 = 324 KB/day per truck - 500 trucks x 324 KB x 30 days = 4.7 GB/month - All QoS 2: 18.5 GB/month (4x higher data cost)

What we do: Consider scenarios that might require QoS adjustments.

Why: Real-world conditions may differ from typical operation.

Edge case: Poor cellular coverage

When truck enters area with weak signal:

# Pseudo-code for adaptive QoS
def get_gps_qos(signal_strength, time_since_last_update):
    if time_since_last_update > 300:  # 5 min since last successful
        return QOS_1  # Promote GPS to QoS 1 (need confirmation)
    elif signal_strength < -110:  # Very weak signal
        return QOS_1  # Upgrade to ensure delivery
    else:
        return QOS_0  # Normal operation

Edge case: Delivery confirmation retry

If QoS 2 handshake fails after 3 attempts:

# Store-and-forward pattern
def confirm_delivery(delivery_id, mqtt_client):
    for attempt in range(3):
        result = mqtt_client.publish(
            f"fleet/truck123/delivery/{delivery_id}/confirmed",
            payload=confirmation_data,
            qos=2,
            timeout=10
        )
        if result.is_published():
            return True
        time.sleep(5 * (2 ** attempt))  # Exponential backoff

    # Store locally for later sync
    local_buffer.save(delivery_id, confirmation_data)
    return False

Outcome: Optimized QoS configuration balancing reliability and efficiency.

Final QoS assignments:

Message Type QoS Rationale
GPS location 0 High frequency, loss acceptable, next update imminent
Delivery confirmed 2 Business-critical, duplicates cause billing issues
Driver panic alert 1 Safety-critical, duplicates acceptable, speed matters
Fuel level 0 Trend data only, interpolatable, battery savings
Speed violation 1 Compliance record needed, duplicates minor annoyance

Key design decisions:

  1. 95% of messages use QoS 0 - GPS and fuel readings dominate volume
  2. QoS 2 only where duplicates cause harm - Delivery confirmation (billing)
  3. QoS 1 for safety events - Reliability without QoS 2 latency overhead
  4. Adaptive QoS in poor coverage - Promote GPS to QoS 1 when stale
  5. Local buffering - Store failed deliveries for eventual consistency

Cost-benefit summary:

  • Battery: 5.2% more messages than all-QoS-0 (acceptable for reliability)
  • Data cost: 4.7 GB/month vs 18.5 GB if all-QoS-2 (75% savings)
  • Reliability: Critical messages guaranteed, non-critical efficiently sent

25.5 Worked Example: Smart Door Lock QoS Selection

Smart Door Lock Scenario

Scenario: A commercial building deploys 50 smart door locks that must respond to unlock commands from a mobile app. The security team needs to ensure commands are executed reliably while minimizing battery drain on battery-backup locks.

Given:

  • 50 door locks, each with 4x AA battery backup (2,400 mAh total at 6V)
  • Unlock commands: ~200 per lock per day (employees entering/exiting)
  • Status updates: locks publish state every 30 seconds
  • Network: Enterprise Wi-Fi with 2% packet loss
  • Critical requirement: No duplicate unlock commands (security audit trail)
  • MQTT packet overhead: QoS 0 = 2 bytes, QoS 1 = 4 bytes, QoS 2 = 6 bytes

Steps:

  1. Analyze message types and requirements:
    • Unlock commands (app to lock): Cannot duplicate (audit issues), must confirm execution
    • Lock state (lock to app): Current status, duplicates harmless, high frequency
    • Battery alerts (lock to app): Important but duplicates acceptable
  2. Calculate QoS overhead for unlock commands (200/day):
    • QoS 1: PUBLISH (4 bytes) + PUBACK (4 bytes) = 8 bytes, 2 messages
    • QoS 2: PUBLISH + PUBREC + PUBREL + PUBCOMP = 24 bytes, 4 messages
    • With 2% packet loss, QoS 1 has 2% chance of duplicate per command
    • Daily duplicate risk with QoS 1: 200 x 0.02 = 4 potential duplicate unlocks
  3. Calculate energy impact per command:
    • Radio power: 80 mA active, 6V supply
    • Message transmission: 5 ms per message at 250 kbps
    • QoS 1 energy: 80 mA x 6V x 0.01s (2 msgs x 5ms) = 4.8 mJ per command
    • QoS 2 energy: 80 mA x 6V x 0.02s (4 msgs x 5ms) = 9.6 mJ per command
  4. Calculate daily energy for commands:
    • QoS 1: 200 commands x 4.8 mJ = 960 mJ = 0.96 J/day for commands
    • QoS 2: 200 commands x 9.6 mJ = 1,920 mJ = 1.92 J/day for commands
    • Additional QoS 2 cost: 0.96 J/day
  5. Calculate status message energy (2,880/day at 30-sec intervals):
    • Using QoS 0 (fire-and-forget): 2 bytes overhead, 1 message
    • Energy per status: 80 mA x 6V x 0.005s = 2.4 mJ
    • Daily status energy: 2,880 x 2.4 mJ = 6.9 J/day
  6. Calculate total battery life:
    • Battery capacity: 2,400 mAh x 6V = 14.4 Wh = 51,840 J
    • Daily consumption (QoS 2 commands + QoS 0 status): 1.92 + 6.9 = 8.82 J/day
    • Battery backup duration: 51,840 J / 8.82 J/day = 5,877 days = 16 years

Result: Use QoS 2 for unlock commands (zero duplicates, audit compliance) and QoS 0 for status updates (high frequency, duplicates harmless). Daily energy cost is 8.82 J, providing 16 years of battery backup. The additional 0.96 J/day for QoS 2 commands (vs QoS 1) is negligible compared to status message energy.

Key Insight: QoS 2’s 2x energy overhead (9.6 mJ vs 4.8 mJ per command) seems expensive, but commands represent only 22% of daily energy (1.92 J / 8.82 J). Status updates dominate at 78%. For security-critical commands where duplicates cause audit violations, QoS 2’s guarantee is worth the modest energy cost. Never use QoS 1 for commands where duplicates have real-world consequences.

25.6 Worked Example: Persistent Session Sizing

Fleet Session Sizing Scenario

Scenario: A logistics company manages 1,000 delivery trucks, each with an MQTT client that sleeps during overnight hours. The broker must queue messages for offline trucks and deliver them when trucks reconnect in the morning.

Given:

  • 1,000 trucks, each offline 10 hours/night (10 PM to 8 AM)
  • During offline period, central system sends:
    • Route updates: 1 per truck, 2 KB payload
    • Delivery manifests: 5 per truck, 500 bytes each
    • System alerts: 20 total (broadcast), 100 bytes each
  • Persistent session enabled (Clean Session = false)
  • QoS 1 for all queued messages (delivery confirmation required)
  • Broker: EMQX with 16 GB RAM

Steps:

  1. Calculate per-truck queued message volume:
    • Route updates: 1 x 2,048 bytes = 2,048 bytes
    • Delivery manifests: 5 x 500 bytes = 2,500 bytes
    • System alerts: 20 x 100 bytes = 2,000 bytes
    • Total per truck: 6,548 bytes = 6.4 KB
  2. Calculate total broker queue memory:
    • Message storage: 1,000 trucks x 6.4 KB = 6.4 MB payload data
    • MQTT metadata per message: 200 bytes (topic, QoS, timestamp, client ID reference)
    • Messages per truck: 1 + 5 + 20 = 26 messages
    • Metadata total: 1,000 trucks x 26 messages x 200 bytes = 5.2 MB
    • Queue memory: 6.4 MB + 5.2 MB = 11.6 MB
  3. Calculate persistent session state memory:
    • Per-session overhead: 5 KB (client ID, subscriptions, connection metadata)
    • Session state: 1,000 trucks x 5 KB = 5 MB
    • Total session memory: 5 MB + 11.6 MB = 16.6 MB
  4. Calculate reconnection storm impact:
    • All 1,000 trucks reconnect between 7:50-8:10 AM (20-minute window)
    • Connection rate: 1,000 / 20 minutes = 50 connections/minute = 0.83/second
    • Queued message delivery: 26,000 messages in 20 minutes = 1,300 msg/min = 22 msg/sec
    • Average message size: 6,548 bytes / 26 messages = 252 bytes/msg
    • Peak bandwidth: 22 msg/sec x 252 bytes/msg = 5.5 KB/sec = 44 kbps
  5. Verify broker capacity:
    • EMQX memory usage: 16.6 MB / 16 GB = 0.1% (well within limits)
    • Connection handling: 50/minute is trivial (EMQX handles 10,000/sec)
    • Message throughput: 22 msg/sec is trivial (EMQX handles 100,000/sec)
  6. Calculate queue expiry settings:
    • Maximum offline period: 10 hours
    • Safety margin: 2x = 20 hours
    • Recommended message_expiry_interval: 72,000 seconds (20 hours)
    • Disk spillover threshold: 100 MB (current 16.6 MB is 16% of threshold)

Result: Persistent sessions for 1,000 trucks require only 16.6 MB broker memory, handling 26,000 queued messages during 10-hour offline periods. Morning reconnection storm (50/minute) and message delivery (22 msg/sec) are within 1% of broker capacity. Set message expiry to 20 hours and disk spillover at 100 MB.

Key Insight: Persistent sessions seem expensive but scale efficiently - 1,000 trucks need only 16.6 MB total. The real cost is reconnection storms: when trucks reconnect simultaneously, message delivery spikes. Stagger reconnection times (e.g., random 0-10 minute delay) to spread load. Without persistent sessions, trucks would miss route updates and require manual re-sync, costing far more in operational overhead than the 16.6 MB memory investment.

25.7 Worked Example: Medical Device Telemetry

Medical Telemetry Scenario

Scenario: A hospital deploys 100 patient monitors that transmit vital signs (heart rate, blood oxygen, blood pressure) to a central monitoring station. Nurses need real-time alerts for critical values, and all readings must be logged for medical records. You must select appropriate QoS levels balancing reliability with device battery life.

Given:

  • 100 patient monitors, battery-powered (1,500 mAh, 3.7V Li-ion)
  • Vital sign readings: 3 parameters x 1 reading/second = 3 msg/sec per device
  • Critical alert threshold: heart rate < 50 or > 120 BPM triggers immediate alert
  • Regulatory requirement: all vital signs must be logged (no data loss for records)
  • Network: Hospital Wi-Fi with 0.5% packet loss
  • Device radio power: 120 mA transmit, 15 mA idle
  • Message transmission time: 8 ms for QoS 0, 25 ms for QoS 1, 50 ms for QoS 2

Steps:

  1. Categorize message types by criticality:
    • Routine vitals (99% of messages): Regular readings within normal range
    • Critical alerts (<1% of messages): Out-of-range values requiring immediate attention
    • Acknowledgment requests (rare): Nurse confirms alert received
  2. Analyze delivery requirements per message type:

Routine vitals QoS flow

  1. Calculate energy consumption per QoS level:
    • QoS 0 energy: 120 mA x 8 ms = 0.96 mAs per message
    • QoS 1 energy: 120 mA x 25 ms = 3.0 mAs per message
    • QoS 2 energy: 120 mA x 50 ms = 6.0 mAs per message
  2. Calculate daily energy with mixed QoS strategy:
    • Routine vitals (QoS 0): 3 msg/sec x 86,400 sec x 0.96 mAs = 248,832 mAs = 69.1 mAh
    • Critical alerts (QoS 1): 10 alerts/day x 3.0 mAs = 30 mAs = 0.008 mAh
    • Acknowledgments (QoS 2): 10/day x 6.0 mAs = 60 mAs = 0.017 mAh
    • Total daily: 69.1 mAh for MQTT transmission
    • Battery life (1,500 mAh, 50% for MQTT): 750 / 69.1 = 10.9 days
  3. Compare with all-QoS-1 approach (regulatory conservative):
    • All messages QoS 1: 259,200 msg/day x 3.0 mAs = 777,600 mAs = 216 mAh
    • Battery life: 750 / 216 = 3.5 days (3x more frequent charging)
  4. Address logging requirement (no data loss):
    • Use persistent session (Clean Session = false) for historian subscriber
    • Broker queues missed messages during historian restarts
    • Historian publishes acknowledgment after writing to database
    • If historian offline > 1 hour, alert IT staff (not QoS problem)

Result: Use QoS 0 for routine vital signs (99% of traffic), QoS 1 for critical alerts, and QoS 2 for nurse acknowledgments. This mixed strategy provides 10.9 days battery life versus 3.5 days with all-QoS-1. Regulatory logging is ensured by persistent sessions on the historian subscriber, not by upgrading publisher QoS.

Key Insight: QoS selection should be per-message-type, not per-device. Critical alerts representing <1% of traffic can use QoS 1 without significantly impacting battery life. The logging requirement (no data loss) is solved at the subscriber side with persistent sessions, not by forcing publishers to use higher QoS. Never use QoS 2 for high-frequency telemetry - the 6x energy cost destroys battery life. Reserve QoS 2 for rare, non-idempotent operations like acknowledgments where duplicate confusion matters.

25.8 Worked Example: Sleep-Wake Sensor Sessions

Sleep-Wake Sensor Scenario

Scenario: An agricultural monitoring system uses 200 soil moisture sensors that sleep for 55 minutes, wake for 5 minutes to transmit data and receive commands, then return to sleep. Sensors must receive any pending irrigation commands issued while they were asleep.

Given:

  • 200 sensors with solar-powered batteries
  • Sleep/wake cycle: 55 min sleep, 5 min active (5/60 duty cycle = 8.3%)
  • During active period: publish 3 readings, check for commands
  • Commands issued centrally: ~50 per day total across all sensors
  • Command types: calibrate (safe to duplicate), irrigate (must not duplicate)
  • Broker: Mosquitto with persistent message storage enabled
  • Maximum acceptable command delay: 60 minutes (one full cycle)

Steps:

  1. Configure session persistence for each sensor:

    // ESP32 sensor MQTT configuration
const char* clientId = "sensor-042";  // Stable ID (from chip MAC)
bool cleanSession = false;  // Persistent session - broker saves subscriptions

// Subscribe to command topic on every wake
client.subscribe("farm/zone-b/sensor-042/command", 1);  // QoS 1

  2. Calculate broker session storage per sensor:

    • Session state: 5 KB (client ID, subscriptions, connection metadata)
    • Queued commands during sleep: avg 0.25 commands x 200 bytes = 50 bytes
    • Total per sensor: 5.05 KB
    • Total for 200 sensors: 1,010 KB = 1 MB

  3. Calculate message queue depth requirements:

    • Commands per sensor per sleep cycle: 50 commands/day / 200 sensors / 24 cycles = 0.01 per cycle
    • Maximum queue (worst case all to one sensor): 5 commands
    • Mosquitto setting: max_queued_messages 10 (per client)

  4. Design command delivery flow:

    Central system issues command at 10:15 AM:
"farm/zone-b/sensor-042/command" = "{"action":"irrigate","duration":300}"

Sensor-042 timeline:
10:00 AM - Goes to sleep
10:15 AM - Command arrives, broker queues it (sensor offline)
10:55 AM - Sensor wakes, connects with same clientId
10:55 AM - Broker detects persistent session, sends queued command
10:55 AM - Sensor receives command, starts irrigation
10:56 AM - Sensor publishes confirmation, goes back to sleep

Latency: 40 minutes (acceptable, within 60-min requirement)

  5. Handle QoS for different command types:

    # Central command publisher

# Calibrate command - QoS 1 (duplicates safe, sensor recalibrates)
client.publish("farm/zone-b/sensor-042/command",
               '{"action":"calibrate","value":2.5}',
               qos=1, retain=False)

# Irrigate command - QoS 2 (duplicates waste water, damage crops)
client.publish("farm/zone-b/sensor-042/command",
               '{"action":"irrigate","duration":300}',
               qos=2, retain=False)

  6. Calculate session expiry settings:

    • Maximum offline time: 55 minutes (normal sleep)
    • Safety margin for extended sleep (low battery): 24 hours
    • Mosquitto setting: persistent_client_expiration 1d
    • MQTT 5.0: Session Expiry Interval: 86400 (24 hours)

  7. Handle sensor replacement scenario:

    # When replacing sensor hardware, clear old session
def decommission_sensor(sensor_id):
    # Connect with same clientId, clean session to clear state
    temp_client = mqtt.Client(client_id=sensor_id, clean_session=True)
    temp_client.connect(broker, port)
    temp_client.disconnect()
    # Old session cleared, queued messages discarded
    print(f"Session cleared for {sensor_id}")

Result: Configure sensors with Clean Session = false and stable client IDs derived from hardware MAC. Broker queues commands during 55-minute sleep periods, delivering them when sensors wake. Use QoS 1 for idempotent commands (calibrate) and QoS 2 for non-idempotent commands (irrigate). Set session expiry to 24 hours to handle extended low-battery sleep. Total broker memory for 200 sensors: ~1 MB.

Key Insight: Persistent sessions transform MQTT into a store-and-forward system for sleeping devices. The key requirements are: (1) stable client IDs - random IDs break session restoration, (2) subscribe on every wake - subscriptions persist but re-subscribing is harmless and handles broker restarts, (3) match QoS to command idempotency - irrigate twice wastes water while calibrate twice is harmless. Without persistent sessions, sensors would need to poll for commands or miss them entirely, requiring complex application-level queuing that MQTT already provides for free.

Common Mistake: Assuming QoS Level is End-to-End

The mistake: Developers set QoS 2 on the publisher and assume messages are delivered exactly-once to all subscribers, regardless of subscriber QoS settings.

Why it’s wrong: MQTT QoS is NOT end-to-end – it operates independently on two segments: 1. Publisher → Broker (governed by publisher’s QoS) 2. Broker → Subscriber (governed by minimum of publisher QoS and subscriber QoS)

Effective QoS = min(publisher_qos, subscriber_qos)

Real-world impact example:

  • Factory publishes emergency stop command with QoS 2 (exactly-once)
  • PLC-A subscribes with QoS 2 → receives exactly-once (correct)
  • PLC-B subscribes with QoS 0 (default) → receives at-most-once (may lose message!)
  • Dashboard subscribes with QoS 1 → receives at-least-once (may duplicate, triggers double alarm)

The fix:

# Publisher sets QoS 2 for critical command
client.publish("factory/emergency_stop", "STOP_ALL", qos=2)

# EVERY subscriber MUST match the required QoS
plc_a.subscribe("factory/emergency_stop", qos=2)  # Critical safety system
plc_b.subscribe("factory/emergency_stop", qos=2)  # NOT qos=0!
dashboard.subscribe("factory/emergency_stop", qos=2)  # Display needs consistency

Key insight: Document required subscriber QoS in your API specification. Failing to match QoS on the subscriber side silently downgrades delivery guarantees, causing bugs that only appear under specific network conditions.

Quick Check: End-to-End QoS

25.9 Interactive Calculators

25.9.1 Fleet QoS Data Cost Calculator

Compare monthly cellular data costs for a fleet of vehicles under different QoS assignment strategies. Adjust the fleet size, message rates, and payload sizes to see how QoS choices impact your data budget.

25.9.2 QoS Battery Life Estimator

Calculate how long a battery-powered IoT device will last under different QoS configurations. This calculator models the energy cost per MQTT transaction for each QoS level.

25.9.3 Broker Session Memory Calculator

Size the broker memory requirements for persistent MQTT sessions. Model how many devices, queued messages, and metadata overhead your broker must handle during offline periods.

25.9.4 Mixed-QoS Energy Comparison

Compare battery life when using a mixed QoS strategy (QoS 0 for routine data, QoS 1 for alerts) versus a uniform QoS approach. This models the medical telemetry scenario where message frequency varies by type.

25.9.5 Sleep-Wake Queue Depth Calculator

Model the message queue requirements for duty-cycled sensors that sleep for extended periods. Calculate how many commands accumulate during sleep and the burst delivery rate at wake-up.

Common Pitfalls

QoS 2’s four-message handshake consumes 4× the bandwidth of QoS 0 and adds 2-4 roundtrips of latency — on a 2G connection this can mean 2-8 seconds per message. Reserve QoS 2 for irreplaceable commands (actuator control, firmware triggers); use QoS 1 for telemetry where occasional duplicates are acceptable.

MQTT QoS governs publisher-to-broker and broker-to-subscriber segments independently — QoS 1 from publisher to broker combined with QoS 0 subscription results in at-most-once overall. Always set both the publish QoS AND the subscribe QoS to the required level.

QoS 1 guarantees at-least-once delivery — when the broker does not receive PUBACK, it retransmits the message with dup=true flag. Applications storing sensor readings will create duplicate database entries unless they check message IDs or implement idempotent writes.

25.10 Summary

This chapter provided detailed worked examples for MQTT QoS and session configuration:

  • Fleet Tracking: 95% of messages use QoS 0 for efficiency, QoS 2 only for delivery confirmations where duplicates cause billing issues, QoS 1 for safety alerts where speed matters more than duplicate prevention
  • Smart Door Locks: QoS 2 for unlock commands (audit compliance, no duplicates), QoS 0 for status updates (high frequency, duplicates harmless), battery impact is dominated by status messages not commands
  • Fleet Session Sizing: 1,000 trucks need only 16.6 MB broker memory, reconnection storms are the real challenge, stagger reconnections with random delays
  • Medical Telemetry: Mixed QoS by message type provides 3x better battery life than uniform QoS 1, logging requirements are solved at subscriber side with persistent sessions
  • Sleep-Wake Sensors: Persistent sessions enable store-and-forward for sleeping devices, stable client IDs are critical, QoS matches command idempotency

25.11 Knowledge Check

25.12 What’s Next

Chapter Focus Why Read It
MQTT Labs and Implementation Hands-on ESP32 and Python MQTT projects Apply the QoS selection principles from this chapter in real code with DHT22 sensors, dashboards, and TLS-secured brokers
MQTT Comprehensive Review Full MQTT protocol consolidation Consolidate QoS, session, and topic knowledge before moving to protocol integration
MQTT QoS Fundamentals Core QoS concepts and decision rules Revisit the foundational QoS decision framework that underpins all five worked examples here
MQTT QoS Levels Technical handshake mechanics per QoS level Understand the exact packet exchanges (PUBACK, PUBREC, PUBREL, PUBCOMP) that drive the energy and latency costs calculated in this chapter
MQTT Session Management Persistent session configuration and lifecycle Deepen understanding of the persistent session patterns used in the fleet and sleep-wake worked examples
CoAP Protocol Constrained Application Protocol Compare MQTT QoS with CoAP’s confirmable/non-confirmable message model for ultra-constrained devices