Smart home won't reconnect after the Duke Energy outage
Smart home devices stay unavailable after Duke Energy outage
Last updated
The bad move, right after power returns, is opening the app, seeing half the house marked unavailable, and immediately deleting devices. A Zigbee sensor, Thread device, Matter accessory, or Wi-Fi plug can look dead while it is really waiting for something upstream: a router, access point, hub, coordinator, bridge, or border router that came back late, came back confused, or is still rebuilding its view of the network.

Use this order before re-pairing anything:
| Order | What to recover | What not to do yet |
|---|---|---|
| 1 | Get the modem, router, access points, smart-home hub, Zigbee coordinator, Thread border routers, and Matter controllers stable. | Do not judge end devices while the network stack is still booting. |
| 2 | Let mains-powered mesh devices settle: Zigbee routers, Thread routers, Wi-Fi mesh nodes, smart plugs acting as repeaters, bridges, and powered switches. | Do not pull batteries or factory-reset sleepy sensors. |
| 3 | Refresh the hub view only after upstream networking is stable. Then check whether devices report back naturally. | Do not rename entities or rebuild automations because one dashboard card is gray. |
| 4 | Reboot the hub, coordinator, or controller only if the network is stable but the hub still has a stale view. | Do not reboot everything in a loop. |
| 5 | Re-pair only the specific devices that remain unavailable after the mesh has had a real chance to rebuild. | Do not bulk-delete working-but-late devices. |
That order matters after the August 2026 Duke Energy derecho because utility restoration and smart-home restoration are not the same event. Duke Energy said more than 340,000 Greater Cincinnati customers were affected and that power was restored from Aug. 11–15; it also said 85% of customers were restored in under 48 hours and that self-healing grid technology restored about 23,000 customers automatically.[1] Other local reporting captured different outage snapshots: WLWT reported more than 260,000 outages, Axios Cincinnati cited Duke spokesperson John Juech at more than 274,000, and the Cincinnati Enquirer reported outages down 70% from peak by Aug. 13.[2][3][4]
Those figures should not be flattened into one magic count. They are useful because they pin this to a real, dated regional outage after the Aug. 11 derecho, not because a smart-home dashboard cares whether the peak number was described one way or another in a news story.[5] The hallway problem is simpler: the lights are on, the refrigerator is humming, and the smart home is still half gray.
Why “unavailable” does not automatically mean broken
Most smart-home devices do not talk straight to your phone. They report through layers. A battery contact sensor may need a mains-powered Zigbee router. A Thread bulb may need a Thread border router and the Matter controller that knows its fabric. A Wi-Fi device may need the access point, router, DNS, DHCP, internet path, cloud service, and local integration to stop arguing with each other.

After a whole-house outage, these layers do not necessarily return in the order your automations expect. A modem may take longer than the router. A mesh access point may boot before it has backhaul. A Zigbee plug that normally repeats for three nearby sensors may be on a switched outlet that was left off. A border router may come online before the controller that stores the Matter relationship is reachable. The device at the edge gets blamed because it is the visible failure, but the missing part is often several hops upstream.
Matter and Thread: the expensive failure mode
The sharp warning sign is not that every Matter device will fail after an outage. It is that when Matter recovery fails, the cleanup can be ugly. A Home Assistant core issue titled “Matter devices become unavailable after power outage or power cycle” describes Matter devices becoming unavailable after an outage or power cycle, with the reported outcome including manual re-adding and automation reconfiguration.[6]
That is exactly why re-pairing belongs at the end of the recovery sequence. Re-pairing may create a new device record, new entity names, broken dashboards, and automations that no longer point at the thing in the room. If the only problem was that the controller, border router, or network path had not finished recovering, deleting the accessory turns a temporary outage into configuration work.
A few anecdotal forum snippets that were not independently reproduced describe Thread or Zigbee recovery taking from hour-scale delays to overnight. Treat that as Investigating or Workaround-level context, not confirmed behavior. It is enough to justify patience before destructive steps; it is not enough to promise a specific recovery clock.
Zigbee: the child may be waiting for its parent
Zigbee adds another trap. Battery sensors and buttons often sleep most of the time. They usually depend on mains-powered routers — bulbs, plugs, in-wall switches, repeaters — to carry messages back to the coordinator. A Home Assistant Community thread about Zigbee devices losing connections after a power cut describes the familiar mechanism: when powered routers drop out, end devices can lose their parents, and the mesh has to rebuild after power returns.[7]
That community thread is useful mechanism evidence, not a standards manual. Still, it matches what many small installs teach the hard way: the sensor in the hallway is not the first thing to touch. First make sure the powered devices that form the route back to the coordinator are actually powered, joined, and in their normal places. A plug moved during cleanup, a lamp switch left off, or a repeater sitting on a dead power strip can strand several devices that look unrelated in the app.
Wi-Fi, cloud devices, and hubs: boring infrastructure still wins
Wi-Fi devices fail less mysteriously, but they are not exempt. If the router boots without internet, if the access point comes up before the main gateway, if DHCP hands out addresses before everything is ready, or if a hub starts before the network it depends on, the dashboard can show stale failures. Home Assistant, Hubitat, SmartThings, bridge-based lighting systems, and cloud integrations all need a stable path before their status screens become trustworthy.
This is why the useful backup advice after the Duke Energy outage starts with the network stack, not with individual bulbs. If the hub and network came back cleanly, you have a chance at a boring recovery. If they came back in pieces, every downstream device becomes a suspect even when most of them are innocent.
The recovery order before you re-pair anything

Start with a physical pass, not the app. Look at the modem, router, access points, hubs, bridges, PoE switch, Zigbee coordinator, and any Thread border routers. If one of them is dark, blinking in an abnormal pattern, or plugged into a power strip that tripped, the device list is not ready for interpretation.
- Restore internet and LAN first. Confirm that the modem is online, the router is routing, Wi-Fi is broadcasting, and wired hubs or bridges have link lights.
- Bring access points and mesh nodes back before judging Wi-Fi devices. A device may be reachable only through the access point in that part of the house.
- Check that smart-home controllers are reachable locally. That includes Home Assistant, Hubitat, SmartThings hubs, lighting bridges, Matter controllers, Zigbee coordinators, and Thread border routers.
- Verify mains-powered repeaters. For Zigbee, that means plugs, bulbs, switches, and repeaters that normally route traffic. For Thread, that means powered Thread routers and border routers. For Wi-Fi, that means APs and mesh nodes.
- Wait before touching sleepy end devices. Battery sensors, buttons, locks, and remotes may not report immediately just because you are staring at the dashboard.
Only after that pass should you refresh the smart-home platform’s view. In Home Assistant, that may mean checking integration logs and the device page before doing anything destructive. In Hubitat or SmartThings, it may mean checking whether the hub sees the device as offline or whether the route has simply not recovered. For bridge systems, open the bridge’s own app or admin page before blaming the individual accessory.
If the network is stable but the hub still appears confused, reboot the hub or coordinator once. One clean reboot after the upstream network is healthy is different from cycling the whole house repeatedly. Repeatedly rebooting everything can keep changing the failure while you are trying to observe it.
What to check by symptom
| Symptom after power returns | Most useful first check | Re-pair now? |
|---|---|---|
| Many devices across different brands are unavailable | Router, access points, hub, DNS/DHCP, and internet path | No |
| Only one Zigbee area is missing | Powered Zigbee routers in that part of the house: plugs, bulbs, switches, repeaters | No |
| Battery sensors are unavailable but nearby powered Zigbee devices are also missing | Recover the powered routers first, then wait for sleepy devices to report | No |
| Matter devices are unavailable after a power cycle | Matter controller, Thread border router if used, hub logs, and network stability | Not yet |
| One device remains unavailable after the rest of its route is healthy | Power, battery, physical reset state, and whether the hub still has a valid device record | Maybe |
| A device works in its vendor app but not in the hub | Integration, bridge, cloud/local connection, and entity mapping | Usually no |
The important split is “one device is actually gone” versus “the path to a group of devices is gone.” If five sensors in one wing disappear together, factory-resetting all five is usually vandalism with extra steps. Find the repeater, access point, bridge, or power strip they depended on.
For a broader device-by-device expectation table, keep this separate from the recovery job and use what smart-home devices do during a power outage. The point here is not to predict every brand behavior before a storm; it is to avoid making the wrong first move after the storm.
When re-pairing is justified
Re-pairing is not forbidden. It is just expensive. Use it when the evidence points to a device-level failure rather than a network recovery delay.
- The hub, router, access points, bridges, coordinator, and relevant border routers are stable.
- Nearby mains-powered repeaters are online.
- Other devices on the same protocol and in the same area have recovered.
- The device has fresh power or battery and is not physically switched off.
- A single clean hub or coordinator reboot did not restore it.
- Logs or the platform’s device page show that the old relationship is not coming back, rather than merely late.
Before deleting, look for a repair or rediscovery path that preserves identity. Some platforms can re-interview, rediscover, or repair a device without losing the existing entity names. If deletion is unavoidable, note the device name, automations, scenes, dashboards, and room assignment first. The five minutes spent writing that down is better than discovering later that the hallway motion automation now points at an entity that no longer exists.
Matter deserves extra caution here because the failure mode documented in the Home Assistant issue included manual re-adding and automation reconfiguration.[6] If your Matter device is unavailable but the controller or Thread border router has just come back from a power event, re-pairing may be the step that creates the larger problem.
The backup lever that actually reduces cleanup next time
A UPS does not keep a whole smart home alive. It will not make a dead utility line power your bulbs, and it will not stop every brand from using its own power-on default. For that boundary, see what battery backup can’t fix in a smart home power outage.
What a UPS can do is keep the control plane from collapsing during short outages and flickers. HomeTechHacker’s UPS guide gives a concrete anchor: a typical modem, router, and hub stack draws about 25–40 watts.[8] That is the load worth protecting first if the goal is less post-outage cleanup.
Put the modem, router, primary access point or mesh base, smart-home hub, Zigbee coordinator, and the most important Thread border router or Matter controller on protected power where your setup allows it. If your access points depend on a PoE switch, the PoE switch may be part of the protected stack. If your Thread border router is inside a smart speaker or display, decide whether that device is part of the recovery-critical layer or just a convenience controller.
Do not turn this into a fantasy where every endpoint has backup power. The useful target is narrower: keep enough upstream infrastructure alive that, when utility power returns, the hub and mesh have not forgotten the room. For UPS sizing, outlet selection, and a pre-storm test routine, use the dedicated smart-home storm-prep recipe rather than rebuilding that plan during an outage.
After the Duke outage, most unavailable devices are better treated as downstream devices waiting on infrastructure, not as broken accessories. Restore the stack, let the mesh rebuild, reboot the hub only after the network is stable, and save re-pairing for the devices that still fail after that. Next time, the practical upgrade is not a bigger dashboard or a new protocol sticker. It is keeping the modem, router, hub, and relevant border-router or access-point layer on a UPS so the smart home has less to reconstruct when the lights come back.
References
- Duke Energy thanks Greater Cincinnati customers for their patience and support as storm workers restored power after rare derecho — Yahoo Finance
- Power outages severe storms Cincinnati Ohio Duke Energy map — WLWT
- Inside Duke Energy’s race to restore power — Axios Cincinnati
- Duke Energy outages down 70% from peak: When will power be back? — Cincinnati Enquirer
- SevereWx Derecho Aug11th2026 — National Weather Service Northern Indiana
- Matter devices become unavailable after power outage or power cycle — GitHub
- Zigbee lost connections for some devices after power cut — Home Assistant Community
- How to Choose the Right UPS for a Smart Home — HomeTechHacker
Corroborating context
For protocol background on why this failure happens, see Compatibility & Protocols.
Not currently linked to a known regression. Background on the underlying protocol lives in Compatibility & Protocols.
