Guide · Wireless · IoT
Zigbee, Wi-Fi, BLE or LoRa? Pick the right IoT radio
There’s no “best” wireless — only trade-offs. You get to pick two of three: long range, years on a battery, and a direct line to the internet. Nail down which two your project actually needs and the choice makes itself. Here are the four that matter for ESP and IoT.
Zigbee / Thread — range and battery, via a mesh
Zigbee and Thread are low-power mesh networks on 2.4 GHz: every mains-powered node relays for its neighbours, so the network heals and stretches around a house without any node shouting far. Battery sensors sip so little that a CR2032 coin cell lasts years. The catch: you need a hub/coordinator (a Zigbee dongle, a Thread border router) to bridge to your LAN. Perfect for door, leak, motion and temperature sensors — dozens of them, quietly.
Wi-Fi — the direct line, at a power cost
Wi-Fi goes straight to your router and on to a server (HTTP, MQTT, WebSocket) with no hub in between — which is exactly why the ESP32 became the default IoT chip. The price is power: an always-listening Wi-Fi radio is milliamps, not microamps, so it’s wrong for a coin cell. Use it for anything mains-powered or anything that needs to serve a page or push to the cloud itself — the whole point of a RisalDash dashboard. To stretch battery life on Wi-Fi, it’s all about deep sleep between bursts.
BLE — talk to a phone, sip power
Bluetooth Low Energy is the short-range, low-power link to a phone or tablet — no router, no account, just pair and go. Great for wearables, locks, and for provisioning (handing a headless device its Wi-Fi credentials from an app on first boot). Range is a room (~10 m) and there’s no internet on its own, but for “configure or read this thing from my phone” nothing is simpler.
LoRaWAN — kilometres, on a shoestring
LoRa trades bandwidth for reach: a few bytes at a time over 5–15 km, on a tiny power budget. It’s the answer for farm sensors, asset trackers and city-wide metering — anywhere cellular is overkill and Wi-Fi can’t reach. You send tiny packets to a gateway, not a stream; don’t expect to push JSON or a web page. On ESP you add a LoRa module (SX127x / RFM95) over SPI — it’s not built into the chip.
The 30-second decision
| Protocol | Best for | Range | Battery | Needs a hub? |
|---|---|---|---|---|
| Zigbee / Thread | many battery sensors in a home | house (mesh) | years (coin cell) | yes |
| Wi-Fi | direct cloud / a served dashboard | a room or two | hungry — mains or deep sleep | no (router) |
| BLE | phone link, setup, wearables | ~10 m | low | no (a phone) |
| LoRaWAN | tiny data over kilometres | 5–15 km | excellent | a gateway |
Which ESP speaks which radio
- Wi-Fi: every ESP32 and the ESP8266. BLE: the ESP32 family (not the 8266). So a plain ESP32 already does Wi-Fi + BLE.
- Zigbee / Thread (802.15.4): the newer ESP32-C6 and ESP32-H2 add the radio for it — the C6 also keeps Wi-Fi 6 + BLE, the H2 is 802.15.4 + BLE only. See the chip guide.
- LoRa: none of them have it on-chip — bolt on an SX127x / RFM95 module over SPI.
Rule of thumb: a battery swarm in one building → Zigbee/Thread; one device that serves its own dashboard or hits the cloud → Wi-Fi; configure/read from a phone → BLE; a few bytes from a far-off field → LoRa. Get the two constraints right and the radio picks itself.
Going Wi-Fi? A live dashboard served straight from the board is a few lines of C++.