The wireless protocol decision is one of the most consequential early choices in an IoT product design. It affects your MCU selection, your antenna design, your regulatory obligations, your cloud infrastructure, your battery life, and your firmware architecture.
Most teams make this decision too casually — either defaulting to WiFi because it is familiar, or copying what they saw in a reference design. Here is a more structured way to think about it.
BLE: when to choose it
Bluetooth Low Energy works best when: - The device talks to a phone (companion app required) - Range requirements are under ~50m line of sight - Power budget is tight (coin cell or small LiPo) - Data rates are low and bursts are short
BLE is available in almost every modern MCU ecosystem (nRF52, ESP32, STM32WB) and has a mature toolchain. The advertising/connection model adds firmware complexity, but Nordic's nRF5 SDK and Zephyr both handle much of it.
Watch for: BLE 5.x range extension claims are real but highly environment-dependent. Plan for 20–30m indoors as a realistic typical range.
WiFi: when to choose it
WiFi wins when: - The device needs to talk to a cloud backend directly - Throughput matters (video, audio, large data payloads) - The device is mains-powered or has a large battery - You need zero additional infrastructure on-site
The tradeoffs are real: an ESP32 in active WiFi typically draws 80–200 mA. On a 500 mAh battery, that gives you 2–6 hours of active operation — which is fine for many use cases, but eliminates months-long battery life scenarios.
For battery-powered sensors, the deep sleep / wake-transmit-sleep duty cycle matters enormously. Well-tuned, an ESP32 can run for months — but it requires careful firmware architecture.
Do not use WiFi for a product that will be deployed in industrial or agricultural environments without WPA2-Enterprise or similar. Consumer-grade networks are not a reliable deployment target.
LoRaWAN: when to choose it
LoRaWAN is designed for one specific use case: low-data-rate, long-range, low-power, wide-area sensor networks.
Choose it when: - Devices are in the field — outdoors, spread over a large area - Data payloads are tiny (sensor readings, status flags, GPS coordinates) - Battery life of months to years is a requirement - You have access to LoRaWAN network coverage (TTN, Helium, private gateway)
Typical LoRaWAN A class device: transmitting every 30 minutes at SF7, average current draw around 3–6 µA. On a 1200 mAh AA-equivalent battery, that is over 10 years of theoretical operation.
The tradeoff is harsh: maximum payload per transmission is 51–242 bytes depending on spreading factor and regional parameters. No streaming, no large payloads.
Decision matrix
Quick decision guide:
| Requirement | BLE | WiFi | LoRaWAN |
|---|---|---|---|
| Phone companion app | ✓ best | ✓ possible | ✗ no |
| Cloud backend direct | ✗ needs gateway | ✓ best | ✓ needs network |
| Battery life (months+) | ✓ possible | ✗ difficult | ✓ best |
| Range (km+) | ✗ no | ✗ no | ✓ best |
| High throughput | ✗ no | ✓ best | ✗ no |
| Infrastructure-free | ✓ | ✓ | ✗ needs gateway |