What your smart home does when the internet is gone

The outage should be boring

A smart light can be three metres from your phone and still need a journey to somebody else's servers before it responds. On a normal evening that path is hidden by a quick tap and a working internet connection. During an outage, the household discovers the architecture one unresponsive device at a time.

The useful question is not “is this a smart device?” or even “does it use Wi-Fi?” It is: where is the decision made, and which working systems must carry the command and the reply? A device may use the local network for setup but a vendor cloud for everyday control. Another may accept local commands while sending notifications through a remote service. “Works locally” can describe one feature without describing the whole product.

The aim is not to ban cloud services. It is to make their loss unsurprising, proportionate and recoverable.

Classify the path in household language

Home Assistant's IoT classes offer a useful starting point because they describe the integration path rather than the badge on the box. Translate them into questions a household can answer:

This classification answers two different questions. “Local or cloud?” tells you where the control path goes. “Push, polling or assumed?” tells you how quickly and confidently the controller learns what happened. A local integration can therefore survive a WAN outage yet still show stale state for a polling interval. An assumed-state integration can display success without knowing whether the physical device moved at all.

Treat the class as a clue, not a warranty. Check the documentation for the exact integration and test the functions you rely on. Firmware, configuration and optional vendor features can change the path even among devices sold under one brand.

• **Local push:** the controller talks directly to the device, and the device reports a change as it happens.
• **Local polling:** the controller talks directly to the device but checks periodically, so a changed state may appear later.
• **Cloud push:** the integration depends on an active internet connection, while the cloud sends new state when it becomes available.
• **Cloud polling:** the integration depends on an active internet connection and checks for state periodically, adding the possibility of delay.
• **Assumed state:** the controller cannot read the device's actual state and can only infer it from the last command.

Build an inventory around consequences

Here is an invented example household. Its list is deliberately about functions, not real brands or a private network. For each item, record the integration class, what it controls, what stops when its remote dependency disappears, and the safe manual path.

Add columns for “WAN unavailable”, “vendor account unavailable” and “home controller unavailable”. Those are different failures. A local integration may pass the first two and fail the third. A cloud integration may fail the first while the device's physical controls continue normally. An expired account session may block an app even though the internet is healthy.

Prioritise by consequence. A decorative lamp can wait. Heating, access, doors and smoke or leak warnings deserve documented manual operation and a test schedule. For safety equipment, follow the product's instructions and applicable local guidance; a home-automation dashboard is supplementary, not evidence that the underlying protection works.

• **Hall lamp — local push.** Local app and automation control should be tested with the WAN disconnected. Consequence is low; the wall switch is the fallback.
• **Heating schedule — local polling.** The local controller may continue to exchange state, but remote changes and notifications are separate dependencies to test. The heating equipment's own safe controller and documented manual operation remain the fallback.
• **Entry lock status — assumed state.** A command is not proof of the physical result. The household checks the door and keeps the manufacturer's approved non-cloud access method available.
• **Bathroom leak notification — cloud push.** If the cloud path fails, the remote notification may disappear. The household treats any device-level alarm as primary, tests it according to its instructions and never makes an automation the only warning path.

Run three small failure drills

Do not wait for a real outage to discover the answers. Choose a calm time, tell everyone affected and avoid disabling any safety-critical function. Then test one boundary at a time.

First, disconnect only the WAN while leaving the home network and controller running. Record which dashboards load, which commands work, which state updates arrive and which notifications do not. Second, sign out of a vendor account or use a documented test method without deleting the account; this separates account dependency from connectivity. Third, stop or isolate the home controller briefly only where the device has a known safe manual path. Confirm that manual switches, controls and alarms behave as their instructions say.

For every failed function, record the observed result rather than “offline failed”. “Wall switch worked; dashboard command timed out; physical state was not reported” is actionable. It tells you whether to accept the limitation, change an integration, add a local control path or improve the household note.

Local control still has dependencies

Local connectivity reduces one dependency; it does not erase the rest. The Connectivity Standards Alliance describes Matter as local connectivity, while noting that away-from-home control for Matter-only devices needs an internet-connected controller in the home. Some devices can also connect directly to their maker's online service. So a Matter logo does not, by itself, answer which app features, updates or remote controls survive an outage.

Thread makes a different part of the path more resilient. A Thread Border Router carries traffic between the low-power mesh and the rest of the home network, and multiple Border Routers can keep that route available if one goes offline. That helps with a networking failure. It does not keep the home controller powered, preserve a broken automation, renew an account or deliver an internet notification.

A local-first design also concentrates responsibility at home. The controller needs power, backups, updates and a recovery path. If it becomes the only place where decisions are made, its failure matters more. Keep critical manual controls outside it, and record how the household will operate while it is being restored.

What we would do next

We would inventory the five household functions with the greatest consequence, verify each integration's current IoT class, and run the WAN-loss drill before buying replacement hardware. The result should be a one-page note: what keeps working, what becomes unavailable, what safe state is expected and which manual action to take. If an outage then feels boring, the design has done its job.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Integration manifest — Home Assistant. Defines assumed-state, cloud-polling, cloud-push, local-polling and local-push IoT classes, including whether communication is direct, needs an active internet connection or may report state later.
2. Matter FAQs — Connectivity Standards Alliance. Describes Matter as local connectivity and explains that away-from-home control for Matter-only devices needs an internet-connected controller in the home.
3. What is a Thread Border Router and How is it Different from a Hub or a Bridge — Thread Group. Explains that a Thread Border Router carries traffic between the low-power mesh and the rest of the network, and that multiple Border Routers can preserve that path if one goes offline.

More from Server Attic

• 2026-07-20

  Home Assistant automations that fail clearly

  A practical way to design household automations so missed conditions, failed actions and recovery steps are visible instead of mysterious.

• 2026-07-22

  Make home automations fail safe first

  A practical checklist for designing Home Assistant automations that recover clearly, leave evidence and avoid doing the wrong thing twice.

• 2026-08-19

  A health check is not a recovery plan

  A practical home-server guide to separating liveness, readiness and restart signals from the human decisions that make recovery safe.