IoT Communication Protocols

A communication protocol is the set of rules that defines how IoT devices format, send, and receive messages. Just like humans need a shared language to communicate, devices need protocols to understand each other. IoT systems use different protocols at different layers — from the device's internal communication to the messages it sends across the internet.

Protocol Layers in IoT

Think of IoT communication as a postal system. The envelope format is one standard. The addressing system is another. The delivery vehicle is a third. Each layer operates independently but works together to deliver a message.

APPLICATION LAYER        MQTT, CoAP, HTTP, AMQP
      |                  (What the message says and how it's structured)
      v
NETWORK / TRANSPORT      TCP/IP, UDP
      |                  (How to route the message across networks)
      v
DATA LINK / PHYSICAL     Wi-Fi, BLE, LoRaWAN, Ethernet
                         (The radio wave or cable carrying the signal)

Application-Layer Protocols

These protocols define how IoT devices format their messages and how servers receive and respond to them. This is the layer where most of the IoT-specific design decisions happen.

MQTT (Message Queuing Telemetry Transport)

MQTT is the most widely used IoT messaging protocol. It follows a publish-subscribe model. A device (publisher) sends a message to a central broker. Other devices or servers (subscribers) that have registered interest in that message type receive it immediately.

Sensor (Publisher)              MQTT Broker              App (Subscriber)
   |                                |                          |
   |-- "home/temperature" : 23.4 -->|                          |
   |                                |-- "home/temperature" --> |
   |                                |    23.4 degrees          |
   |                                |                          |

Why IoT devices prefer MQTT:

Extremely lightweight — the message header is just 2 bytes minimum
Works over unreliable networks — the broker queues messages if a subscriber is offline
Supports three delivery guarantees (QoS levels 0, 1, and 2)
A single broker can handle thousands of connected devices simultaneously

QoS levels explained:

QoS 0 — At most once: Send and forget. No acknowledgment. Like a flyer left in a mailbox — it may or may not be read.
QoS 1 — At least once: The message is delivered at least once, but may arrive more than once. Like a registered letter — the sender gets a receipt but will resend if unsure.
QoS 2 — Exactly once: The most reliable mode. The message is guaranteed to arrive exactly one time. Used for billing or critical alerts.

CoAP (Constrained Application Protocol)

CoAP was designed for devices with very limited memory and processing power, such as a tiny environmental sensor on a coin-cell battery. It works like a simplified version of HTTP — using request/response messages — but runs over UDP instead of TCP, which makes it much lighter and faster to start a connection.

Best for: resource-constrained sensors (temperature loggers, smart meters, agricultural sensors) that need a request-response style interaction without the overhead of HTTP.

HTTP / HTTPS

HTTP is the same protocol that web browsers use to load websites. IoT devices sometimes use HTTP to send data to a web server using a REST API. HTTP is well-understood, well-supported, and integrates easily with existing web infrastructure.

Limitation: HTTP is heavyweight for IoT. Each request requires a full connection setup, which takes time and energy. Battery-powered devices avoid it for frequent transmissions.

Best for: IoT devices with a stable power supply that need to interact with existing web APIs, cloud dashboards, or data pipelines.

AMQP (Advanced Message Queuing Protocol)

AMQP is a feature-rich messaging protocol used in enterprise IoT systems. It offers more complex routing, queuing, and delivery guarantee options than MQTT. It is heavier and more complex to implement, but it fits well into corporate data infrastructure.

Best for: large-scale enterprise IoT deployments, financial systems, healthcare platforms where advanced message routing and enterprise-grade reliability are required.

WebSocket

WebSocket opens a persistent two-way connection between a device and a server. Once connected, both sides can send messages to each other at any time without the overhead of starting a new connection each time.

Best for: real-time dashboards, live telemetry displays, interactive IoT control panels in web applications.

Device-Level Communication Protocols

These protocols operate inside a device or between devices on the same circuit board or local network.

I2C (Inter-Integrated Circuit)

I2C lets a microcontroller communicate with multiple sensors using just two wires: one for data (SDA) and one for the clock signal (SCL). Each sensor has a unique address so the microcontroller can talk to them individually on the same wire pair.

Microcontroller
  SDA ---+-------+-------+
         |       |       |
      [Sensor1] [Sensor2] [Sensor3]
         addr:0x48  addr:0x77  addr:0x39
  SCL ---+-------+-------+

Best for: temperature sensors, displays, real-time clocks, and any short-range board-to-board sensor communication.

SPI (Serial Peripheral Interface)

SPI is faster than I2C and uses four wires: clock (SCK), data in (MISO), data out (MOSI), and chip select (CS). It is used for sensors or modules that need to transfer large amounts of data quickly, such as display screens, SD cards, and high-resolution ADC converters.

Best for: displays, data logging to SD cards, high-speed sensors, radio modules.

UART (Universal Asynchronous Receiver/Transmitter)

UART is the simplest serial communication method. It uses two wires (TX and RX) and is commonly used to connect GPS modules, serial Bluetooth adapters, and debugging consoles to microcontrollers.

Best for: GPS modules, radio modules (like HC-05 Bluetooth), debug serial monitor output.

Comparing Application Protocols at a Glance

+-------------+-----------+-----------+----------+--------------+
| Protocol    | Transport | Pattern   | Overhead | Best Use     |
+-------------+-----------+-----------+----------+--------------+
| MQTT        | TCP       | Pub/Sub   | Very low | Most IoT     |
| CoAP        | UDP       | Req/Resp  | Very low | Constrained  |
| HTTP        | TCP       | Req/Resp  | High     | Web APIs     |
| AMQP        | TCP       | Pub/Sub   | Medium   | Enterprise   |
| WebSocket   | TCP       | Full-dup. | Low      | Dashboards   |
+-------------+-----------+-----------+----------+--------------+

End-to-End Message Journey: Temperature Alert

[Temperature Sensor]
     |
     | I2C (reads 42°C)
     v
[ESP32 Microcontroller]
     |
     | MQTT Publish: topic="factory/machine3/temp", payload="42.1"
     v
[Wi-Fi / TCP/IP]
     |
     v
[MQTT Broker (Cloud)]
     |
     | MQTT Subscribe (rules engine receives message)
     v
[Alert System]
     |
     | HTTP POST to notification service
     v
[Engineer's Phone] --> Alert: "Machine 3 temperature exceeded 40°C"

Summary

IoT communication operates across multiple layers. Physical layers (Wi-Fi, BLE, LoRaWAN) carry the signal. Device-level protocols (I2C, SPI, UART) connect chips on the same board. Application-layer protocols (MQTT, CoAP, HTTP) structure the messages and define how devices interact with servers. MQTT is the dominant choice for IoT because of its lightweight publish-subscribe model and reliable delivery options.

Previous lesson

Back to course

Next lesson