Devices that work when the internet dies

The test of a local-first smart home is what keeps working when the router loses its upstream connection, whatever the marketing claims and the spec sheet say. This guide sorts devices by how they behave in that moment.

Local control behavior varies a lot across devices, and the results aren’t always what you expect.

Short version: run Home Assistant on local hardware, lean on Zigbee, Z-Wave and Matter devices with local control, and keep automations on your local server. Smart bulbs die with the power, and phone notifications fall back to a cloud relay unless you turn on the Companion app’s Local Push, so add a UPS for the server and network plus a local siren for critical alerts. A cellular backup link only has to carry remote access and alerts, so it can sit idle until the cable is out.

The general rule

Devices that talk directly to a local hub over Zigbee, Z-Wave, or Thread will generally keep working. Devices that depend on a vendor cloud for command processing, automation logic, or device communication will generally stop being smart.

Your smart home’s offline behavior depends less on the individual devices and more on where the brains live. If your automations run on a local-first hub like Home Assistant inside your home, they keep running. If they run on a server in Virginia, they don’t.

What works well offline

Zigbee and Z-Wave devices with Home Assistant

This is the strongest offline story. Zigbee sensors, switches, plugs, and lights paired to a local coordinator and automated through Home Assistant keep working exactly as they did before the internet went down. The mesh is local, the hub is local, the automations are local.

Devices worth highlighting:

Zigbee motion sensors and contact sensors, where automations keep firing
Zigbee and Z-Wave light switches, with full local control and no cloud dependency
Z-Wave locks, where lock/unlock commands work through Home Assistant
Zigbee smart plugs, where on/off and energy monitoring stay local
Aqara FP1E and FP1 presence sensors, which are Zigbee and keep working through a local coordinator (the Aqara FP2 is a Wi-Fi device, so it belongs with the Wi-Fi group below)

Matter devices controlled over Thread or your LAN stay reachable the same way, because the WAN is not in that path either.

The coordinator is the piece that matters here. A good Zigbee coordinator paired with Home Assistant gives you the most resilient local setup. The plugs matter almost as much, because every mains-powered one repeats the mesh for the battery devices around it; the best Zigbee plugs for Home Assistant covers which ones report energy and which only switch.

ESPHome devices

Devices running ESPHome firmware are fully local by design. They connect to Home Assistant over your local Wi-Fi network and never touch a cloud server. When the internet goes down, they don’t even notice.

The Everything Presence One is a good example: mmWave presence detection that is completely local. The best mmWave presence sensors for Home Assistant covers how it compares with the other radars in the category.

HomeKit devices with an Apple home hub

Apple HomeKit automations run locally on your HomePod, HomePod mini, or Apple TV. If your internet goes down but your local network stays up, HomeKit automations keep running and you can still control devices from your phone (as long as you’re on the same local network).

The Schlage Encode Plus is a strong example. HomeKit local control keeps working without internet.

What partially works

Wi-Fi devices with local APIs

Some Wi-Fi devices have local APIs or local control modes that work without internet, but with reduced functionality. Shelly devices, for example, have excellent local HTTP APIs and work great with Home Assistant locally. Tuya devices flashed with custom firmware can work locally. Stock Tuya devices without firmware modifications are mostly cloud-dependent.

The pattern: if the device supports a local API or local protocol that Home Assistant can talk to directly, it usually keeps working. If Home Assistant has to go through a cloud bridge, it doesn’t.

Smart locks

Locks are complicated. Most smart locks will still lock and unlock physically regardless of connectivity, and they all have a physical key or keypad as a fallback. But the “smart” features vary:

Z-Wave, Zigbee, or Matter-over-Thread locks controlled through Home Assistant, where smart features keep working locally
Wi-Fi locks like August, where the lock works mechanically, but app-based smart features may not
Bluetooth locks, which work if your phone is nearby, but remote and automation features are limited

See my smart lock guide for more detail on local control realities.

What stops working

Cloud-dependent voice assistants

Alexa and Google Assistant stop processing commands when the internet is down. Your Echo and Google Home speakers become Bluetooth speakers (if that). Voice-triggered automations that run through these platforms stop entirely.

This is the single biggest failure mode in homes that build their whole automation stack around Alexa routines or Google Home automations. Home Assistant’s own Assist with local speech-to-text is the local-first alternative.

Cloud-relayed phone notifications

Notifications are the piece people most often get wrong. By default the Home Assistant Companion app receives pushes through a cloud relay - Apple’s APNs on iOS, Firebase on Android - so if your home internet is the thing that’s down, those never arrive. There is a local path, though: the Companion app’s Local Push delivers notifications over your own LAN through the WebSocket API instead of APNs or Firebase, so no internet is involved. It needs Home Assistant core 2021.6 or newer plus the iOS/macOS app 2021.7+ or the Android app 2022.2+, and it only engages while the app is connected over your internal URL, which means marking your home Wi-Fi SSIDs as internal. That condition is the catch, because a phone that has wandered onto cellular is back on the cloud relay, so turn it on and still back critical alerts with a local siren or speaker announcement that needs no phone at all.

Remote access from outside the house

Reaching your dashboard from outside the house (via Nabu Casa or a reverse proxy) depends on internet, but local control from inside the house does not. If you rely on remote access, it’s worth comparing the tradeoffs of Home Assistant Cloud vs Tailscale vs a Cloudflare tunnel, and for a true fallback path, the cellular fallback at the end of this guide.

Cloud-only cameras

Cameras that stream exclusively through vendor clouds (Ring, most Blink cameras, cloud-only Wyze setups) lose their smart features. They may continue recording to a local SD card if they have one, but you lose remote viewing, notifications, and cloud-based detection.

Cameras with RTSP or ONVIF support that stream to a local NVR (like Frigate on Home Assistant) keep working fine.

Cloud-dependent smart plugs and switches

Cheap Wi-Fi smart plugs that only work through a vendor app (Tuya cloud, Smart Life, etc.) stop responding to app commands. The device itself stays in whatever state it was in, but you can’t control it remotely or trigger automations.

Vendor-bridged integrations

Any integration where Home Assistant talks to a vendor’s cloud to reach the device fails when the internet goes down. This includes many popular integrations: stock Tuya, Ring, Nest (some features), and others.

How to audit your own setup

Here’s a practical test:

Unplug your internet connection (just the WAN cable from your router, keep your local network running)
Wait a few minutes for cloud connections to time out
Walk through your house and test every automation and device
Note what works, what is degraded, and what is dead

Do this before you need it, not during an actual outage. It’s revealing.

Building for resilience

The playbook is boring on purpose. Start by listing what matters day to day: lights, the thermostat, door locks, and any security sensors. For each, prefer devices that speak a local protocol - Zigbee, Z-Wave, Thread/Matter, or a local API over your LAN - rather than Wi-Fi devices that only work through the manufacturer’s app and servers. Use Home Assistant as your automation engine, because it runs locally, and use ESPHome for custom devices, since it is fully local by design. Don’t build critical automations on cloud-dependent platforms, and keep voice assistants as a convenience layer, not the foundation.

Run Home Assistant on local hardware you own. Purpose-built options like the Home Assistant Green (the Home Assistant Yellow was discontinued in October 2025 but still works if you own one) keep the whole system on your network, and the Home Assistant Connect ZBT-2 (which replaced the discontinued Connect ZBT-1) adds a local Zigbee or Thread radio. Once your automations live on a local box, they run regardless of your internet connection. A “turn on the hallway light when motion is detected after sunset” rule doesn’t care about your ISP.

You don’t need to be paranoid about this. Some cloud features are fine for non-critical things. But your lights, locks, climate control, and security automations should work without the internet.

Power outages are a different problem: add a UPS

An internet outage and a power outage are different problems, and a smart home plan should cover both. If the power goes out, your Home Assistant server, your network gear, and every mains-powered device go dark - including all your smart bulbs and any mains-powered sensors. Smart bulbs need mains power to work at all. A Philips Hue or LIFX bulb is not battery-powered - if the power is out, the bulb is off, full stop. For lighting that survives a power outage you need battery lanterns or a UPS, not a smart bulb.

A small UPS (uninterruptible power supply) is the single best investment here. Put your Home Assistant server, your router, and your Zigbee/Z-Wave coordinator on a UPS so the brain and the radios survive a brief outage. Consumer UPS units from brands like APC and CyberPower are inexpensive and will typically run a low-power Home Assistant server and a router for a meaningful stretch - long enough to ride out short outages and shut down cleanly during long ones.

Keep in mind that battery-powered sensors (door/window, motion, leak) keep running during a power outage, but they still need a path back to the hub, and a UPS on the hub is only half of that path. Battery sensors are Zigbee and Z-Wave end devices: they never route traffic themselves, so they reach the coordinator through your mains-powered bulbs, plugs, and in-wall switches. When those go dark, an orphaned sensor does not instantly find another way in - it sleeps through the outage and only looks for a new parent on its next rejoin cycle, which can take hours, and some older models stay isolated until you re-pair them. If particular sensors have to keep reporting through a power cut, put a couple of the mains-powered routers near them on the UPS as well.

A zero-data cellular fallback

Everything above means most of the house keeps working on its own when the home internet drops. The thing a cellular backup saves is the stuff that does need the internet - remote access, push notifications, and any cloud-dependent integrations. That makes a cellular failover a connectivity tool, not an automation tool. You’re not buying it to keep your lights on - they were never at risk. You’re buying it so you can still check the cameras and get alerts while the cable is out. There is no magic “no data” switch, but a link that only carries traffic during an outage comes close.

Pick a way onto cellular

There is no consumer device that does “cellular with zero data.” A cellular link is a real LTE/5G connection through a modem and a SIM, and it uses data whenever traffic flows over it. The way to keep that traffic near zero is to only use the link during an outage. A few real options, easiest to most capable.

The cheapest backup is a phone hotspot: tether a phone’s hotspot to your router’s secondary WAN. Fine for short outages; just watch your plan’s hotspot cap. A step up is a travel router with a USB modem. A small OpenWrt box like the GL.iNet Mango (GL-MT300N-V2) supports tethering and 3G/4G USB modems, and can do multi-WAN failover from a wired uplink to the cellular dongle, with modest throughput but plenty for HA traffic. The proper answer is a dedicated cellular gateway. The GL.iNet Spitz AX (GL-X3000) is a Wi-Fi 6 router with a built-in dual-SIM 5G NR / 4G LTE modem and built-in WAN/SIM/repeater failover, and for business-grade hardware a Cradlepoint does the same job.

Drop the SIM into the cellular device, and put a cheap data SIM or a low-cost IoT/backup plan in it - you won’t use much.

Make it fail over automatically, and only when needed

The goal is a link that sits idle until your primary WAN dies, then carries traffic, then steps back when the cable returns. Any dual-WAN / WAN-failover router does this:

OpenWrt uses mwan3: give your primary WAN a metric of 0 and the cellular interface (usually wwan or ppp0) a higher metric like 10, so cellular is only used when the primary can’t route. mwan3 pings targets to decide when to switch. Test your real config - some setups detect the outage but need tuning to fail over cleanly.
UniFi gateways, pfSense, and OPNsense all have dual-WAN failover with the cellular link set as the backup gateway.
The GL.iNet gateways above and Cradlepoint have failover built into their own firmware.

Because the cellular path is the backup, it draws essentially no data while your main connection is healthy - that’s the closest thing to “zero data” that exists. Bonus: with mwan3 you can write a script in /etc/mwan3.user to fire an MQTT message on failover, so Home Assistant knows it’s running on the backup link and can react (for example, switch to a low-data mode).

Keep data use down on the backup link

Cellular data is metered, so treat the failover link as precious. Cap it: set a data limit on the SIM or plan, or use your router’s traffic limits, so a runaway upload can’t blow the budget. Pause heavy uploads during failover by disabling cloud camera uploads, off-site backups, and large media syncs while you’re on cellular; if HA knows it’s on the backup link (see the MQTT trick above), an automation can flip those off automatically. And trim notifications, because you want alerts, not chatter, and high-frequency sensor pushes add up.

Done right, an outage costs you a few megabytes of remote access and alerts, not gigabytes.

Remote access during an outage

All the usual Home Assistant remote-access methods work over cellular, because to them it’s just another internet connection.

Home Assistant Cloud (Nabu Casa) is one toggle and works behind CGNAT, which matters, since many cellular plans put you behind carrier NAT; it is the simplest option and it funds HA development. I compare all three remote-access options in Home Assistant Cloud vs Tailscale vs Cloudflare Tunnel. The Tailscale community add-on builds a WireGuard mesh between your devices, works through CGNAT and uses very little data when idle. Self-hosted WireGuard via the add-on is the choice if you’d rather not depend on a third party, with one note: a plain port-forward to your home is often impossible on cellular because of CGNAT, so prefer Nabu Casa, Tailscale, or WireGuard with a relay.