MQTT and basic protocols

Key takeaways

Your device has data to send, a temperature reading, a GPS coordinate, a battery voltage, but how does that data actually reach your cloud application? The answer depends on the messaging protocol you choose. This lesson builds the conceptual mental model you need, covering what each key IoT protocol does, how they differ, and when to use each, with no code or implementation detail.

What you'll learn

Why protocol choice is a consequential architecture decision

Choosing a messaging protocol is one of the most consequential decisions in an IoT project. The protocol determines how much bandwidth your device uses, how much power it consumes per transmission, whether the device can receive commands from the cloud, and how complex your integration will be. Get it right and the system runs efficiently for years; get it wrong and you may face a redesign. A critical design principle is to keep your application-layer protocol (such as MQTT or CoAP) separate from your transport choice (TCP or UDP), so you can swap one without rewriting the other.

How MQTT's publish/subscribe model works

MQTT (Message Queuing Telemetry Transport) is the most widely used IoT messaging protocol. It uses a publish/subscribe pattern over TCP: devices publish messages to named "topics" (like sensors/temperature), and any application subscribed to that topic receives the message. A central MQTT broker sits between publishers and subscribers and routes messages. Its key advantages are low overhead, built-in quality of service (QoS) levels, and bidirectional communication, since the cloud can publish commands back to devices through the same broker. MQTT defines three QoS levels:

• QoS 0 (at most once): fire and forget
• QoS 1 (at least once): guaranteed delivery with possible duplicates
• QoS 2 (exactly once): guaranteed single delivery

When CoAP and HTTP are the right fit

CoAP (Constrained Application Protocol) is designed for very constrained devices with limited memory and processing power. It runs over UDP instead of TCP, eliminating connection-management overhead, and follows a request/response pattern similar to HTTP (GET, PUT, POST, DELETE) but with much smaller packets. Its "Observe" extension lets clients register interest in a resource and receive notifications when it changes, giving it some publish/subscribe-like behavior. HTTP/HTTPS, the protocol of the web, is simple, universally supported, and the easiest to integrate with existing web infrastructure, since any REST API can receive device data. However, HTTP is heavyweight: every request needs a full TCP connection setup, headers are large, and there is no built-in way for the server to push data to the device. It suits devices that report infrequently and do not need to receive commands.

How LwM2M fits alongside the other protocols

LwM2M (Lightweight Machine-to-Machine) is purpose-built for device management. It runs over CoAP and DTLS and provides a standardized object model for firmware updates, configuration, and monitoring. While it can carry telemetry, its primary strength is device lifecycle management rather than data streaming.

How publish/subscribe differs from request/response

The fundamental difference between MQTT and the other protocols is the communication pattern. In publish/subscribe, the device does not need to know who receives its data; it just publishes to a topic. This decouples senders from receivers and makes it easy to add new consumers without changing device firmware. In request/response, the device sends a specific request to a specific endpoint and waits for a response, which is simpler to understand but creates tighter coupling.

Why dual-protocol deployments and data formats matter

Dual-protocol deployments are common: many real-world systems use LwM2M for device management operations (firmware updates, configuration) while using MQTT or CoAP for telemetry, keeping each protocol doing what it does best. Separately, the payload format is what you send, distinct from the protocol that carries it. Common IoT formats include JSON (human-readable and widely supported, but verbose), CBOR (binary JSON, compact and efficient), Protocol Buffers (strongly typed and very compact, but requires a schema), and raw binary (maximum efficiency, minimum interoperability).

Lesson 5.2 Self-assessment

Frequently asked questions