MQTT QoS Level Simulator

Step through MQTT QoS 0, QoS 1, and QoS 2 delivery paths, retries, duplicates, and effective subscriber QoS

Interactive MQTT QoS workbench showing publish handshakes, packet loss recovery, duplicate risk, QoS downgrade, and protocol-level delivery limits

Animation MQTT reliability 12 min

MQTT QoS Delivery Workbench

Step through what MQTT really sends for QoS 0, QoS 1, and QoS 2. Watch retries, duplicate risk, and subscriber QoS downgrade as packet events move between publisher, broker, and subscriber.

QoS 1 At least once on the publish leg

Subscriber QoS 1 Effective QoS is min(publish QoS, subscription QoS)

4 packet events Handshake and retry overhead for one message

Duplicate possible Lost ACKs can make QoS 1 repeat the PUBLISH

What Changes

QoS changes the packet exchange, not the topic name or payload. Higher QoS adds acknowledgements and stored state.

Why It Matters

Small sensors often prefer QoS 0. Alerts and commands usually need QoS 1. QoS 2 is reserved for messages where duplicates are more damaging than delay.

Try First

Use the QoS 1 lost ACK preset, then press Step. The same message can be delivered and still be sent again.

Common Mistake

QoS 2 confirms MQTT protocol delivery. It does not prove that a motor moved, a lock opened, or a sensor action completed.

Scenario

Publish QoS QoS 0 - at most once QoS 1 - at least once QoS 2 - exactly once This is the QoS used by the publishing client when sending to the broker.

Subscriber maximum QoS QoS 0 maximum QoS 1 maximum QoS 2 maximum The broker delivers to the subscriber at the lower of publish QoS and subscription QoS.

Network event No packet loss First PUBLISH is lost Acknowledgement is lost QoS 2 PUBREL is lost The simulator uses deterministic packet events so the lesson is repeatable.

Round-trip time 180 ms

Messages per minute 30/min

Application command is idempotent or de-duplicated by message ID.

QoS 1 command with a lost PUBACK

The broker receives the PUBLISH, but the acknowledgement back to the publisher is lost. The publisher retries with DUP=1, so the application must be prepared for a duplicate command.

Step 1 of 6

Publisher Sending first PUBLISH

Broker Waiting for packet identifier 42

Subscriber Subscribed with QoS 1 maximum

Packet Flow

Delivered Lost Retry or duplicate

Client state: waiting for PUBACK Packet identifier 42 remains in-flight until the acknowledgement arrives.

Broker state: message received The broker can forward the message before the publisher sees the ACK.

Effective QoS: 1 Subscriber delivery uses min(1, 1), so the subscriber path is QoS 1.

Application state: duplicate unsafe A non-idempotent command needs a command ID or other duplicate protection.

Delivered, but duplicate possible QoS 1 promises at least one delivery, not exactly one delivery.

Estimated confirmation: 360 ms This teaching estimate counts MQTT control exchanges and retry timeout cost.

180 packet events/min Higher QoS increases broker and radio work when message rate is high.

Learning Support

Read The Direction

MQTT QoS is negotiated per delivery leg. The publisher-to-broker leg and broker-to-subscriber leg can use different QoS levels.

Watch The Packet ID

QoS 1 and QoS 2 use a packet identifier while the exchange is in progress. Retries reuse that identifier and set DUP=1.

Separate Protocol From Action

An MQTT acknowledgement means a protocol peer handled the MQTT packet. It is not proof that an actuator finished the physical task.

Quick Reference

QoS 0

At most once PUBLISH only. No acknowledgement, no retry, lowest overhead. A lost packet is simply lost.

QoS 1

At least once PUBLISH plus PUBACK. If the acknowledgement is lost, the sender retries and the receiver may see a duplicate.

QoS 2

Exactly once at protocol level PUBLISH, PUBREC, PUBREL, PUBCOMP. More state and packets, used when duplicates are costly.

Effective QoS

min(publish, subscription) A publisher using QoS 2 does not force every subscriber to receive QoS 2 delivery.

DUP Flag

Retry marker DUP=1 tells the receiver that this control packet may be a retransmission, not a new application meaning.

Design Rule

Make commands repeat-safe Use command IDs, state checks, or idempotent actions when duplicate execution would be unsafe.

Guided Practice

1. Compare Cost

Switch from QoS 0 telemetry to QoS 2 meter. The packet count and estimated confirmation time should increase.

2. Find Duplicate Risk

Use QoS 1 with a lost acknowledgement. The broker receives the first publish, but the publisher cannot know that yet.

3. Test Downgrade

Set publish QoS to 2 and subscriber maximum to 0. The broker-to-subscriber leg becomes QoS 0.

MQTT QoS Levels Animation Reference page for the three QoS handshakes. MQTT Session Management See how persistent sessions queue QoS 1 and QoS 2 messages.