Radio & Wire

TOOL

IoT protocol picker

Six constraints decide most connectivity arguments before anyone gets to preference. Set them and the picker eliminates every standard that physically cannot meet them, then explains what each survivor costs you.

Range to the nearest hub
Power available
Application data rate
Latency tolerance
Devices on one network
Native IP addressing

Pick the second one when each device has to be reachable without a protocol translator in the middle.

How the picker decides

Every standard below carries six declared figures: the range it holds in its normal deployment, the lowest power class it supports, the application-layer throughput it realistically delivers, its round-trip latency class, the node count one network holds before it needs splitting, and whether devices are IP endpoints. A standard is eliminated when it fails a constraint outright, which is why every elimination below is stated rather than hidden.

What survives is ranked by cost of ownership rather than by capability: a standard that needs nothing but the phone already in the room outranks one that needs a hub you have to buy and run, which outranks one that needs a carrier contract with a monthly line rental. When two standards do the same job, the picker prefers the one that leaves less infrastructure behind.

What it deliberately does not model

Where the picker points at a standard you want to understand properly, the reasoning behind each one is in the guides: Zigbee vs Z-Wave vs Matter, LoRaWAN vs NB-IoT vs LTE-M, Bluetooth LE for wearables, Modbus vs MQTT, and the full connectivity decision guide.