MQTT · Study deck
MQTT QoS Levels
Picture a cold room that sends routine temperatures and a rare warm alarm.
Broker Bex is your guide for this deck.
After studying this chapter
Learning objectives
The right delivery contract depends on what losing or repeating a message would do.
- Different message families can need different delivery promises.The cold room sends replaceable routine temperatures and a rare warm alarm whose loss or repetition can change a safety decision.
- QoS 1 retries require duplicate-safe consumers.A lost PUBACK can lead to another PUBLISH, so an event identifier or desired-state command must make repeated handling safe.
- QoS 2 can control duplicate delivery on one protocol leg.Its longer handshake retains packet-identifier state at both peers until completion, adding packets, storage, and recovery work to the exchange.
- A physical outcome needs separate application evidence.The broker can acknowledge a valve command without proving valve movement, so the device must report its result or final state.
Major section
Start With The Consequence Of Losing One Message (1/2)
A routine temperature reading and a rare alarm protect different decisions.
- A fresh routine sample can replace a lost temperature reading.The cold-room decision may tolerate one missing value when the next sample arrives soon and the dashboard shows whether readings remain fresh.
- A missing alarm can change the response to a temperature problem.The rare warm alarm has different loss consequences from routine readings, so both families need their own documented delivery promises.
Major section
Start With The Consequence Of Losing One Message (2/2)
- Repeated events need safe handling in the receiving application.An important door-open event can use QoS 1 with an event identifier, allowing the consumer to recognize a repeat during retry.
- Failure tests must preserve the promised application outcome.Link cuts, repeated acknowledgements, broker restarts, and receiver reconnects expose losses, repeats, and delays that must match the cold-room policy.
Major section
Topic promises, safe commands, and state readback (1/2)
Message-family documentation connects QoS with useful evidence.
- Topic documentation connects delivery policy with tolerated loss and delay.The temperature topic uses QoS 0 and maximum staleness of 30 seconds to align firmware, broker policy, and dashboard expectations.
- Event identifiers make repeated alarm deliveries recognizable.The alarm topic declares QoS 1 and requires an event identifier, giving the consumer evidence for suppressing duplicates after a retry.
Major section
Topic promises, safe commands, and state readback (2/2)
- Desired-state commands make repeated handling safer than toggle actions.Replacing toggle_relay with set_relay_state=on avoids switching the relay twice when a QoS 1 retry brings the same command back.
- State readback closes the gap between delivery and device outcome.A command identifier and broker acknowledgement still leave the physical result unproven until the device reports its accepted or rejected state.
Major section
QoS Is Hop-by-Hop State (1/2)
This sequence shows the low-state delivery baseline before acknowledgement and retry are added.
- The first PUBLISH travels from publisher to broker without acknowledgement.The QoS 0 sequence has no return packet on that leg, leaving the publisher without protocol evidence that the broker received the publication.
- The next PUBLISH travels from broker to subscriber without acknowledgement.The second delivery leg also provides no QoS 0 receipt confirmation, so broker receipt alone cannot establish delivery to the subscribing application.
Major section
QoS Is Hop-by-Hop State (2/2)
- A lost QoS 0 publication can disappear silently.Neither leg confirms receipt in this sequence, making the low-state path suitable for replaceable telemetry rather than an unsupported must-arrive promise.
- Higher QoS levels add stored exchanges separately on each delivery leg.Publisher and subscriber delivery can use different effective QoS levels, so the broker handshake cannot establish an end-to-end physical or business outcome.
Major section
Choose QoS for a Valve Command and a Gauge (1/2)
This sequence connects a replaceable gauge reading with the cost of its delivery promise.
- The one-way PUBLISH path gives the gauge no receipt confirmation.The QoS 0 sequence contains no acknowledgement, so a missing gauge sample has no return packet that could prove successful receipt.
- The next gauge value can make one lost sample acceptable.At 60 readings per minute, the pressure gauge supplies a fresh value one second later, allowing a message-family policy to tolerate loss.
Major section
Choose QoS for a Valve Command and a Gauge (2/2)
- The rare valve command needs a separate duplicate-handling decision.A repeated OPEN action can be unsafe unless the application handles its command identifier idempotently, even when important telemetry shares the device.
- More handshake state leaves the physical action unproven.QoS 2 adds packets and stored session state for duplicate control at the MQTT layer, while the valve outcome still requires device evidence.
Major section
Packet identifiers, reconnects, and retained state (1/2)
Retained messages and unfinished handshakes are different broker responsibilities.
- Packet identifiers connect acknowledgements with the correct unfinished publication.Identifier 42 belongs to one in-flight exchange; using the same number for two unfinished exchanges would confuse which publication an acknowledgement completes.
- A completed exchange allows its packet identifier to be reused.Identifier 42 can be used again after its QoS exchange finishes, keeping packet-handshake identity distinct from an application command identifier.
Major section
Packet identifiers, reconnects, and retained state (2/2)
- Session settings determine which state survives reconnect.The valve tests need the chosen clean-start and expiry behaviour because a reconnect can change retained state and queued-message handling at the broker.
- A retained message does not upgrade its delivery handshake.A retained QoS 0 state remains a QoS 0 delivery choice; broker retention and unfinished handshake state are separate responsibilities.
Activity 1 · Predict
✎ Lose the acknowledgement
I want you to price the retry before you promise that the valve is safe.
On paper, send a QoS 1 valve command and lose its PUBACK. Predict what a repeated PUBLISH can do. Write one way to make repeated handling safe, then name evidence that proves the valve’s final state.
3 minutes · Pen and paper · Answer: Activity 1
8 seconds · Predict the retry, one safe handler, and one final-state record.
Major section
Summary (1/2)
A reliable application combines delivery contracts with safe handling and outcome evidence.
- QoS 0 reduces acknowledgement work for replaceable telemetry.A gauge value arriving each second can replace a lost sample, avoiding extra radio and broker work when the policy tolerates that loss.
- QoS 1 supports important events when consumers safely handle repeats.The door-open event needs delivery retries and an event identifier or idempotent processing so another delivery does not repeat the harmful effect.
Major section
Summary (2/2)
- QoS 2 adds duplicate-control state for narrowly justified delivery needs.Its multi-step handshake costs packets, storage, and recovery logic, so frequent replaceable gauge samples need a different review from rare valve commands.
- A device result must confirm the physical or business outcome.The broker/client delivery step cannot prove that a pump started, a door locked, or a technician responded to the requested action.
Deck summary
Key takeaways (1/2)
QoS policy belongs to each message family and must survive failure testing.
- Loss consequences determine the delivery promise for each message family.The cold room can tolerate a missing routine reading while a rare warm alarm needs a policy that protects the response decision.
- QoS 1 retries make duplicate-safe application handling essential.A lost PUBACK can repeat a valve command, so desired state or command identity must prevent repeated handling from causing an unsafe action.
Deck summary
Key takeaways (2/2)
- Sessions and broker limits shape what an offline subscriber receives.Session configuration, queued-message policy, retained messages, and reconnect behaviour determine the offline result rather than the publication QoS label alone.
- Application acknowledgement supplies evidence beyond protocol delivery.A final state update or application result establishes the device outcome after the broker handshake has completed only its own delivery leg.
Retrieval practice
Recall check 1 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q1A battery-powered sensor publishes a replaceable temperature reading every few seconds. Which MQTT QoS choice is usually the best starting point?
Show answer
Answer: A For replaceable telemetry, occasional loss is tolerable and avoiding acknowledgements reduces radio and broker work.
Retrieval practice
Recall check 2 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q2A device currently publishes the command 'toggle_relay' with QoS 1. Sometimes a retry causes the relay to switch twice. What is the best design fix before reaching for QoS 2?
Show answer
Answer: C Replacing toggle_relay with a desired-state command such as set_relay_state=on removes the harm from duplicates and gives the system clearer evidence.
Retrieval practice
Recall check 3 of 3
Broker Bex says: answer from memory, then check your reasoning.
Q3A controller publishes a QoS 2 command to an MQTT broker. The broker completes the QoS 2 handshake with the controller. What has been proven?
Show answer
Answer: D MQTT QoS is protocol delivery evidence, not proof that the physical action happened.
Print reference
Answers
Answer key.
- A · For replaceable telemetry, occasional loss is tolerable and avoiding acknowledgements reduces radio and broker work.
- C · Replacing toggle_relay with a desired-state command such as set_relay_state=on removes the harm from duplicates and gives the system clearer evidence.
- D · MQTT QoS is protocol delivery evidence, not proof that the physical action happened.
Print reference
Activity 1 answer
Model answer.
Predict: The payload may be delivered again. A command identifier with duplicate suppression, or an idempotent desired-state command, can make repeated handling safe. Application acknowledgement or state readback must establish the valve’s actual result.