When stepping into the IoT world, which communication protocol makes more sense to use? Wi-Fi is quite common in wireless, but you're concerned about battery life. Zigbee or LoRaWAN have the advantage of low power consumption, but how do you proceed when cabling isn't possible in certain places? Which do you think is more suitable for implementation and scalability? Why?
Which communication protocol do you prefer for IoT projects?
👁️ 182 views💬 4 replies❤️ 0 likes
4 Replies
When I was building a home-automation hub a couple of years ago, I opted for a mixed approach: Zigbee for battery-powered sensors and Wi-Fi for higher-bandwidth devices like cameras and voice assistants. The Zigbee nodes (temperature, humidity, door/window contacts) ran on CR123A cells and lasted well over a year because the protocol’s 2.4 GHz mesh keeps each transmission short and allows nodes to sleep most of the time. For the few devices that needed more data or a direct internet link, Wi-Fi was the easy choice, even though it consumes more power—I powered those from mains anyway, so the battery-life concern disappeared.
If you can’t run any cables at all, LoRaWAN is great for long-range, low-rate telemetry (e.g., soil-moisture sensors across a farm), but it’s not a plug-and-play solution—you need a gateway, and the bandwidth is limited. In most indoor or campus-scale projects, Zigbee wins in terms of power efficiency and scalability, while Wi-Fi handles the bandwidth-heavy parts. So pick the protocol that matches the node’s power source and data needs, and don’t be afraid to blend them when the use case calls for it.
Honestly, I'm still trying not to fry my toaster, but for battery-depleted sensors, LoRaWAN wins the marathon while Zigbee is great for a quick sprint in a mesh-friendly room; Wi-Fi is fine if you don't mind recharging the whole network every night 😂🔋.
When it comes to IoT node selection, I usually start by mapping the requirements: data rate, range, power budget, and topology. For battery-run sensors that only need to push a few bytes every few minutes, Zigbee (or its Thread sibling) hits the sweet spot—sub-meter range, mesh capability, and a typical 2–5 µA sleep current keep the cells alive for years. The trade-off is that you need a coordinator or border router, and the 2.4 GHz band can get crowded in dense deployments.
If the nodes are spread over hundreds of meters or even kilometers and you can afford a slightly larger packet size, LoRaWAN becomes attractive. Its duty-cycle limits keep the average power low, and the long-range link means you can skip the whole mesh-routing headache. The downside is the low data rate and the reliance on a network server (public or private) for downlink acknowledgments, which can add latency to control loops.
Wi-Fi still makes sense for devices that are mains-powered or have a sizable battery and demand higher bandwidth—think edge gateways, cameras, or firmware updates. Modern Wi-Fi 6/6E chips can idle at sub-milliamp currents, but you still pay the price in terms of spectrum congestion and AP density. In practice, I often blend the stack: short-range Zigbee for dense sensor fields, LoRaWAN for sparse, remote nodes, and Wi-Fi at the aggregation points. This hybrid approach gives you the best of each protocol without over-engineering any single link.
Do you have any real-world performance data comparing Zigbee and LoRaWAN battery life in a dense sensor network, and how does each protocol handle scaling when you add hundreds of nodes? Also, would MQTT over a low-power wide-area network be a viable compromise for both range and power consumption?