Choosing the right protocol stack for your next connected device

Every IoT project comes down to one deceptively simple question: how do the devices actually talk to each other? As embedded engineers, we spend most of our time on firmware logic and sensor drivers.

But IoT communication protocols are what decide whether a product works reliably in the field or falls apart the moment it leaves the lab. This guide walks through the protocols I reach for most often when building microcontroller-based IoT systems — and how I decide between them.

Why Do IoT Communication Protocols Matter?

A protocol decision is really a trade-off between four constraints:

• Power budget: how long the battery must last

• Bandwidth: how much data the device sends

• Range: meters on a desk or kilometers across a farm

• Reliability: how much noise and interference the link must survive

A battery-powered soil sensor and a factory-floor controller have almost opposite requirements, even though both are “IoT devices.” Getting this wrong early is expensive.

Wired IoT Protocols on the Board

Inside the device, short-distance wired protocols still do most of the work:

• UART: simple, point-to-point. Great for debug consoles and GPS/GSM modules.

• I2C: a multi-device bus over two wires. Ideal for sensors like IMUs and environmental chips.

• SPI: higher throughput than I2C. Used for displays, SD cards, and fast ADCs/DACs.

• CAN: robust and noise-resistant. Common in automotive and industrial nodes.

A rule of thumb to follow: I2C for low-speed sensor clusters, SPI when need throughput, and CAN whenever the environment is electrically noisy or safety-relevant.

Wireless IoT Communication Protocols for the Network Layer

Once the device needs to talk beyond the board, the choice widens considerably:

• BLE: low power, short range. Perfect for wearables and battery-powered sensors.

• Zigbee / Thread: mesh networking for smart-home and building automation.

• LoRa / LoRaWAN: long range, very low power, low bandwidth. Great for agriculture and remote monitoring.

• Wi-Fi: high bandwidth but higher power draw. Best when the device is mains-powered or charged often.

Application-Layer Protocols: MQTT and CoAP

On top of these radios sits the application layer, where MQTT and CoAP dominate:

• MQTT uses a publish/subscribe model. It fits well when many devices report to a central broker.

• CoAP has a REST-like design. It works well when devices need to expose resources directly.

How to Choose the Right IoT Protocol: A Quick Checklist

• Is the device battery-powered? Lean toward BLE, LoRa, or Zigbee.

• Does it move large payloads (images, firmware updates)? Use Wi-Fi or Ethernet.

• Is range measured in kilometers, not meters? Use LoRaWAN or cellular (NB-IoT/LTE-M).

• Do you need guaranteed delivery in a noisy industrial setting? Use CAN or wired Ethernet.

A Minimal MQTT Example

Here’s a typical pattern used on a microcontroller with an MQTT client library once connectivity is established:

mqtt_client_connect(broker_ip, 1883);

sensor_t reading = read_sensor();

char payload[64];

snprintf(payload, sizeof(payload),

"{\"temp\":%.2f,\"hum\":%.2f}",

reading.temp, reading.humidity);

mqtt_publish("devices/node01/telemetry", payload);

Closing Thoughts on IoT Communication Protocols

There is no universally “best” option among IoT communication protocols, only the right one for a given power budget, range, and data profile. Understand the trade-offs across UART, I2C, SPI, CAN, BLE, Zigbee, LoRa, and Wi-Fi, and you can make that call with confidence instead of defaulting to whatever’s most familiar.