My progress
Menu

IoT and Smart Systems Engineer · Focus area 3: Device-to-cloud communication

IO7: Device-to-cloud messaging: MQTT and CoAP

Goal: choose a protocol for devices on weak networks, use MQTT's topics, QoS levels, retained messages, last wills and keepalives, design topics and payloads, know when CoAP suits better, and secure the connection with per-device identity.

You'll need: IO1, IO3, Module 4 (Computer Networks), Module 5 (IP Addresses and Ports), Module 25 (APIs and JSON), Module 76 (API and Network Security), and the JalSetu practice kit (lib/mqtt.py, sim/broker.py, tools/broker.py, docs/FORMATS.md).

Where this is used: MQTT carries messages for smart meters, factory sensors, connected cars, home devices and many cloud IoT platforms. CoAP is used where devices are very small or on low-power networks.

How it differs: a web app asks a server and waits for an answer. IoT devices sleep, wake briefly and push small messages over connections that drop; servers need to know which devices are alive and send them commands when they next appear.

Time: reading about 3 hours · practice (the Try it tasks) about 3 hours · assignment about 4 hours.

Lessons

  1. 1Why not HTTP for everything?Reading 15–25 minutes, plus practice✓
  2. 2MQTT: topics, QoS, retained messages, wills and keepaliveReading 15–25 minutes, plus practice✓
  3. 3Designing topics and payloadsReading 15–25 minutes, plus practice✓
  4. 4CoAP and UDP for the smallest devicesReading 15–25 minutes, plus practice✓
  5. 5Securing the connection and the brokerReading 15–25 minutes, plus practice✓

🛠️Assignment: JalSetu's messaging

  1. Design JalSetu's topics for readings, status and commands, general to specific.
  2. Write the reading format with seq, ts and units in field names.
  3. Implement QoS 1 publishing, a retained status, an "asleep" status and a retained last will.
  4. Watch it with tools/broker.py and a standard MQTT client.
  5. Write the security plan: TLS, per-device credentials and ACLs.
  6. Run pytest tests/test_buffer.py and note which tests pass (6 and 8 at least).

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How should a device send data to the cloud?

Show a good answer

A good answer mentions: publish and subscribe through a broker rather than polling, with one small connection; MQTT topics from general to specific with IDs, QoS 1 with sequence numbers for data that matters, retained status, a last will and keepalive; compact, versioned payloads with units and time; CoAP over UDP with confirmable messages and observe for the smallest devices; and TLS with per-device credentials, ACLs per device and credentials kept out of code.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A team's 10,000 devices poll an HTTP endpoint every minute for commands, and nearly every poll gets "nothing new". What's the better design?

Why each option is right or wrong

  • “Poll every second instead, so that commands arrive more quickly” (Incorrect): That multiplies the waste.
  • “Remove commands entirely and update devices only by visiting them” (Incorrect): Remote commands are useful.
  • “Buy a bigger server so it can handle all of the 14.4 million polling requests every day” (Incorrect): That pays for the waste instead of removing it.
  • “Devices subscribe to their own MQTT command topic and receive commands when they're sent” is correct.

    No requests are wasted on "nothing new".

    • Also: commands arrive faster.

📖 Revise: Lesson 1: Why not HTTP for everything?

Question ID sp-iot-07-q1 · Report a mistake in this question
2. A reading is published with QoS 1, and the PUBACK is lost. What happens?

Why each option is right or wrong

  • “The reading is lost for good, since QoS 1 doesn't resend anything” (Incorrect): QoS 1 resends until acknowledged.
  • “The broker sends the PUBACK twice to be sure, so nothing is resent” (Incorrect): The device can't know the PUBACK was lost.
  • “The connection switches to QoS 2 for that one message” (Incorrect): QoS doesn't change by itself.
  • “The device resends it, so the broker may receive it twice” is correct.

    At least once means duplicates are possible.

    • Fix duplicates: the server keeps one per seq.

📖 Revise: Lesson 2: MQTT: topics, QoS, retained messages, wills and keepalive

Question ID sp-iot-07-q2 · Report a mistake in this question
3. A dashboard shows sleeping devices as "online" all night. What should change?

Why each option is right or wrong

  • “Turn off retained messages, so that the dashboard shows no status for anyone at all” (Incorrect): New viewers would see no status.
  • “Keep each device connected all night, so that the "online" label really is true” (Incorrect): That drains batteries.
  • “Remove the last will, so the broker stops sending any status for them” (Incorrect): The will is what reports real failures.
  • “Publish a retained "asleep" status before disconnecting, and keep a retained "offline" will” is correct.

    The dashboard then tells sleep and failure apart.

    • Kit: Project 2's test 8.

📖 Revise: Lesson 2: MQTT: topics, QoS, retained messages, wills and keepalive

Question ID sp-iot-07-q3 · Report a mistake in this question
4. Which topic design lets one subscription receive every reading from site S01?

Why each option is right or wrong

  • “T07, T08, ... for each device, with the site in the message” (Incorrect): Subscribers can't filter by site.
  • “reading/everything, with every device publishing to the same one topic” (Incorrect): Nothing can be filtered or permissioned.
  • “jalsetu/<caretaker's name>/reading, so people know whose tank it is” (Incorrect): Personal names don't belong in topics.
  • “jalsetu/S01/<device>/reading, subscribed as jalsetu/S01/+/reading” is correct.

    General to specific lets wildcards pick a site.

    • Or: jalsetu/S01/# for everything at the site.

📖 Revise: Lesson 3: Designing topics and payloads

Question ID sp-iot-07-q4 · Report a mistake in this question
5. Why does JalSetu disconnect properly before deep sleep?

Why each option is right or wrong

  • “So that the broker deletes all of the retained messages the device published earlier” (Incorrect): Disconnecting doesn't delete retained messages.
  • “Because an MQTT connection can't stay open longer than one minute at a time” (Incorrect): Connections can last as long as keepalive allows.
  • “So the next connection can use QoS 0 instead of QoS 1” (Incorrect): QoS is chosen per message.
  • “So the broker doesn't publish its last will, which is for real failures” is correct.

    A proper disconnect means "I left on purpose".

    • Then: the will marks only unexpected drops.

📖 Revise: Lesson 2: MQTT: topics, QoS, retained messages, wills and keepalive

Question ID sp-iot-07-q5 · Report a mistake in this question
6. A coin-cell light sensor sits on a low-power mesh network. Which protocol most likely suits it?

Why each option is right or wrong

  • “HTTP with TLS, sending a full request for each reading” (Incorrect): Heavy headers and connections cost too much energy.
  • “MQTT over TCP, with one connection kept open all day and all night” (Incorrect): Keeping TCP connections is costly on such networks.
  • “FTP, uploading a file of readings once a week” (Incorrect): That's slow and unsuited to a sensor.
  • “CoAP over UDP, with observe and confirmable messages for alarms” is correct.

    Small messages and no connection to keep open.

    • Often: through a gateway.

📖 Revise: Lesson 4: CoAP and UDP for the smallest devices

Question ID sp-iot-07-q6 · Report a mistake in this question
7. A fleet of devices shares one password to connect to the broker. What's the main risk?

Why each option is right or wrong

  • “The shared password makes every connection slower for every single device in the fleet” (Incorrect): Speed isn't the risk.
  • “The broker can only accept one connection per password at a time” (Incorrect): The risk is security, not limits.
  • “Devices with shared passwords can't use QoS 1” (Incorrect): QoS isn't affected.
  • “One leak lets anyone connect as any device, and no single device can be blocked alone” is correct.

    Shared credentials spread the damage.

    • Fix: per-device credentials and ACLs.

📖 Revise: Lesson 5: Securing the connection and the broker

Question ID sp-iot-07-q7 · Report a mistake in this question
8. Which is the best reading payload?

Why each option is right or wrong

  • “{"value": 940}, since the dashboard knows which device and units it means” (Incorrect): No units, time or sequence number.
  • “"Tank T07 at Patil house has 940 mm of water", so anyone can read it” (Incorrect): Text with a person's name is hard to process and shares personal data.
  • “A 5 KB block of every setting the device has, sent with each reading” (Incorrect): Wasteful on a slow link.
  • “{"seq": 312, "ts": 1793635200, "level_mm": 940, "level_pct": 47}” is correct.

    Units, time and sequence are clear.

    • Kit: the agreed format in docs/FORMATS.md.

📖 Revise: Lesson 3: Designing topics and payloads

Question ID sp-iot-07-q8 · Report a mistake in this question
9. What does MQTT keepalive do?

Why each option is right or wrong

  • “It keeps the device awake, so it doesn't drop into deep sleep while it's still connected” (Incorrect): It's about the connection, not sleep.
  • “It resends every message twice to keep the data alive on the broker” (Incorrect): That isn't keepalive.
  • “It stores the device's readings on the broker for a week” (Incorrect): Storage is a different feature.
  • “Lets the broker drop a silent connection after about one and a half intervals” is correct.

    Silence beyond the interval means the client is gone.

    • Then: the last will is published.

📖 Revise: Lesson 2: MQTT: topics, QoS, retained messages, wills and keepalive

Question ID sp-iot-07-q9 · Report a mistake in this question
10. A device should be able to publish only its own readings. What enforces that?

Why each option is right or wrong

  • “A comment in the firmware asking developers not to publish elsewhere” (Incorrect): Comments don't stop anything.
  • “Using QoS 2 for every message, which checks the sender” (Incorrect): QoS doesn't check permissions.
  • “Putting the device's ID at the start of every payload” (Incorrect): Any device could write any ID.
  • “A broker ACL tied to the device's own credentials” is correct.

    The broker refuses other topics.

    • Example: T07 may publish to jalsetu/S01/T07/#.

📖 Revise: Lesson 5: Securing the connection and the broker

Question ID sp-iot-07-q10 · Report a mistake in this question

ProLearners Assist