Core functions should complete locally

What it is

The design principle for offline degradation: a device's core functions — light on and off, lock and unlock, temperature regulation — should close the loop inside the home network; the cloud carries only the value added: remote access, voice assistants, cross-site scenes, analytics. When the internet drops, what is lost is icing, not cake.

"Core" is not decided by a product manager's intuition but by consequence: functions touching safety (locks, alarms, fire-safety interlocks), health maintenance (heating and cooling in extreme climates) and daily high frequency (lighting) belong to the base layer. Their reason for existing never depended on the network, and neither should their availability.

Why it happens

Functions tier by execution location: Tier 0 mechanical — physical switches operate directly, needing no computation or network; Tier 1 local loop — sensing, decision and execution all inside the home network or gateway, surviving WAN loss; Tier 2 cloud-enhanced — remote, voice, scene integration, learning, failing with the WAN. Degradation design is precisely the act of pushing functions down tiers: core functions at least Tier 1, safety-critical paths preferably with a Tier 0 bypass.

Why the local loop is feasible: the sensor-to-actuator distance is metres, the decision logic is rules and simple models, and a home gateway has compute to spare. The cloud has no technical necessity in these links — its necessity is connection (controlling home from outside) and aggregation (many vendors, many sites), which is exactly Tier 2's definition. Cloud-hosted rule engines are mostly a product of deployment convenience and commercial stickiness (ecosystem lock-in, data return), not functional need.

In implementation, the local loop rests on a local protocol stack: the wireless protocols between device and gateway never leave the house anyway; the automation engine runs on the gateway, so rule triggers never touch the internet. Voice is the standing exception — wake word locally, language understanding historically in the cloud — so voice must never be the sole entry point to a core function.

Studying it

• Architectural argumentation: the local-first software movement (Kleppmann et al., 2019) proposes a set of principles — local as the source of data, network as enhancement — aimed at applications, but its structural argument ("fast path local, slow path as gain") transfers directly to device control; the edge-computing literature similarly argues the latency and availability gains of placing decisions next to the data.
• Outage drill testing: cut the WAN per device and record each function alive or dead, yielding a per-device outage function matrix. Such testing can be standardised as a review item, and it is a method consumers can replicate.
• Long-term in-the-wild comparison: compare availability and recovery times between cloud-architecture and local-architecture households over time — naturally occurring ISP outages and cloud incidents provide the comparison windows.

One methodological caution: outage drills must separate the LAN-down condition from the WAN-down condition; only the latter exposes cloud dependency. Plenty of testing conflates the two and bills the router's failure to the cloud architecture.

Where it stops holding

• Cross-site linkage inherently needs a relay. Monitoring the holiday cabin, remotely looking in on parents — the two ends share no LAN and something must relay. For these scenarios the "cloud" is constitution, not dependency. The critique targets "control inside one room must also transit the cloud", not remote function per se.
• Local compute has a ceiling. Learning automations (personalised schedules, occupancy prediction) train poorly on gateway-class hardware; heavy models still need the cloud. Tiering allows learning to fail while the basic schedule survives — not all-or-nothing.
• Misaligned incentives are the main obstacle. Localisation conflicts directly with cloud subscriptions, data return and ecosystem lock-in. "Technically feasible" and "commercially offered" are separate propositions; procurement must not assume the second.

Applying it

• Tag every function with its Tier 0/1/2 assignment in product requirements, and use the tags as the acceptance checklist for outage testing.
• Choose a local gateway for the automation engine (device-side wireless protocols + gateway rule engine); do not run core scenes on a pure cloud rule engine.
• Beyond voice, always keep a non-cloud control path (on-device control, LAN-direct app, or physical bypass — any one of the three).
• How to check: live normally for 24 hours with the WAN cut, logging every daily action that fails — lights, heating, locking, scene switching. The failure list is the architecture defect list; an empty list is what tiering actually achieved.

Related

• Same group: Z4.03.1 Cloud dependency disables devices when the internet drops · Z4.03.3 Degraded behaviour must be predictable
• Nearby: Z4.01.1 Physical switches provide certain state and tactile confirmation · Z4.09 Faults, disconnection and degradation
• Search terms: local control · local-first · edge computing · graceful degradation