What Stays Running When the Connection Drops
A comparison of offline behaviour across LoRa, Wi-Fi, Zigbee and wired control, stated as required, optional and degraded behaviour.
This comparison describes what continues, what pauses and what is lost when a wide area or internet link fails, for four control technologies. It separates required local behaviour from optional cloud features and from degraded behaviour. Offline operation is a property of the whole system, not of the radio alone.
| LoRa | Wi-Fi | Zigbee | Wired | |
|---|---|---|---|---|
| What continues when the WAN or internet link drops | Local schedules, scenes and manual switching continue on the private gateway. | Depends on the design; cloud schedules and remote control pause, and local logic continues only if it is held on a local controller. | Local mesh control continues if the coordinator and local logic stay online. | Control continues while the local controller and the wiring are powered. |
| What continues when the local gateway or coordinator fails | Switches fall back to their defined fail state, and local push buttons remain available. | Wi-Fi control stops; hard-wired switches continue only if they are wired independently of the controller. | Mesh and coordinator-based logic stop; end devices keep only their local defaults. | Stops for the controlled points unless a separate physical switch or bypass exists. |
| Cloud account needed for setup or daily use | Optional. Basic commissioning can be completed on the local gateway without a cloud account. | Often required for setup and for app-based control. | Often required for setup and for app-based control, depending on the vendor. | Not required. |
| Remote status reporting during an outage | Paused. Reports queue and are sent when the uplink returns. | Lost while the connection is down. | Lost while the cloud or internet path is down. | Available only through whatever monitoring path the controller can still reach. |
| Recovery after the link returns | Queued reports are delivered and the remote dashboard catches up; the local state is unchanged. | Remote control resumes; commands missed during the outage are not replayed unless the design buffers them. | Remote features resume; buffered history depends on the coordinator and the vendor. | Monitoring resumes; control was never interrupted. |
| Manual override | Local push buttons plus a defined fail state on each point. | Depends on the switch hardware; app control is unavailable during an outage. | Depends on the device; some end devices keep a physical button. | Usually a physical switch or a bypass at the panel. |
| What a specification must state | Name the gateway, the local rule set, the fail states and the recovery path. | State what runs locally if the internet or the access point is lost. | Confirm the coordinator, its power and the local logic, not only the cloud app. | Confirm the wiring topology, the bypass points and the effect of a controller failure. |
Where LoRa fits
- Sites that must hold a core control routine through a WAN or internet outage without depending on a cloud account.
- Installations where local fail states and manual override have to be defined per circuit.
- Retrofit projects that cannot rely on new cable but still need offline continuity.
- Remote or seasonal sites with an intermittent uplink and no permanent on-site network staff.
Where LoRa does not fit
- Installations that depend on high-bandwidth cloud services or live remote video during an outage.
- Cases where large payloads or dense interactive control must continue with no uplink available.
- Sites already served by a satisfactory wired backbone, where offline behaviour is guaranteed by the wiring itself and is cheaper to extend.
- Positions where the required local gateway cannot be housed, powered or protected against the environment.