When the Internet Goes Down, What Happens to Your Building Data?
A gap in a building trend can become surprisingly expensive once somebody needs to explain it.
A tenant reports that meeting rooms were uncomfortable for most of the afternoon. Energy use looks abnormal overnight. Plant appears to have operated outside its normal schedule. The facilities team goes back through the BMS or monitoring platform to establish what happened, only to find that the building’s internet connection was unavailable during the same period.
The building, of course, did not stop operating. HVAC continued to run, spaces remained occupied, environmental conditions changed and equipment kept consuming energy. What disappeared was visibility beyond the building.
That distinction matters as more building monitoring moves beyond the traditional BMS and into wireless sensors, remote dashboards and cloud-based analytics. If every useful measurement has to leave the site before it becomes useful, a relatively ordinary WAN outage can become a gap in the operational record.
A different approach is to keep more of the collection and processing inside the building. With the Robustel LG3120e and E2C Field, LoRaWAN sensors can be managed and decoded locally, while configured MQTT reports can be buffered when an upstream service is unavailable and delivered after connectivity returns. The aim is not to pretend the internet never fails. It is to stop a temporary delivery problem automatically becoming a loss of useful building information.
Keep collection close to the building
LoRaWAN is well suited to this type of architecture because communication between a sensor and a local gateway does not inherently depend on the public internet.
In a local network server deployment, LoRaWAN sensors communicate with the LG3120e on site. E2C Field can decode supported sensor payloads into usable values, or Tags, before those values are forwarded to whatever systems need them. That may include a remote application over MQTT, a local BMS over BACnet/IP, or both.
This creates an important separation between collecting information from the building and delivering that information somewhere outside it.
If the WAN connection fails, sensors may still be able to reach the gateway and E2C Field can continue processing their messages, provided the gateway remains powered, radio reception remains available and the required local services are operating. Where MQTT reporting has been configured to use the cache, pending upload data can be retained within the configured storage capacity and retention period until the upstream service becomes available again.
For a building operator, this is the useful part of an edge architecture. The remote service may be unavailable, but not every useful function has to disappear with it.
Local visibility and historical continuity solve different problems
If the building already has a BMS, there may also be a local path for selected sensor data.
A commissioned BACnet/IP integration between E2C Field and the BMS may continue during an external WAN outage if the building LAN, BMS and relevant gateway services are still operating. That can allow facilities staff on site to retain access to selected live values even while a remote dashboard is unavailable.
It is useful to separate these two requirements because they are often discussed as though they were the same thing.
| Requirement | What it provides |
|---|---|
| Local operational visibility | A commissioned local BMS path may continue presenting selected live values while the WAN is unavailable. |
| Historical continuity | Configured MQTT reports can be retained locally and delivered to the upstream platform after connectivity returns. |
A building may need one or both.
Neither should be confused with uninterrupted cloud availability. A remote dashboard may show stale information or become unreachable during the outage, and replaying cached reports later does not create a real-time alarm retrospectively. Anything that requires an immediate response still needs an appropriate local alarm or control strategy designed for the building and tested during commissioning.
This is one of the more important lessons in resilient building monitoring: deciding which functions genuinely need to remain local is usually more useful than trying to make every part of the system behave as though connectivity can never fail.
Store-and-forward starts with the reporting strategy
The phrase “store-and-forward” can make buffering sound more comprehensive than it really is. The system does not simply save everything indefinitely whenever the internet disappears. It retains the reports that have been configured to enter that delivery path.
E2C Field MQTT reporting can send live Tag values periodically, when values change, or using both methods. The data available for later delivery therefore depends on the reporting strategy selected for the project; a buffered report should not be assumed to represent every LoRaWAN transmission the gateway has ever received.
For facilities teams, the better starting point is to decide what information would actually be useful after an interruption.
A comfort-monitoring application may benefit from regular samples of temperature, humidity or CO₂ so that conditions can be reconstructed across an afternoon. Energy monitoring may need a different interval. Another application may care primarily about a meaningful change in state rather than a continuous stream of values.
Before commissioning store-and-forward, it is worth defining:
- which measurements need to be retained
- whether they should be reported periodically, on change, or both
- the reporting interval appropriate to the application
- how long an interruption the design is expected to cover
- the storage and retention assumptions behind that period
- how the receiving platform will process reports that arrive late
Those decisions determine whether the data recovered after an outage will actually answer the operational question that prompted the monitoring project in the first place.
Recovering the data is not enough if the timeline is wrong
Once the upstream service becomes available again, E2C Field can resume delivery of cached reports. Cache settings allow older cached records or newer cached records to be sent first, and successfully uploaded records are removed from the cache. The appropriate replay order depends on what the destination is expected to do with the backlog.
For building applications, however, transport is only half the problem.
Suppose a room temperature reading was taken at 14:17 during the outage but did not reach the remote platform until 16:03. If the destination treats 16:03 as the time the measurement occurred, the value may be technically present but historically misleading.
That matters because facilities investigations are often built around sequence. When did occupancy increase? When did CO₂ begin rising? When did the HVAC start? When did conditions recover? If delayed information is placed at the wrong point in the trend, the resulting analysis can suggest a relationship that never existed.
The receiving application should therefore be checked for the timestamps and identifiers contained in the selected payload, what survives caching and replay, how late-arriving reports are displayed, and whether repeated delivery creates misleading duplicate events. A successful MQTT transaction confirms that the message moved; it does not prove that the building history has been reconstructed correctly.
Design for the interruption you actually expect
A local cache has finite capacity and a finite retention period. The reporting volume generated during an outage therefore needs to be considered alongside the period the customer expects the system to cover, with additional allowance for the time required to clear the backlog after connectivity returns.
There is little value in discussing this in abstract terms. A building that needs to bridge a short ISP interruption has a different requirement from a site expected to retain useful monitoring information through a much longer loss of connectivity.
It is equally important not to treat every failure as a WAN failure. Different faults affect different parts of the architecture.
| Failure mode | What may continue | What is affected |
|---|---|---|
| WAN outage | Local LoRaWAN collection, processing and potentially the local BMS path | Remote delivery and cloud visibility |
| LoRaWAN radio loss | Gateway and other local services | Messages from affected sensors are not received and therefore cannot be buffered |
| Gateway power loss | Independent building systems | Local LoRaWAN collection, processing and buffering |
| Building LAN failure | LoRaWAN sensor collection may continue | Local BACnet/IP communication with the BMS |
| Remote platform issue | Local collection and processing | Delivery or presentation at the destination |
Cloud-report recovery also does not automatically imply historical backfill into a BACnet BMS. The cloud path and the local BMS path have different behaviours and should be commissioned accordingly.
Thinking about failures this way is more useful than treating “connectivity” as a single thing. It shows which parts of the system are dependent on each other and which can continue independently.
Commission the failure, not only the normal operation
Most systems are handed over after demonstrating that everything works under normal conditions. That proves the sensors can report and the data can reach its destination, but it says very little about the resilience that store-and-forward is supposed to provide.
A useful pilot should deliberately test the interruption.
- Establish a baseline. Confirm that the sensors are reporting correctly, payloads are being decoded as expected and the destination is receiving the configured MQTT data. Where a local BMS integration is included, verify the BACnet/IP values and any stale-data handling as well.
- Remove only the WAN connection. Keep sensor radio, gateway power and the local network operating so that the test isolates the behaviour of the upstream connection rather than introducing several failure modes at once.
- Create a recognisable change. Alter a monitored condition in a controlled way during the outage. A clearly identifiable change makes it easier to verify later that the correct information survived, rather than relying on an hour of largely identical readings.
- Restore connectivity. Allow the cached reports to resume delivery and observe how queued information and current information are handled together.
- Reconcile the result. Compare the destination with what should have been retained. Check the recovered period, timestamps, duplicate handling, replay order and the point at which the remote system is clearly presenting current information again.
The important acceptance criterion is not simply that the WAN reconnects or that a status indicator changes colour. The question is whether the building team receives the information it expected to preserve and can interpret it correctly.
That is the difference between proving a communications feature and commissioning an operational capability.
What a facilities team should expect to know
Once the behaviour has been tested properly, the outcome should be straightforward enough to explain without a networking diagram.
The facilities team should know what information remains available locally during a WAN outage, what stops being visible remotely, which reports are retained for later delivery, how long the designed interruption window lasts, and how recovered data will appear when the connection returns.
The integrator should also be able to document the reporting configuration, cache and retention assumptions, destination behaviour and known limitations. Once established, that collection-and-recovery pattern can become part of the commissioning method for future deployments rather than something investigated for the first time after an outage has already occurred.
This is a more useful way to think about resilience in building monitoring than simply asking whether a gateway has a store-and-forward checkbox.
Start with the building requirement, not the feature
Before configuring the system, the project team should be able to answer a small set of practical questions:
- Which measurements would matter if the WAN disappeared?
- Does the facilities team need live local access to them during the interruption, or is later recovery enough?
- What duration of outage should the system reasonably be designed to cover?
- How should delayed reports appear in trends and dashboards after connectivity returns?
- Which events require immediate local alarm or action regardless of the cloud connection?
- Which other failure modes, such as radio loss, gateway power or LAN failure, need their own acceptance tests?
Those answers determine the architecture.
With LG3120e and E2C Field, Robustel can combine local LoRaWAN network management, payload processing, BACnet/IP integration and MQTT store-and-forward within the same building-level deployment. That gives integrators and facilities teams more control over where useful information is collected, when it depends on the WAN and what should happen when that connection is temporarily unavailable.
Internet outages are not unusual enough to deserve heroic language. They are simply another operating condition that a well-designed monitoring system should be prepared for.
The real measure of resilience is whether the building still has the information it needs when normal connectivity returns.
Planning for connectivity outages in your building?
Start with the information you need to preserve, how long you need to preserve it, and what must remain available locally while the WAN is offline.
Robustel or your integration partner can help you design and validate an LG3120e + E2C Field architecture for local LoRaWAN collection, BACnet/IP integration and MQTT store-and-forward, including the outage and recovery behaviour that should be proven before handover.