IO7: Device-to-cloud messaging: MQTT and CoAP
Designing topics and payloads
🎯You'll be able to
Design a topic structure and a message format that stay clear as a fleet grows and changes.
🏠The everyday picture
A postal address goes from big to small: state, district, village, house. Anyone can find a house, and a whole village's mail can be sorted together.
📘What it really is
-
Topics from general to specific:
project/site/device/kind, such asjalsetu/S01/T07/reading. A subscriber can then take a whole site (jalsetu/S01/#) or every reading (jalsetu/+/+/reading). -
IDs, not names: device and site IDs, not people's names or addresses, in topics.
- Separate kinds: readings, status, commands and command results on their own topics.
- Payloads: JSON is readable and easy; compact formats (CBOR, Protocol Buffers or a fixed binary layout) save bytes on slow links.
- Version the format: add a field or a topic level for the version so old and new firmware can coexist.
- Include what the server needs: a sequence number, the measurement time, units clear from the field names (
level_mm). - Keep it small: no padding, no repeated text, numbers as numbers.
📝A worked example
Input: a first draft topic jalsetu/T07 with payload {"level": 940, "temp": 26}.
Steps:
- Add the site and the kind:
jalsetu/S01/T07/reading. - Name units and add what the server needs:
{"seq": 312, "ts": 1793635200, "level_mm": 940, "level_pct": 47, ...}. - Put status on
jalsetu/S01/T07/status, separate from readings.
Expected output: Project 2's agreed format, as in docs/FORMATS.md.
🌍Where it's used
- Fleet platforms sort and permission by topic.
- Data pipelines subscribe to whole sites or kinds.
- Firmware updates that change formats without breaking dashboards.
📝Case scenario
A company used topics like sensor1, sensor2, ..., with no site. When a second city joined, nobody could subscribe to one city's
devices. Renaming topics to company/city/device/kind across the fleet took months.
🖱️Try it
Design topics for a building with 20 rooms, each with a temperature sensor and a light switch. Include readings, status and commands. Success: a pattern where one wildcard subscription gets all temperatures.
⚠️Common mistakes
- Flat topics. Sign: no way to subscribe by site. Fix: general to specific.
- Personal data in topics. Sign: names and flat numbers visible to anyone with broker access. Fix: IDs.
- No units or time. Sign: confusion about meaning and age. Fix: units in names,
tsin each message.
🛠️For your project
Project 2's test 6 checks the topic and exactly the agreed keys, using a standard MQTT client.
✅Quick check
Why put the site in the topic?
Show the answer
So one subscription can take all of a site's devices, and permissions can be set by site.
Why add a version to a message format?
Show the answer
So old and new firmware can coexist while a fleet updates.