When the internet drops: local-first safety and security
Ask every safety device one question before buying it. Then run the unplug test, because the answers are usually more surprising than people expect.
There is a question worth asking about every safety or security device in a home, and hardly anybody asks it before buying: what does this still do when the internet is down?
For a smart bulb the answer barely matters. For an alarm, a lock, a smoke detector or a camera, it matters a great deal — because outages are common, because they tend to coincide with storms and power cuts, and because a connection is trivially easy to interrupt deliberately.
This is not an argument against connected devices. It is an argument for knowing which layer each function lives in.
Three places logic can live
Every automation in your home is executed somewhere, and where determines what survives.
On the device. A smoke alarm's siren, a lock's keypad, a thermostat's own schedule. This layer keeps working through anything short of losing power, because nothing external is involved.
On a local hub. A controller in your house that holds the rules and talks directly to devices over Zigbee, Z-Wave, Thread or your local network. Survives an internet outage completely. Fails if the hub fails.
In the cloud. Rules stored on a manufacturer's servers, with your device reporting up and receiving commands back. Convenient, updatable, and dependent on your connection, their servers and their continued willingness to run the service.
Most homes are a mixture, and that is fine. The problem is when a mixture is accidental, so that a function you assumed was local turns out to make a round trip through a data centre.
The functions that should never depend on the cloud
Our view, and it is not a controversial one among people who build these systems:
Life-safety alarms. A certified smoke or CO alarm sounds locally, on its own, always. The cloud may add notification; it must not be what makes the noise. Verify this rather than assuming it.
Getting into your house. A smart lock must open with a physical key, a code entered on the lock itself, or a local credential — without a phone, without Wi-Fi, without the manufacturer's app. If the only way in is an internet round trip, you have installed a lock with a remote single point of failure.
Local recording. A camera that records to a card or a network recorder still captures the event during an outage. One that only uploads captures nothing.
The siren and the local alarm state. Arming, disarming and sounding should all be possible from inside the house with no connection.
Anything protecting property from physical damage — a water shut-off valve reacting to a leak sensor, for instance. Those decisions want to be made locally in seconds, not remotely.
Where the cloud is genuinely the right answer
Being even-handed about this, some things can only work off-site.
Reaching you when you are not home. Push notifications, by definition, leave the building. Nothing local can substitute.
Off-site copies of footage. If a camera is stolen, local-only recording goes with it. A short cloud retention window for important events is sensible belt-and-braces.
Professional monitoring. If you want a monitoring centre to respond, that is inherently a remote service.
Firmware updates and vulnerability fixes. A device that never phones home also never gets patched, and unpatched network devices are their own risk.
The sensible architecture is therefore local execution with cloud reporting: decisions made in the house, information sent out of it. That way an outage costs you awareness rather than function.
How to find out what you actually have
You do not need to trust anyone's marketing copy. You can test it in ten minutes.
- Disconnect your internet at the router — unplug the cable from the modem, leaving your local network and Wi-Fi running. This is the important distinction: you want the house network up and the outside connection down.
- Try the things that matter. Does the lock open with its code? Does the light switch on the wall still work? Does a motion sensor still trigger the automation it is supposed to? Does the camera record? Does the alarm arm?
- Write down what failed. That list is your dependency map, and it is usually more surprising than people expect.
- Then pull the power to your hub and repeat. This tells you what depends on the hub as opposed to the internet, and it is the test people skip.
Do this before you need to know, and ideally before you buy the next device.
Reducing the dependencies you find
Move logic to the hub. If a rule currently lives in a manufacturer's app, and your hub can express the same rule, move it. Same behaviour, one fewer dependency.
Prefer local protocols for anything load-bearing. Zigbee, Z-Wave, Thread and wired connections operate on your premises by design. Wi-Fi devices vary enormously: some are entirely local, others cannot do anything without their cloud, and the difference is rarely on the box.
Keep physical controls. A wall switch that still works, a key that still turns, a manual valve you can reach. This is the layer that never fails and it is repeatedly designed out in the name of elegance.
Put the hub and router on a small UPS. An uninterruptible power supply keeps them running through the brief cuts that cause most disruption, which also keeps mains-powered mesh devices relaying. Modest cost, disproportionate benefit.
Consider a backup notification path. Some alarm hubs accept a mobile data module, so notifications survive the broadband failing. Worth it if genuine intrusion detection is the point rather than convenience.
The question to ask before every purchase
One sentence, and it filters out a lot of bad buys: if this company disappeared tomorrow, what would this device still do?
For a good lock, thermostat, sensor or hub, the answer is “almost everything, just without remote access”. For a surprising number of products the answer is “nothing at all”, and there is a long list of discontinued smart home products that became inert when a service was switched off.
Ask it about the device, and ask it about the standard it speaks. A device that talks Zigbee, Z-Wave, Thread or Matter can usually be adopted by another controller later. A device that only talks to one company's cloud cannot.
Local does not mean unpatched. Choosing local control is not a reason to keep devices off the network entirely. Anything with a network interface benefits from firmware updates, and abandoning updates trades one risk for another. The goal is a device that functions without the internet, not one that never touches it.
A short resilience checklist
- Certified alarms that sound locally, interlinked independently of your hub.
- A lock you can open with no phone and no network.
- Local recording as primary, cloud as a secondary copy.
- Automations executed on a hub in your house rather than in a vendor app.
- Physical switches and valves retained wherever they exist.
- Hub and router on a UPS.
- The unplug test performed, twice, and the results written down.
None of this is expensive. Most of it is a series of small decisions made in the right order, and the unplug test is the one that tells you whether you made them.