Failover and local policy
Which behaviour must resolve on the edge, how a site is tested for local-first operation, and what degrades — and does not — when the uplink is lost.
| Document revision | r0.1-draft |
|---|---|
| Status | draft |
| Applies to | LS-GW-100, LS-GW-300, LS-DIN-4CH, LS-RC-16A, LS-RC-25A |
| Regions | global |
| Published | Oct 15, 2026 |
| Review due | Apr 15, 2027 |
| Author | Engineering documentation (owner unassigned) |
| Reviewer | Engineering sign-off pending (reviewer unassigned) |
Local-first is a property of where a rule resolves, not of where the data is stored. A schedule held in the cloud and evaluated in the cloud is not local-first even if the device has flash memory. This document states which behaviour must resolve on the edge, how to prove it, and what legitimately degrades.
Preconditions
- The node registry is committed and every endpoint that a rule references has a stable identity, per Pairing and addressing.
- The gateway has a local power source and a time base that has been verified, per Edge controller setup.
Which behaviour resolves on the edge
Resolve locally — these must survive the loss of the uplink:
- schedules and timers that control real loads at a defined time;
- scenes triggered by a local input, such as a wall button or a dry contact;
- threshold alarms raised by local sensor readings;
- the fail-safe state of a relay on power loss.
May depend on the uplink:
- remote dashboards, historical reporting and outbound notifications;
- firmware distribution and configuration backup;
- anything that requires data from outside the site to compute.
Proving local-first operation
1. Disconnect the uplink physically
Remove the uplink rather than blocking it in software. A software block can leave a queued request that later succeeds and hides the fault.
2. Run each local behaviour
Execute one schedule, one scene and one alarm with the uplink absent, and confirm each acts on the real endpoint and is written to the local log.
3. Reintroduce the uplink
Reconnect and confirm that outbound reporting resumes and that no local behaviour changed as a result. If behaviour changes when the uplink returns, that behaviour was not local.
4. Power-cycle and repeat
Power-cycle the gateway with the uplink still absent and repeat step 2. Local-first behaviour must survive a power event, because that is when the site most needs it.
What degrades, honestly
- Outbound notifications and remote dashboards are queued, not lost, and are delivered when the uplink returns.
- Cloud-computed analytics pause. Nothing should be promised as always-connected.
- Fail-safe behaviour on power loss is a defined device state, not a guarantee that the load remains energised; the state is per SKU and stated on the model page.
Failure modes
- Rule behaves differently with the uplink up: the rule is resolving in the cloud; move it to the edge.
- Schedule fires late after an outage: the time base drifted; re-check it before editing the rule.
- Alarm raised locally but not delivered: outbound delivery is queued, not immediate; this is expected, not a fault.
Placeholder — pending engineering sign-off: the outbound queue depth, the retry schedule and the notification delivery window are not published yet and are set per gateway generation.
Limitations
- The boundary between "resolved locally" and "may depend on the uplink" is fixed, but the names of the configuration objects that implement it are per-SKU and are given with the model page.
- No always-connected guarantee is offered anywhere in this set. Any figure describing delivery latency after an outage is a placeholder until measured.
What this document does not cover: the diagnostic steps for a rule that does not resolve as expected are in Diagnosis checklist, and the interface by which an external system observes these events is in API and webhooks.