Which Smart Home Devices Survive a Texas Power Grid Outage
Which smart home devices keep working through a Texas grid outage is decided by protocol and configuration before the storm arrives. This guide shows how Matter, Zigbee, Z-Wave, and Thread devices behave when the power drops, which units expose a power-restoration setting, and why a UPS for the router and hub is the highest-leverage preparation.
Last updated
A Texas grid outage is a bad test for casual smart-home assumptions. During Winter Storm Uri, 69% of Texans surveyed lost power, the average disruption was 42 hours, and 71% lost internet service.[1] That 42-hour average is the number that matters for smart-home planning: it is long enough for many small backup batteries to be exhausted, long enough for cloud control to become irrelevant if the internet is down, and long enough to reveal whether a sensor network is actually local or only looks local on a normal day.
For a Texas power-grid outage, the useful smart-home answer is not a brand list. The devices most likely to remain useful are battery-powered Zigbee and Z-Wave sensors joined to a locally hosted hub, as long as the hub, router, and radio network path still have power. Cloud-dependent Wi-Fi devices, voice assistants, and app-only control become fragile once broadband drops. Matter can help with one specific outage problem — what a powered device does when electricity returns — but Matter 1.3 power-restoration behavior only helps when the actual plug, bulb, or switch exposes the setting in the app or hub you use.[2]

The outage survival hierarchy
The first purchase that usually moves the needle is not another leak sensor or another Matter plug. It is a UPS sized for the modem or gateway, router, and smart-home hub. Without that powered chain, a battery-powered contact sensor may still have charge, but the system that hears it may be dead.
| Layer | What has to survive | Outage judgment |
|---|---|---|
| Battery Zigbee or Z-Wave sensor on a local hub | Sensor battery, hub power, and local radio path | Best candidate for useful outage status, especially contact, motion, leak, and temperature sensors |
| Local hub automations | Hub power and the devices in the automation | Useful if the rule does not require cloud services, speakers, or unavailable powered devices |
| Matter device | Device power, controller or hub power, fabric health, and exposed settings | Promising, but not automatically resilient; power-restoration behavior depends on device and app support |
| Thread device | Device power plus a powered Thread border router and controller path | Can be local, but a sleeping device is not useful if the border router or controller path is dead |
| Wi-Fi device with cloud control | Device power, router power, broadband, vendor cloud, and app path | Often becomes partial or unavailable when internet service is lost |
| Voice assistant or smart speaker control | Speaker power, Wi-Fi, internet, account services, and device integrations | Convenient on normal days; poor as the only control path during a long outage |
For a device-class baseline — what tends to be Works, Partial, or Off when the power drops — use the existing smart-home device outage table. The Texas-specific question is narrower: which protocol path is still alive after the outage has lasted long enough to take out both mains power and internet service?
Why Zigbee and Z-Wave sensors usually get the first seat on the lifeboat
A battery-powered Zigbee or Z-Wave contact sensor does not need the wall outlet beside it to stay energized. A leak sensor under a sink, a door sensor on an exterior door, or a motion sensor in a hallway can keep its own radio alive as long as its coin cell or AA battery holds up. The catch is upstream: the local hub has to remain powered, and the automation or alert path has to avoid cloud-only dependencies.
That mechanism is why these devices are often the most defensible smart-home layer in an outage. They are low-power, they can report to a hub over a local radio network, and they do not inherently need broadband to produce a state change inside the house. The hub may be Home Assistant, Hubitat, SmartThings hardware with local-capable routines, or another controller; the label matters less than whether the relevant device state and automation can run locally while the WAN is gone.
There is still no magic in the protocol name. Zigbee mesh repeaters are often mains-powered plugs, bulbs, or in-wall modules. When those repeaters lose power, the mesh topology changes. A nearby battery sensor may still reach the coordinator directly; another device that usually hops through a dead plug may not. Z-Wave has similar practical limits around route availability and hub power. Local-first does not mean outage-proof. It means there are fewer unnecessary dependencies between the sensor and the decision-maker.
A useful documented example comes from Creating Smart Home’s August 2026 account of a 10-minute blackout. In that case, Zigbee and Z-Wave battery devices continued to report through local infrastructure while Wi-Fi and hub-power weak points showed up quickly.[3] That is worth paying attention to, but it is not proof of multi-day resilience. Ten minutes does not test UPS runtime, battery age, frozen mesh routes, broadband restoration delays, or what happens after the second night of an ERCOT event.

Where Wi-Fi, cloud apps, and speakers become partial
Wi-Fi is not the villain. A locally controlled Wi-Fi device on a powered router can still be useful inside the home. The weak version is the device whose control path leaves the house before anything useful happens: app to vendor cloud, cloud to device, voice assistant to cloud, then back through the integration. When the internet is down, that path is broken even if the device itself has power.
Consumer reporting from WRAL in January 2026 described the same practical failure mode: smart-home features that depend on Wi-Fi, speakers, apps, or cloud service can stop being available during outages, leaving owners with devices that are powered but not meaningfully controllable.[4] That distinction matters. A plug that still passes electricity is not the same as a plug you can command. A lock that still works with a key or keypad is in a different category from a lock whose only convenient control was a cloud-mediated app.
For safety devices, keep the fallback separate from the smart layer. Battery-backed smoke and CO alarms, mechanical keys, local lock keypads, and offline lighting are not made obsolete by automations. If you are sorting that part of the house, the more relevant companion page is smart-home power outage safety, not another cloud integration.
Matter’s useful outage feature is narrower than the marketing sounds
Matter is most useful in this outage conversation when it gets specific. The important question is not whether a device is “Matter-compatible.” It is whether the device exposes a power-restoration setting: turn on when power returns, stay off, or restore the last state. Matter 1.3 can standardize that behavior, but a household only benefits if the particular device, firmware, and controlling app or hub expose the setting.[2]
This matters most for powered devices: smart plugs feeding lamps, bulbs in fixtures, switches, and appliance-adjacent plugs. After an outage, the wrong default can be annoying, unsafe, or simply misleading. A lamp may turn on at 3 a.m. when utility power returns. A plug may stay off even though the owner expected the attached device to resume. A switch may restore the last state, which is desirable in one room and wrong in another.
| Matter device tested | Power-restoration setting exposed? | Available behavior | Status to use before relying on it |
|---|---|---|---|
| Bosch Matter smart plug tested by matter-smarthome.de | Yes | On, stay off, or restore last state | Hands-on result from one source; re-check your model, firmware, and app before treating as Confirmed.[2] |
| Eve Matter smart plug tested by matter-smarthome.de | Yes | On, stay off, or restore last state | Hands-on result from one source; re-check your model, firmware, and app before treating as Confirmed.[2] |
| IKEA Matter smart plug tested by matter-smarthome.de | Yes | On, stay off, or restore last state | Hands-on result from one source; re-check your model, firmware, and app before treating as Confirmed.[2] |
| Ledvance Matter smart plug tested by matter-smarthome.de | Yes | On, stay off, or restore last state | Hands-on result from one source; re-check your model, firmware, and app before treating as Confirmed.[2] |
| Meross Matter smart plug tested by matter-smarthome.de | No | No exposed restoration choice in the cited test | Investigating / not confirmed as generally absent; firmware and app updates can change this.[2] |
| TP-Link Tapo Matter smart plug tested by matter-smarthome.de | No | No exposed restoration choice in the cited test | Investigating / not confirmed as generally absent; firmware and app updates can change this.[2] |
Read that table like an outage notebook, not a permanent compatibility verdict. The cited hands-on testing records device and firmware context, but Matter devices are moving targets. Firmware updates, app updates, and hub support can add or remove what you actually see. Before the next storm window, open the controlling app or hub for each Matter plug, bulb, or switch and verify the restoration option on the device you own.
For a lamp you want available when power returns, “restore last state” may be the right setting. For a plug feeding something you do not want unexpectedly energized, “stay off” is safer. For a small night light in a hallway, “on” may be intentional. The protocol can expose the choice; it cannot choose the right default for your house.
This is also where battery backup and power defaults intersect. A UPS may keep the hub alive, but it does not fix a smart plug that returns in the wrong state after mains power comes back. The separate guide on what battery backup cannot fix during a power outage is the better place for the broader limitations; for Matter devices, the immediate job is to check the exposed restoration behavior now, while the lights are still on.
Thread still needs a powered border router
Thread often gets lumped into local-first planning because it can carry Matter devices over a low-power mesh. That can be useful, especially for battery sensors. But a Thread device still needs a working path through a Thread border router and a controller. If the border router is a smart speaker, display, Wi-Fi router, or hub that has no backup power, the sleeping sensor at the edge of the mesh is not the limiting factor. The powered infrastructure is.
For outage prep, treat Thread border routers the way you treat Zigbee coordinators, Z-Wave sticks, and local hubs: identify them, decide which one is supposed to survive, and put that device on the same backup-power plan as the router and hub. If you do not know which box in the house is the border router, the system is not yet prepared.
Power returning can be its own failure event
The outage is only half the test. The other half begins when utility power comes back and every powered device tries to rejoin, refresh routes, reconnect to Wi-Fi, renegotiate with a hub, or restore a previous state. A house can look fine from the breaker panel and still have a smart-home stack that is confused for the next hour.
One Home Assistant core issue reported Matter devices becoming unavailable after a power cycle, with the user describing no recovery path except manually re-adding the devices.[5] That should be treated as a reported failure mode, not proof that Matter devices generally behave that way. It is still useful as a warning: power cycling is not a clean laboratory restart in a real home. Hubs, controllers, bridges, routers, and endpoint devices may all come back in a different order.
The practical response is to know your recovery order. Bring the modem or gateway up, then the router, then the hub or controller, then bridges and powered repeaters, then endpoint troubleshooting. The detailed version already exists in the smart-home reconnect order after an outage; the Texas twist is that you should not be learning that order while the house is hot, dark, and running on phone battery.

The prep order before the next ERCOT event
Start with the boring chain. Put the modem or gateway, router, and primary smart-home hub on a UPS. If you use a separate Zigbee coordinator, Z-Wave controller, Thread border router, or Ethernet switch that sits between the hub and the network, include that too. A battery sensor is only useful if something powered is still awake to receive and act on its message.
- Inventory the devices that matter during an outage: exterior contact sensors, leak sensors, freezer or refrigerator temperature sensors, locks, local lighting, thermostats, cameras, and network gear.
- Mark each one as local, cloud-mediated, or unknown. Unknown should be treated as partial until tested.
- For Zigbee and Z-Wave, identify which battery devices still report when broadband is disconnected but the hub remains powered.
- For Thread, identify the border router and confirm it is on backup power if Thread devices are part of the outage plan.
- For Matter plugs, bulbs, and switches, open the actual controller app or hub and set the power-restoration behavior intentionally.
- For Wi-Fi and cloud devices, decide what still works without internet and what falls back to manual control.
- Run one controlled drill: disconnect internet, leave the router and hub powered, and watch which automations still fire.
Do not let kitchen anxiety consume the first backup-power budget unless there is a specific medical or safety reason. Ready.gov says a closed refrigerator keeps food cold for about 4 hours, and a full freezer holds temperature for about 48 hours if the door stays closed.[6] That does not make food loss irrelevant. It means a small UPS is usually better spent keeping the router-and-hub chain alive than trying to run kitchen circuits it cannot realistically support.
For sizing and drills, use the smart-home storm prep recipe. For DHCP reservations, network naming, and making the router-hub path less brittle, use the network-layer power outage prevention guide. If you want the house to tell you when utility power fails before broadband disappears, build that from the power outage alert automations rather than relying on a cloud push notification that may arrive after the network is already down.
The final sorting rule is plain: local and battery-powered gets trusted first; local but mains-powered gets tested for restart behavior; Matter gets checked device by device for exposed restoration settings; Thread gets judged by its border router; cloud-only devices are only partially prepared. Before the next long Texas outage, the house does not need to look smarter. It needs the router, hub, radios, and a few boring sensors to stay alive.
References
- Winter Storm Impact, Texas Comptroller Fiscal Notes, October 2021
- Which Matter smart plugs report energy data?, matter-smarthome.de
- Smart Home Power Outage: What a 10-Minute Blackout Taught Me About My Smart Home’s Weak Points, Creating Smart Home, August 7, 2026
- Prepare for outages: essential tips for smart home power failures, WRAL, January 2026
- Home Assistant core issue #161886, GitHub
- Power Outages, Ready.gov
Known issues with this device / protocol
Spec-version history
For active regressions on this protocol, see Update Watch.
No linked Update Watch entries yet.
