In short
An IoT protocol is chosen on four factors: range, power, data volume and environment. WiFi or Ethernet for powered, data-heavy devices; Zigbee or Thread for sensors inside a building; LoRaWAN for dispersed battery sensors over long distances; NB-IoT or LTE-M where only mobile coverage exists; Modbus or BACnet for existing industrial equipment. MQTT carries data to the platform.
The four key questions
- How far are the sensors from the connection point?
- Is the device powered or battery-run? How long must it last?
- How much data does it send and how often: one reading an hour or continuous video?
- What is already installed: network, industrial equipment, automation system?
Indicative comparison
| Protocol | Range | Power | Data |
|---|---|---|---|
| WiFi | Building, with access points | High | Lots |
| Zigbee / Thread | Building, as a mesh | Low | Little |
| Bluetooth LE | A few metres | Very low | Little |
| LoRaWAN | Kilometres in open country | Very low | Very little |
| NB-IoT / LTE-M | Wherever there is mobile coverage | Low | Little |
| Modbus / BACnet | Equipment wiring or IP network | Depends on device | Equipment readings |
MQTT: how data reaches the platform
Whatever the sensor protocol, a gateway usually translates the data to MQTT or HTTP and sends it to the platform (for example ThingsBoard), where it is stored, visualised and triggers alerts. Separating the sensor layer from the platform layer lets you change one without rebuilding the other.
Common mistakes
- Choosing sensors on price without testing real coverage on site.
- Using WiFi for battery sensors that should last years.
- Relying on a vendor cloud with no way to export the data.
- Not planning how devices will be updated and maintained.