Adding monitoring to an occupied building is mostly a cabling problem. Running new signal cable through finished ceilings, risers and tenant areas is slow, disruptive and expensive. Low-power wireless networks such as LoRaWAN make it practical to put sensors where cable cannot easily go.
But LoRaWAN is one part of the architecture, not the whole of it. This note explains where it fits, where other connections do a better job, and how to plan a retrofit that stays dependable for years.
What LoRaWAN is good at
LoRaWAN is designed for small, infrequent messages sent over long distances using very little power. In buildings, that suits:
- Battery-powered sensors for leaks, temperature, humidity, air quality, door state and occupancy.
- Devices spread across many floors, plant rooms and car parks.
- Status and configuration data that does not need to arrive within a fraction of a second.
One gateway can often cover several floors, but concrete cores, steel and basements reduce range, so coverage always needs to be confirmed on site.
Where it is not the right tool
LoRaWAN's low data rate and limits on how often a device may transmit make it unsuitable for:
- Immediate local control, such as switching lights the moment someone walks in.
- Large data, such as images or high-frequency measurements.
- Equipment that already offers a wired interface such as RS485, Modbus or BACnet.
Those needs are better served by Bluetooth for local interaction, wired contacts or RS485 for existing equipment, and Ethernet, Wi-Fi or 4G for gateways and higher-bandwidth devices.
Combine local and central wireless
A practical pattern is to let nearby devices talk to each other directly over Bluetooth for fast actions, while LoRaWAN carries status, alarms and settings to the central platform.
For example, an occupancy sensor can switch its light fitting locally and instantly, and the platform still receives the occupancy and energy data. If the central link is interrupted, the local behaviour carries on.
Plan coverage, not just the number of gateways
There is no reliable rule of thumb for how many devices one gateway can serve in a building. What matters is whether every device location has a dependable signal.
- Survey signal strength at the real device locations, including risers, plant rooms, lift lobbies and basements.
- Allow for fire doors, concrete cores, metal ceilings and future fit-out changes.
- Place gateways where they have power and a dependable backhaul connection, such as Ethernet or 4G.
- Keep the survey results as a baseline for future troubleshooting.
Design for maintenance from day one
Battery-powered devices need a maintenance plan before they are installed, not after the first one goes quiet.
- Battery-life estimates based on the actual reporting interval.
- Alerts for any device that stops reporting.
- A device register with location, ID and installation date.
- A process for replacing batteries and devices without losing their history.
Keep integration open
The building owner should know exactly how data leaves the IoT platform and reaches the building management system, an energy platform or a reporting tool. During detailed design, document:
- Payload formats and units.
- APIs or MQTT topics, and who maintains them.
- Responsibilities between the IoT, building-management and IT teams.
- What happens to data and alarms when a link fails and recovers.