Understand and apply MQTT QoS levels, retained messages, and Last Will and Testament in practice

Verified steps

1. Choose QoS based on delivery requirements: QoS 0 (at most once, fire-and-forget) for high-frequency sensor data where occasional loss is acceptable; QoS 1 (at least once) for critical readings that must arrive even if duplicated; QoS 2 (exactly once) for commands where duplicate execution causes harm
2. For retained messages, publish with the retained flag set to true on a status or last-known-value topic; new subscribers immediately receive the retained message without waiting for the next publish; clear a retained message by publishing an empty payload with retained=true to the same topic
3. Configure Last Will and Testament (LWT) in the CONNECT packet: set willTopic, willMessage (e.g., {"status":"offline"}), willQoS, and willRetain; the broker publishes this automatically on unclean disconnect
4. Pair LWT with a retained online message: on successful connect, immediately publish {"status":"online"} with retained=true to the status topic to overwrite any prior LWT; this creates a reliable online/offline indicator
5. Understand broker-side QoS downgrade: if a subscriber subscribes at QoS 0 but a message was published at QoS 1, the broker delivers it at QoS 0 — the effective QoS is the minimum of publisher and subscriber QoS
6. For constrained devices, prefer QoS 1 over QoS 2: QoS 2 requires four-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP) which doubles round-trips and increases RAM usage for in-flight message state