There are more IoT protocols out there than most teams will ever need. That sounds overwhelming until you realize most connected products only use two or three; one for local communication, one for cloud connectivity, and sometimes one for device management.
The problem is not the number of options. The problem is that the protocol you pick at the design stage gets baked into your firmware, your cloud pipeline, and your data model. Change it later and you are rewriting half of your stack.
Here is a practical breakdown of the protocols that matter for most developers building connected products today.
The Three Layers You Are Choosing Across
IoT protocols sit in three distinct layers, and you typically pick one from each:
Application Layer → MQTT, CoAP, HTTP, AMQP (how data reaches your cloud)
Network Layer → LoRaWAN, NB-IoT, LTE-M, Wi-Fi, BLE (how data travels physically)
Industrial Layer → Modbus, OPC UA, Profinet (machine-to-machine on the factory floor)
A soil moisture sensor on a farm might use LoRaWAN at the network layer to push data 10 kilometers to a gateway and MQTT at the application layer to deliver that data to a cloud dashboard. Two protocols, two layers, one product.
The Big Three for Cloud Connectivity
MQTT - The Default for a Reason
Publish-subscribe model. Lightweight. Three QoS levels for delivery guarantees. Run over TCP with TLS encryption. Roughly 70% of cloud-connected IoT deployments use MQTT today.
A basic publish looks like this:
import paho.mqtt.client as mqtt
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.tls_set()
client.connect("broker.example.com", 8883)
client.publish("sensors/temperature", '{"value": 23.5, "unit": "C"}')
Use when: You need real-time telemetry, bidirectional device control, or guaranteed message delivery across unreliable networks.
HTTP - Not for Telemetry, But Still Essential
Too heavy for continuous sensor data. But it is the standard for OTA firmware updates, cloud API integrations, and management dashboards. Every cloud platform supports it natively. Every developer already knows it.
Use when: Firmware updates, one-time configuration calls, or anything involving a browser.
The Wireless Layer - Range Decides for You
- LoRaWAN (LPWAN): 2 to 15 km range, very low power. Built for agriculture, smart cities, and any deployment where devices sit kilometers from the nearest gateway on a single battery for years.
- NB-IoT (Cellular): Nationwide range through existing cell towers, very low power. The go-to for asset tracking and smart metering where private gateway infrastructure is not feasible.
- LTE-M (Cellular): Nationwide range with higher bandwidth and mobility support. Fits wearables, vehicle telematics, and devices that move between cell towers while staying connected.
- Zigbee (Mesh): 10 to 100 meters in a self-healing mesh network, very low power. The standard for smart homes and building automation is where every device extends the network.
- BLE (Short-range): 10 to 100 meters, very low power. Pairs naturally with smartphones, making the right choice for wearables, asset tags, and short-range sensor configuration.
- Wi-Fi (high bandwidth): Around 50 meters, high power draw. Not for battery devices, but unmatched for cameras, display panels, and dashboards that need to stream data continuously.
The decision usually starts here. Range and power budget narrow your options to two or three protocols before you even think about the application layer.
Get this right at the architecture stage, and everything downstream firmware, cloud, and compliance gets significantly simpler.
For a deeper dive into all protocols with full comparison tables and industrial protocol coverage, the complete IoT protocols guide on Promeraki covers everything in detail.
What protocol stack are you running on your current IoT project, and is there one decision you would make differently if you started over?
Top comments (0)