IO7: Device-to-cloud messaging: MQTT and CoAP
Why not HTTP for everything?
🎯You'll be able to
Compare HTTP, MQTT and CoAP for devices, and choose one for a given device and network.
🏠The everyday picture
A newspaper delivered to every subscriber is different from each person going to the shop to ask whether there's news. One message fanned out to many beats many questions asked again and again.
📘What it really is
-
HTTP is request and response: the device asks, the server answers. Each request carries headers, and with TLS a new connection is costly. Fine for occasional uploads; poor for pushing commands to a device.
-
MQTT (publish and subscribe) uses a broker. Devices publish messages to topics; anyone subscribed to a topic receives them. One small, long-lived TCP connection carries messages both ways, with little overhead.
-
CoAP is like a tiny HTTP over UDP, made for very constrained devices and networks (Lesson 4).
- Choosing: MQTT for most connected devices with a TCP connection; CoAP for tiny devices or lossy low-power networks; HTTP for occasional, larger transfers such as firmware downloads.
📝A worked example
Input: JalSetu sends a small reading every hour and should receive a "send your log" command now and then.
Steps:
- With HTTP, the device would have to ask "any commands?" on every wake, and the server couldn't reach it otherwise.
- With MQTT, the device subscribes to its command topic when it connects, and messages waiting for it can be delivered then.
- Choose MQTT for readings and commands, and plain downloads for firmware images.
Expected output: the protocol choice the kit uses.
🌍Where it's used
- MQTT: home automation hubs, factory telemetry, cloud IoT platforms.
- CoAP: smart lighting and meters on low-power mesh networks.
- HTTP: firmware downloads and devices that report once a day.
📝Case scenario
A team's devices polled an HTTP endpoint every minute for commands. With 10,000 devices, the server handled 14 million requests a day, almost all saying "nothing new". Moving to MQTT subscriptions cut the load to the messages that mattered.
🖱️Try it
For three devices (a door sensor, a weather station sending every 10 minutes, a smart bulb), choose HTTP, MQTT or CoAP and say why. Success: a choice and a reason for each.
⚠️Common mistakes
- Polling for commands. Sign: heavy server load and slow commands. Fix: subscribe.
- Large messages for small data. Sign: data and battery wasted. Fix: compact payloads.
- One protocol for everything. Sign: firmware images squeezed through MQTT. Fix: a download for large files.
🛠️For your project
Project 2 sends readings and status with MQTT; Project 3 downloads firmware separately.
✅Quick check
How does a publish and subscribe system deliver a message?
Show the answer
A device publishes to a topic on a broker, and the broker passes it to everyone subscribed to that topic.
Why is polling for commands a poor fit for devices?
Show the answer
It costs requests and battery even when there's nothing new, and commands wait until the next poll.