English is currently available.
IoT & MQTT DISCUSSION
My sensor publishes readings with QoS 1, and a Python client subscribes with QoS 0. Some messages never arrive at the subscriber when its Wi-Fi drops for a few seconds, even though I thought QoS 1 meant guaranteed delivery. Switching the publisher to QoS 2 changed nothing.
What do the three levels really guarantee, and between which parties? Do I need the same QoS on both sides?
QoS is not end to end. It applies separately to each hop: publisher to broker, and broker to each subscriber. The level used for the second hop is the lower of the QoS the message was published with and the QoS the subscriber requested in its subscription.
Your subscriber asked for QoS 0, so the broker delivers to it with QoS 0 regardless of what the sensor used, and a message sent while the connection is broken is simply gone. Changing the subscription to QoS 1 is the first half of the fix.
The levels themselves: QoS 0 sends the PUBLISH once with no acknowledgement (at most once). QoS 1 stores the message until a PUBACK arrives and resends it if not, so it arrives at least once and can arrive twice; the DUP flag marks a retransmission. QoS 2 uses a four-packet exchange, PUBLISH, PUBREC, PUBREL, PUBCOMP, so that the receiver processes the message exactly once.
QoS 2 costs twice the packets and extra state on both sides. For sensor readings, QoS 1 plus a receiver that tolerates duplicates (for example by keying on a timestamp or sequence number in the payload) is the usual choice, and QoS 0 is fine for frequent values where the next reading replaces a lost one.
The second half is the session. A broker only queues messages for an offline subscriber if that subscriber has a persistent session: it connected with clean session set to false (MQTT 3.1.1) or, in MQTT 5, with clean start false and a session expiry interval greater than zero; it uses a fixed client ID; and its subscription is QoS 1 or 2. When it reconnects with the same client ID, the broker sends what was queued.
With a clean session, the broker forgets the client and its subscriptions the moment the connection drops, so nothing is queued, whatever QoS you chose. In paho-mqtt that means creating the client with a fixed client_id and clean_session=False.
Know the limits of the guarantee. It covers delivery to the broker and from the broker to sessions that exist; it does not cover a subscriber that has never connected, and brokers cap the queue for offline clients (Mosquitto has max_queued_messages, for instance), discarding messages beyond the cap. On the publishing side, a microcontroller client that holds unacknowledged QoS 1 messages only in RAM loses them on a reset.
So QoS 1 protects against short network interruptions. For outages of hours, the device needs its own buffer in flash, and the application needs to detect gaps, for example with a counter in each message.
Back to IoT & MQTT community
