Choosing between Wi-Fi, LoRaWAN and Thread for an office sensor project
The radio choice is made by the building and the battery life you need, not by which standard sounds most modern.
Use a cable for anything that will not move. Inside a building, low-power mesh such as Thread suits battery sensors; Wi-Fi suits devices with mains power and real bandwidth needs. Across a yard or compound, long-range low-power radio such as LoRaWAN carries small readings a long way. Most real sites end up using more than one.
Key takeaways
- Cable anything static and mattering. The radio question only applies to what genuinely cannot be cabled.
- Battery life, not speed, is usually the deciding factor for sensors.
- Wi-Fi is the wrong default for battery devices, because keeping a Wi-Fi radio associated is expensive in power.
- LoRaWAN carries small readings across a compound but is not for anything needing responsiveness or volume.
- Most sites use a combination, and the combination should be a decision rather than an accident.
Start by removing the question where you can
The first move is not choosing a radio. It is working out how much of the project needs one at all. Anything that will sit in one place for years and matters when it stops should take a cable, because a cable supplies power and connectivity at once and removes battery replacement from your life permanently.
That covers most cameras, most door hardware and any sensor near a point you are already cabling. The cost is a cable run at first fix, which is modest while ceilings are open and considerable afterwards, as we set out on the structured cabling page.
What remains is the genuinely wireless set: battery sensors in positions nobody will cable, devices spread across a yard, equipment that moves. That is a much smaller list than the original project, and the radio decision is easier once it is the only thing left.
There is a maintenance argument as well as a cost one. Every battery device is a future visit: somebody with a ladder, at a position that may by then be behind racking or above a machine, on a date nobody scheduled. Twenty battery sensors is twenty of those visits on a rolling cycle. Cabling the ones you can is not only cheaper at install, it removes recurring work that otherwise quietly becomes somebody's job.
What actually decides the choice
Four things decide it, and bandwidth is rarely one of them. Most sensors send a few bytes occasionally, so the question of how fast a technology is almost never matters.
The first is power. A device on mains can use anything. A device on a battery you would rather not change for years rules out most of the options immediately. The second is distance and what is between the device and the receiver, which in a warehouse means racking and stock rather than metres. The third is how quickly you need to know, because a temperature reading every fifteen minutes and a door state within a second are different problems. The fourth is who maintains the infrastructure the devices talk to.
A fifth consideration applies in this climate and is easy to forget indoors. Devices in a yard, on a roof or in an unconditioned warehouse live at temperatures that shorten battery life considerably below the figure on the datasheet, which was measured somewhere more comfortable. Treat quoted battery life as an upper bound for anything outside air conditioning, and plan the replacement cycle accordingly.
- Is mains power available at the device position, or is this a battery device?
- How long must the battery last before somebody has to reach the device?
- What is physically between the device and wherever it reports to?
- How soon does a reading or an alert need to arrive to be useful?
- How many devices will there be eventually, not just in the first phase?
- Who owns the gateway or controller, and what happens when it fails?
Wi-Fi: right for some devices, wrong for most sensors
Wi-Fi is the default suggestion because every building has it, and that convenience hides a poor fit. Keeping a Wi-Fi radio associated with an access point is comparatively expensive in power, which is why Wi-Fi sensors either run on mains or eat batteries at a rate that surprises people.
It is a reasonable choice for devices that have mains power and genuinely need bandwidth, which in practice means cameras where cabling is impossible. It is a poor choice for a battery sensor you intended to install and forget.
There is a second problem that only appears at scale. A few dozen extra devices associating with your access points consume airtime and client capacity that was sized for staff, and the symptom is slower Wi-Fi for people rather than a visible device problem. If devices are going on Wi-Fi at all they belong on their own network with their own expectations, which is the subject of segmenting a network for connected devices.
If Wi-Fi is the right answer for a particular device, check which band and which standard it actually supports before buying. A surprising number of devices are still single-band on the older band, which is the busiest part of the spectrum in any occupied building and the one most affected by neighbours. A device that works on the bench and misbehaves on site is often doing nothing more complicated than competing for airtime.
Thread and low-power mesh inside a building
Inside a building, low-power mesh is usually the better answer for battery devices. Thread, maintained by the Thread Group, is the standard most building devices have converged on.
Mesh matters because of how buildings are built. Rather than every device reaching a single point, devices relay for each other, so a sensor in a far corner reaches the network through its neighbours. In a concrete and glass building that is the difference between coverage and a frustrating map of dead spots, and it means adding devices tends to improve the network rather than strain it.
The trade-off is that mains-powered devices do the relaying, so a mesh of nothing but battery sensors is not really a mesh. Plan for some powered devices in the layout rather than assuming coverage will emerge.
Mesh has one operational characteristic worth knowing before you commit. Because devices relay for each other, removing a mains-powered device can change coverage for sensors that were relaying through it, and the symptom appears somewhere other than where the change was made. It is not a reason to avoid mesh, but it is a reason to record which devices are doing the relaying, so a later change is made with that in view.
LoRaWAN across a yard, a compound or a site
Once the distance exceeds a building, the trade changes completely. Long-range low-power radio, governed by the LoRa Alliance, is designed for exactly the case where a small reading has to travel a long way from a device that must run for years on a battery.
The capability it buys is range and battery life together, which nothing else on this list offers. What it costs is everything else: very little data, infrequent transmission, and no expectation of responsiveness. A tank level, a gate state, a temperature in a remote store, a meter reading: all good fits. Anything needing a prompt response or a continuous stream is not.
It also needs a gateway, which someone must own, power and connect. That is a small piece of infrastructure, and it is the part most often left unresolved in a proposal that describes only the sensors.
Coverage also behaves in ways that surprise people used to Wi-Fi planning. Long-range radio tolerates distance well and obstruction poorly, so a gateway with height and a clear line across a yard outperforms one that is closer but behind a steel wall. The practical consequence is that gateway position is worth testing rather than assuming, and a short survey with a test device saves an argument later about why the far corner of the compound never reports.
| Option | Typical power source | Range | Suits |
|---|---|---|---|
| Cable with power over Ethernet | From the cable | Within the building | Anything static that matters: cameras, door hardware, fixed sensors |
| Wi-Fi | Mains, or short battery life | Within access point coverage | Mains devices needing real bandwidth where cabling is impossible |
| Thread or low-power mesh | Battery, years | Building-wide via relaying devices | Battery sensors indoors, where some mains devices exist to relay |
| LoRaWAN | Battery, years | Across a yard or compound | Small, infrequent readings over distance with no urgency |
Cellular, and when it is the honest answer
A device that moves, or that sits somewhere with no infrastructure of yours at all, is usually a cellular device. It carries its own connectivity, which removes the gateway question entirely and replaces it with a subscription per device and a dependency on coverage at that position.
For a handful of devices that is simple and often correct. For hundreds it becomes an administrative and cost problem that a gateway-based approach avoids, which is the usual reason sites move away from it as they grow.
The questions to settle are coverage at the actual position rather than in the general area, what the device does when it loses signal, and whether readings buffer and forward or are simply lost.
Cost behaves differently here too, and it is worth modelling before committing. Gateway-based approaches cost more up front and very little per device afterwards, while cellular costs almost nothing up front and a recurring amount per device forever. For ten devices cellular usually wins; by a hundred it rarely does. The crossover depends on your numbers, but it is worth calculating rather than assuming, because the decision is hard to reverse once devices are installed.
Why most sites end up with more than one
A real site rarely resolves to a single technology, and a proposal that offers one for everything is usually describing a product rather than answering the question. A warehouse might cable its cameras and door readers, run Thread for temperature and humidity in the office area, and use long-range radio for tank and gate sensors in the yard.
The other thing a combined approach needs is one owner. Where cameras came from a security contractor, sensors from a facilities supplier and a gateway from whoever sold the software, there are three parties and no single person who can say why a reading stopped arriving. That is the most common reason device projects decay quietly after handover, and it is organisational rather than technical.
That is three technologies and it is the right answer, because each is doing what it is good at. What makes it manageable is that they converge: readings land in one place, alerts follow one path, and the whole thing is described in one diagram. Three radios with three dashboards and three apps is the failure mode, and it is a design decision rather than a technical inevitability.
Where readings end up matters as much as how they travel. A dashboard nobody opens is not monitoring, a point we made in cold chain temperature monitoring. If you want the choice made from a site visit rather than a brochure, the connected devices page sets out how the work runs, and you can get in touch.
Whichever radios you end up with, the devices still need a segment and a rule set, which is covered in segmenting a network for connected devices.
Whether any of it has to be registered with the regulator is a separate question, answered in do you have to register an IoT service with TDRA.
Frequently asked questions
You can, and for mains-powered devices it is sometimes reasonable. For battery sensors it usually disappoints, because keeping a Wi-Fi radio associated costs power and battery life ends up measured in months rather than years. At scale there is a second cost: device traffic consumes access point capacity that was sized for staff.
On a low-power technology, years rather than months, and that expectation is the main reason to choose one. If a proposal quotes battery life in months for a sensor sending a reading every few minutes, the technology is probably wrong for the job rather than the battery being small.
Mesh and long-range radio both need something that bridges the devices to your network, and it needs power, a position and an owner. It is a small piece of infrastructure that proposals often leave out because they are quoting sensors. Ask what happens when it fails, because while it is down the readings are not arriving.
That should be a design decision rather than a discovery. Readings can buffer locally and forward when the connection returns, which is usually what you want for anything that is a record. Alerts are different and may need a separate path, because an alert that arrives an hour late has not really arrived.
No, and anyone saying otherwise is describing what they sell. Each is good at something specific: cable for anything static, mesh for battery devices indoors, long-range radio for small readings over distance, cellular for things that move. Most sites use several, and the useful skill is deciding which goes where.
Decide where readings land before choosing devices, rather than after. Different radios can feed one place, and that is a design choice. Where it goes wrong is when each system is bought separately with its own portal, and nobody ever sees the whole picture because it does not exist in one place.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 13, 2026 · 2,162 words
