Which Smart Home Devices Keep Working During a Power Outage

The useful answer starts with a split that many outage guides blur: a smart device can fail because the device has no power, because the local network or hub has no power, or because the internet/cloud path is gone while everything inside the house is still powered.

Those are three different failures. A mains-powered smart bulb cannot turn on if the circuit is dead. A Zigbee switch cannot receive a hub command if the hub and router are dark. A powered Matter plug may still be reachable through one local controller while its manufacturer app says it is offline. The difference is not the logo on the box. It is where control actually lives.

First, separate a power outage from an internet outage

When people ask which smart home devices keep working during a power outage, they often mean one of these situations:

The third case is where the compatibility traps live. It feels like everything should work: the device is powered, Wi-Fi is up, the phone is on the same network, and the packaging may mention a local protocol. Yet control can still vanish if the app path goes through a vendor cloud or if the controller the user actually opens is not functioning locally.

The Matter lesson: local protocol does not guarantee the app in your hand works offline

Matter is the cleanest way to see the gap between protocol promise and usable outage behavior. In a Matter Alpha offline test, Matter devices could work without internet in principle through a local controller, but the tested Govee, SwitchBot, and Aqara manufacturer apps reported devices offline or refused control when internet access was removed. Google Home also failed during that offline test.[1]

That result should not be stretched into “Matter does not work offline.” It shows something more specific and more useful: Matter’s local design does not automatically make every manufacturer app, platform app, or user-facing control path local. A device can be reachable by a local controller while another app, looking through its normal cloud-backed route, gives the person in the hallway a gray tile.

This is why offline claims need to be tied to a path: the device, the controller, the hub or border router, the app, and the automation engine. “Supports Matter” is not the same as “the app you use at midnight will still unlock the door when the ISP is down.”

Protocol-by-protocol: what usually survives when the cloud disappears

The map below assumes the home still has local power for the relevant devices, hub, router, bridge, or border router. If those are not powered, the protocol cannot rescue the system.

Zigbee and Z-Wave: strong offline candidates, if the hub is alive

Zigbee and Z-Wave get real credit here. When devices are paired to an on-premises hub, the hub can continue sending commands and running local automations without depending on a vendor cloud, provided the hub and the relevant local network equipment still have power. Full Spectrum Technology Group describes Zigbee, Z-Wave, and Thread devices connected through local hubs as able to continue operating commands and schedules without internet; EVVR makes a similar vendor-stated claim for hub-connected local smart home devices.[2][3]

The caveat is not small. A Zigbee motion sensor can report motion all day, but if the hub that interprets that motion is dead, the hallway light automation is dead too. A Z-Wave switch can be physically pressed at the wall, but an automation that depends on a powered hub will not run if the hub has gone dark.

This is where a UPS belongs in the conversation, but only as part of the chain. Backing up the hub while leaving the router, bridge, or controller unpowered may preserve some automations and not others. For network-layer hardening, NestGrid’s separate guide to smart-home power outage prevention covers the recovery-resistant details: IP leases, router startup order, and the equipment that has to come back cleanly.

Thread: local radio, controller-dependent result

Thread is a local low-power mesh, but the user does not control a Thread device by admiring the mesh. Control still passes through a border router, controller, platform, app, or automation engine. If those remain powered and local, Thread can be part of a resilient setup. If the only working path is an app that wants the cloud, the local radio is not enough.

This becomes especially important as phones, speakers, displays, TVs, and hubs take on Matter controller or Thread border-router roles. A device can be a controller in the architecture without being the offline path you actually use. For more on the controller role itself, see NestGrid’s discussion of the Pixel 11 as a smart-home hub.

Matter: test the controller, not just the badge

Matter’s best idea is local interoperability. Its messy part is that most homes do not interact with “Matter” directly. They interact with Apple Home, Google Home, Alexa, SmartThings, a manufacturer app, Home Assistant, a bridge, or a mix of all of them. The Matter Alpha test is useful because it pulled on that seam: local operation may be possible, yet some familiar app paths failed without internet.[1]

So the practical question is not only “Is this device Matter?” It is:

• Which controller commissioned it?
• Which app will you open during an outage?
• Does that app issue local commands when the internet is unavailable?
• Do automations run on the local controller or in a cloud service?
• If the manufacturer app shows the device offline, does another local controller still control it?

Cloud-first Wi-Fi: powered does not mean controllable

Cloud-first Wi-Fi devices are the common disappointment. They may be plugged in, joined to Wi-Fi, and visible on the LAN, but the app can still route commands through vendor servers. Full Spectrum Technology Group describes cloud-dependent Wi-Fi devices as losing app-based control when the internet is unavailable, and the Matter Alpha test showed the same kind of user-facing failure in tested manufacturer apps under offline conditions.[1][2]

Some Wi-Fi devices do support local APIs, local integrations, or local Matter control. Others do not. The dividing line is not “Wi-Fi bad.” It is whether the device accepts local commands from a controller that remains available when the WAN is down.

What this means by device category

Protocol tells you the control path. Device category tells you what the outage feels like in the house. A sensor that keeps reporting locally is a quiet success. A lock that still opens by keypad but loses push alerts is a partial success. A camera that is powered but cannot load live view because the service is cloud-shaped is not much comfort.

Lights and switches

Lights are where architecture shows up immediately. If the light circuit is out, the smart layer is irrelevant. If the circuit is live but the internet is down, a Zigbee or Z-Wave switch paired to a powered local hub is in a much better position than a cloud-first Wi-Fi bulb controlled only through a vendor app.

Wall switches also preserve one underrated fallback: physical control. Even if the app is useless, a hardwired switch may still turn the load on and off at the wall when power exists. Smart bulbs in always-on fixtures do not offer the same kind of graceful fallback if their only control path is an unreachable app.

Sensors

Battery sensors are often better outage citizens than the app makes them look. A contact sensor can still detect open/close. A motion sensor can still see movement. A leak sensor can still detect water. The question is whether anything powered and local is listening.

If a battery leak sensor reports to a powered local hub and that hub runs the siren or shutoff automation locally, the automation has a real chance of running during an internet outage. If the useful part is a push notification routed through the cloud, the sensor may have done its job while the person who needed the alert hears nothing.

Locks

Smart locks deserve partial-status language. EZVIZ says battery-powered smart locks can continue local entry methods such as fingerprint, keypad, or physical key access during a power outage, while app alerts and remote control depend on connectivity and may stop.[4]

That split matters more than the marketing category. A lock that opens by keypad is still a working lock. A lock that cannot send a remote unlock command or arrival alert is missing smart features, not necessarily failing its core job. The bridge, Wi-Fi module, or hub may be the weak link rather than the lock body.

Cameras and video doorbells

Cameras are the category to treat with the least optimism. They are bandwidth-heavy, app-heavy, account-heavy devices. Many useful camera features — remote live view, cloud recording, person detection, package detection, push alerts, history timelines — are shaped around cloud services. A powered camera on a powered LAN may still fail the thing the owner expects: opening the app and seeing what is happening.

Local recording changes the calculation, but only if it has been configured and tested. A camera recording to local storage or a local NVR is different from a camera that merely connects by Wi-Fi. The test is not whether the camera has power; it is whether live view, recording, playback, alerts, and detection still work when WAN access is blocked.

Thermostats

Thermostats sit between the smart-home outage and the HVAC outage. If the heating or cooling equipment has no power, the thermostat cannot make it run. If the HVAC system and thermostat remain powered but internet access is gone, the split is between local temperature control and cloud-dependent extras.

A thermostat may continue a local setpoint or schedule while losing remote app access, weather-aware adjustments, geofencing, occupancy routines, utility-program integrations, or voice control. Any automation that says “if outdoor temperature does X” or “when everyone leaves” should be treated as cloud-dependent unless proven otherwise in that specific setup.

Automations only survive if the execution engine survives

A local sensor and a local switch are not enough if the rule connecting them runs in the cloud. The automation engine is its own dependency.

If a hub such as Home Assistant, Hubitat, or another local controller runs the rule on premises, that rule has a chance during an internet outage. If the rule lives in a vendor cloud, a voice-assistant routine, or an integration between remote services, it should be marked cloud-dependent until tested.

For households that want to monitor the hub and UPS chain itself, NestGrid’s power outage alert automations recipe is the more appropriate place to handle NUT-based outage detection. Here, the compatibility point is simpler: the automation must execute somewhere that still exists during the failure.

The hub, bridge, router, and border router are part of the device

For outage planning, a smart device is not just the plastic thing mounted on the wall. It is the chain that makes control happen: device, radio network, hub or bridge, router, controller, automation engine, app, and sometimes a cloud service.

That is why “local protocol” can be true and still not enough. A Zigbee plug depends on its hub. A Thread sensor depends on a border router and controller. A Matter device depends on the controller and app path. A cloud-first Wi-Fi device depends on the vendor service. A camera may depend on local storage, a base station, or an upload path. Each dependency needs power, and some need internet.

If devices do drop and then fail to return cleanly after utility power comes back, that is a different problem from offline capability. NestGrid’s guide to smart-home reconnection after the Duke Energy outage covers the recovery order after the fact.

How to verify a device before you trust it offline

Do not test outage resilience by cutting power to the whole house first. That mixes device power, network power, and internet failure into one noisy result. Start by leaving the home powered and disabling WAN access at the router or modem. The goal is to isolate the cloud path.

1. Identify the protocol: Zigbee, Z-Wave, Thread, Matter over Thread, Matter over Wi-Fi, ordinary Wi-Fi, Bluetooth, or a proprietary bridge.
2. Identify the controller: local hub, Matter controller, Thread border router, manufacturer bridge, phone app, voice assistant, or vendor cloud.
3. Disable internet while keeping local power on. Do not unplug the hub, router, or bridge for this first test.
4. Try the manufacturer app and the platform app separately. A device may fail in one and work in another.
5. Run the physical control: wall switch, keypad, fingerprint reader, local button, key, or thermostat faceplate.
6. Trigger the automation that matters: motion-to-light, door-to-scene, leak-to-shutoff, thermostat schedule, freezer alert, or lock routine.
7. Mark voice, remote access, push alerts, geofencing, weather, camera recognition, cloud recording, and cross-vendor cloud routines as separate features, not proof of local control.
8. Repeat the test after app, firmware, hub, or platform updates that change the control path.

Write the result in plain language: “Keypad works; app remote unlock fails; local hub lock automation runs; push alert fails.” That kind of note is more valuable than a compatibility badge because it records the behavior of the actual device, hub, app, and control path as tested.

The device that keeps working during an outage is the one whose necessary control path still has power and does not need the unavailable cloud. Zigbee, Z-Wave, Thread, and Matter can all be part of that answer. None of them remove the need to verify the app, controller, hub, bridge, automation engine, and fallback controls in the home where the outage will actually happen.

References

1. Do Matter devices work without Internet? Matter Alpha.
2. Smart Home Without Internet Full Spectrum Technology Group.
3. What Happens to Your Smart Devices During a Power Outage EVVR.
4. How Smart Locks Work During a Power Outage EZVIZ.