Four questions that settle most cases
How far is the device from infrastructure you control? Metres, and BLE or Wi-Fi are candidates. Kilometres with no infrastructure, and you are looking at LoRaWAN or cellular.
What is the power budget? Mains power removes the constraint entirely. A coin cell for a year rules out almost everything except BLE and LoRaWAN, and rules them in only with careful duty cycling.
How much data, how often? A temperature reading every fifteen minutes is a few bytes. A camera image is six orders of magnitude more, and no low-power long-range technology will carry it.
Who pays the recurring bill, and does anyone want to? Cellular means a SIM and a monthly cost per device, forever. That is sometimes fine and sometimes the thing that kills a business model — worth establishing before the design, not after.
BLE: short range, low power, a phone in the loop
BLE is excellent where a phone or a nearby gateway is part of the design. Power consumption is very low, there is no recurring cost, and every relevant handset already supports it.
The constraints are real. Range is tens of metres in practice, not the optimistic datasheet figure, and walls are unkind. If you need the device to report while nobody is nearby, you need a gateway — at which point you have a second device to power, site and maintain.
The most underestimated difficulty is background behaviour on phones. Both mobile platforms restrict background scanning and connection, and those restrictions will not change to suit your product. Decide early which behaviours need the app in the foreground, because discovering it late tends to invalidate a user-experience design rather than a line of code.
LoRaWAN: kilometres, tiny data, years of battery
For sensors reporting small amounts of data occasionally over long distances, LoRaWAN is often the only sensible answer. Multi-kilometre range, very low power, and no per-device subscription if you run your own gateway.
The price is bandwidth, and it is a hard limit rather than a soft one. Payloads are tens of bytes, duty cycles are regulated, and downlink to the device is limited and awkward. Firmware updates over LoRaWAN are impractical for anything but the smallest patches, which is a significant architectural consequence: plan another update path.
Coverage is also yours to solve. Public networks exist with real but uneven coverage; a private gateway gives control and becomes another piece of infrastructure to power and maintain.
Wi-Fi: convenient where it exists, hungry everywhere
Wi-Fi is the obvious choice for mains-powered devices inside a building with existing infrastructure. Bandwidth is ample, the stack is mature, and there is no recurring cost.
Power is the problem. Even with modern low-power modes, a Wi-Fi radio is far hungrier than BLE or LoRa, and battery-powered Wi-Fi devices tend to mean either a large battery or a short reporting interval, rarely both.
The other cost is onboarding, which is consistently underestimated. Getting a headless device onto a customer's network — with their password, their captive portal, their enterprise authentication — is one of the largest sources of support contacts in consumer connected products.
Cellular: works anywhere, bills forever
For devices that move, or sit somewhere with no infrastructure at all, cellular is the answer. LTE-M and NB-IoT specifically target low-power device use, with much better power characteristics than full LTE while keeping the coverage advantage.
The costs are a recurring subscription per device and higher power draw than the low-power alternatives. Roaming deserves particular attention if devices cross borders — a fleet quietly accruing roaming charges is a genuine operational surprise.
Module certification and carrier approval also add real time to a schedule. It is not difficult, but it is not fast, and it belongs on the plan from the start.
The mistakes that force a redesign
Choosing before knowing the reporting interval. Interval drives power, power drives battery size, battery size drives enclosure and cost. Getting the order wrong means redesigning the mechanical work.
Assuming the datasheet range. Published figures are line-of-sight in ideal conditions. Real deployments have walls, metal, weather and antennas squeezed into an enclosure that was designed for looks. Budget for a site survey.
Treating connectivity as reliable. Every one of these technologies will be unavailable sometimes. Devices that buffer locally and timestamp at source degrade gracefully; devices that assume a live connection lose exactly the data you cared about.
Forgetting the update path. Whatever you choose, work out how firmware gets updated in the field before the first production run. Retrofitting an update mechanism onto deployed hardware is one of the few problems where the answer is sometimes simply no.
And the most common of all: one technology for a system that needs two. BLE for local commissioning and LoRaWAN for routine reporting is a very reasonable combination, and treating the choice as exclusive rules out the design that actually fits.