IO7: Device-to-cloud messaging: MQTT and CoAP
MQTT: topics, QoS, retained messages, wills and keepalive
🎯You'll be able to
Use MQTT's main features correctly: topics and wildcards, QoS 0, 1 and 2, retained messages, last wills, keepalive and sessions.
🏠The everyday picture
A noticeboard has sections ("water", "electricity"). A note can be pinned to stay up for latecomers. A neighbour might leave a sealed note with the caretaker: "if I don't come back by evening, tell my family". That's a last will.
📘What it really is
- Topics are paths such as
jalsetu/S01/T07/reading. Subscribers can use wildcards:+matches one level,#matches the rest. - QoS 0: sent at most once, no acknowledgement. Cheap; can be lost.
- QoS 1: at least once. The broker answers with PUBACK; the sender resends if it doesn't arrive, so duplicates are possible.
-
QoS 2: exactly once between client and broker, using a four-step handshake. More overhead; rarely needed if messages carry sequence numbers.
-
Retained: the broker keeps the last retained message on a topic and gives it to new subscribers at once. Good for status.
- Last will: set when connecting; the broker publishes it if the connection drops without a proper disconnect. Good for "offline".
-
Keepalive: the client promises to send something within an interval; the broker drops a silent connection after about one and a half intervals.
-
Sessions: a persistent session lets the broker keep subscriptions and queued QoS 1 messages for a client that reconnects.
- Ports: 1883 is usual for plain MQTT, 8883 for MQTT over TLS. MQTT 5 adds reason codes, session expiry and user properties.
📝A worked example
Input: JalSetu connects once an hour.
Steps:
- Connect with a last will: topic
jalsetu/S01/T07/status, payload{"state":"offline"}, retained. - Publish a retained status
{"state":"online", ...}, then readings with QoS 1, each waiting for its PUBACK. - Before disconnecting, publish a retained
{"state":"asleep", ...}, then disconnect properly so the will isn't sent.
Expected output: a dashboard that shows "asleep" between contacts and "offline" only when something went wrong.
🌍Where it's used
- Device status on fleet dashboards, with retained messages and wills.
- Telemetry with QoS 1 and sequence numbers.
- Commands to devices on their own topics.
📝Case scenario
A dashboard showed every device "online" all night, though they were asleep. Their last status message was "online", retained. Adding an "asleep" status before each disconnect, and a will for real failures, made the dashboard honest.
🖱️Try it
Run python tools/broker.py and subscribe to jalsetu/# with any MQTT client (or the test's paho client). Write down what a new
subscriber sees first on a topic with a retained message. Success: the retained message arrives at once.
⚠️Common mistakes
- QoS 0 for data that matters. Sign: silent losses. Fix: QoS 1 with sequence numbers.
- Retained "online" with no will. Sign: dead devices look alive. Fix: a will and an "asleep" status.
- Wildcards in publish topics. Sign: errors or confusion. Fix: wildcards are for subscribing only.
🛠️For your project
Project 2's tests 5, 6 and 8 check QoS 1, the topic and format, the status and the last will.
✅Quick check
What does QoS 1 promise?
Show the answer
At least once: the message is resent until acknowledged, so duplicates are possible.
When does the broker publish a client's last will?
Show the answer
When the connection drops without a proper disconnect.