Smart Home Devices Offline After Outage? Recovery by Hub

Current to Q3 2026: if your smart home devices are offline after a power outage, do not start with a factory reset, mass device removal, or immediate re-pairing. Those three moves can erase the very identities your hub may still be able to recover.

Start with the fork that actually matters: is the hub itself up, are the devices still listed but unresponsive, or are devices gone from the list? The recovery path changes by hub behavior, not by a broad claim that “Zigbee,” “Z-Wave,” or “Matter” behaves one way after an outage. If you only need the basic bring-up order, use the broader power-outage device triage and storm restore order. This guide is for the uglier moment when the hub is back, but it came back wrong.

The first triage gate: stop before you change device identity

Before touching a device, look at the hub-side symptom. A bulb that is greyed out in an app is not the same problem as an empty Z-Wave table, a failed MQTT broker lookup, or a Matter CASE-session error. The app tile is only the surface.

• Hub is not reachable: recover power, network, storage, add-ons, and hub services first. Device work waits.
• Hub is up and devices are listed but unresponsive: suspect a service, radio, broker, mesh rebuild, driver, or fabric problem before suspecting every device.
• Devices are gone from the list: stop. That is the highest-risk branch. Check the hub’s database, radio table, coordinator state, or platform incident path before re-adding anything.

That restraint matters because several documented recoveries preserve existing devices. In one Home Assistant + Zigbee2MQTT case, the failure was not dead Zigbee devices at all; Zigbee2MQTT could not resolve the Mosquitto add-on hostname and logged “getaddrinfo ENOTFOUND core-mosquitto” after an outage because the broker add-on was no longer set to start on boot.[1] In that state, deleting devices would be busywork with consequences.

Hub-indexed recovery scan

The table is deliberately hub-first. For more on why one outage can break different platforms in different ways, the protocol-level map is covered separately in why power outages break smart home devices differently and which smart home devices keep working during a power outage. During recovery, protocol theory is less useful than knowing whether the broker, radio, database, or fabric is the part that failed.

Home Assistant + Zigbee2MQTT: check the broker and coordinator before the devices

On a Home Assistant stack using Zigbee2MQTT, the first split is not “are my Zigbee devices bad?” It is whether Zigbee2MQTT can reach its MQTT broker and whether the coordinator is alive.

If Zigbee2MQTT will not start or all devices look dead

Open the Zigbee2MQTT logs and the Mosquitto add-on state. The useful clue from the documented outage case was the exact log line “getaddrinfo ENOTFOUND core-mosquitto,” which pointed to Zigbee2MQTT failing to resolve the broker hostname after the outage. The reported fix was to re-enable Mosquitto start-on-boot and restart the stack, not touch the Zigbee devices.[1]

1. Confirm Home Assistant is up and storage is healthy enough to start add-ons.
2. Confirm Mosquitto is running and set to start on boot.
3. Check Zigbee2MQTT logs for broker resolution, authentication, or coordinator errors.
4. Restart Mosquitto, then Zigbee2MQTT, after fixing the service dependency.
5. Only then test an individual device from the existing device list.

That case does not prove Mosquitto is the most common outage cause. It proves something narrower and more important in a hallway panic: a whole Zigbee network can appear dead when the broker path is broken.

If devices are missing or not reconnecting

Zigbee2MQTT issue reports include cases where devices disappeared or did not reconnect after power loss, and the safe workaround was not a wipe. In the open “All devices gone after power outage” issue, the recovery pattern discussed was to power-cycle a device and enable permit join so it could come back as its existing entry.[2] A later short-power-loss report also describes using permit join and device power-cycling rather than deleting everything first.[3]

Zigbee2MQTT’s own FAQ also cuts against reflexive re-pairing: version upgrades and coordinator firmware updates do not require re-pairing, and a crashed coordinator is normally approached by replugging the adapter and restarting Zigbee2MQTT. The same FAQ notes that crashes can recur on legacy CC2530/CC2531 adapters.[4]

• Safe to try: restart Mosquitto and Zigbee2MQTT after verifying logs; replug the coordinator if the coordinator crashed; power-cycle one affected mains device; enable permit join only long enough to let known devices rejoin.
• Do not do first: delete devices from Zigbee2MQTT, factory-reset end devices, or rebuild the Zigbee network because the app is full of unavailable tiles.
• Stop and inspect: if the coordinator repeatedly crashes, especially with older CC2530/CC2531 hardware, the adapter path is now part of the failure, not merely the outage.

Hubitat: radio reset first, Soft Reset later

Hubitat is where premature database work can turn a recoverable radio problem into a larger job. The key distinction is whether the hub’s radio table has failed to appear, whether devices are listed but not responding, or whether the hub database itself is suspected.

Empty Z-Wave Details page after outage or update

In a February 2025 Hubitat community case on platform 2.4.0.151, the reported symptom was stark: all Z-Wave devices were gone and the Z-Wave Details page was empty after an update and power failure. The recovery that worked was Settings > Shut Down, waiting for shutdown, then unplugging the hub for about 30 seconds to reset the Z-Wave transceiver.[5]

1. Do not remove Z-Wave devices from the app.
2. Use Hubitat’s Settings > Shut Down command.
3. After the hub shuts down, pull power at the hub for about 30 seconds.
4. Power it back up and re-check Z-Wave Details before doing anything else.

A separate March 2025 Hubitat Zigbee outage thread and an older device-recovery discussion point in the same practical direction: check the hub/radio recovery path before treating every endpoint as failed.[6][7]

When Soft Reset belongs in the sequence

Hubitat documents Soft Reset as an advanced recovery path for suspected database corruption, and it preserves the hub’s radio data while resetting the platform database through the procedure described in the documentation.[8] That does not make it the first move after every outage. In the documented radio-table case, the radio power-pull came first and resolved the visible failure.[5]

Use Soft Reset only after the low-risk radio reset path has been checked, you have a reason to suspect database corruption, and you are following Hubitat’s current instructions. If the radio table returns and devices are present, stop escalating.

SmartThings / Aeotec: separate older mesh-heal advice from the January 2026 investigation

SmartThings has two very different kinds of post-outage material: older community mesh-rebuild workarounds, and a January 2026 cluster where all Zigbee and Z-Wave devices showed offline shortly after power was restored while radio activity still appeared to exist. Those are not the same repair.

Older workaround: force a Zigbee mesh heal

Older SmartThings community guidance described powering the hub down with batteries removed for about 20 minutes while keeping mains-powered Zigbee repeaters powered, so the mesh could rebuild when the hub came back. A companion outage case from 2020 involved devices gone after a power outage and fits that older mesh-recovery context.[9]

That workaround is narrow. It is for a mesh-rebuild pattern, especially where repeaters and battery devices may have come back in a bad order. The older guidance also warned that the hub’s roughly 32-device direct-child limit can block rejoins if repeaters are offline. None of that is permission to delete a room full of devices and start pairing them as new.

January 2026: Investigating, not fixed

The January 2026 SmartThings thread is more serious and less satisfying. Users reported all Zigbee and Z-Wave devices offline shortly after a planned outage, while SmartThings engineering engaged on the case. The thread included diagnostic paths such as CLI driver logging and AWA refresh, but those were diagnostics, not a confirmed user-side fix.[10]

• If your case looks like the older mesh-heal pattern: try the hub power-down approach without removing devices.
• If your case matches the January 2026 cluster: preserve evidence, capture logs if instructed, and follow SmartThings support or engineering guidance.
• If devices are still listed: do not assume re-pairing is repair. It may destroy the evidence and identities support needs.

Matter over Home Assistant: treat fabric failures cautiously

Matter failures after a power event are tempting to treat like ordinary device drop-offs. The documented Home Assistant cases do not support that confidence.

A Home Assistant Core issue reported Matter devices becoming unavailable after a power outage or power cycle.[11] A separate Home Assistant add-ons issue for Matter Server 6.1.2 described Matter devices always offline after a power outage, with CASE-session failures including “Network is unreachable,” and reported that restarting Home Assistant, border routers, and devices did not necessarily recover them; that add-ons issue was closed as not planned.[12]

So the safe branch is conservative: restart Home Assistant and the Matter Server path, verify the network and border-router layer, power-cycle affected devices if that is non-destructive, then stop before factory-resetting Matter accessories. A factory reset may create a new commissioning problem while the original fabric/session failure remains unexplained.

When the outage is not the only suspect

If the failure arrived right after an update plus a power event, do not bury that detail. Update-triggered regressions belong in an Update Watch lane, not in the ordinary outage script.

The Hubitat 2.4.2.119 Matter report was from June 2025 and described Matter devices that appeared online but would not respond until rollback to 2.4.1.177 restored control.[13] Zigbee2MQTT also has update-linked reports for 2.2.0 all-devices-offline-after-upgrade and 2.6.0 device-leave drops after a power event.[14][15]

This distinction saves time. A device that came back in the wrong on/off state is a different nuisance, covered in why smart home devices come back on after an outage. A hub that changed behavior immediately after a platform or add-on update needs version notes, logs, and a rollback or vendor-support path if the platform supports it.

The practical stop rule

If devices are still present, preserve their identity and recover the hub service, radio, broker, database, or fabric first. If devices are gone, do not assume re-pairing is the first move until the hub-specific database or radio path has been checked.

A recoverable outage often looks like a dead smart home from the app screen. The difference is whether you let the hub show you what actually failed before you erase the parts it still remembers.

References

1. Please help getting Zigbee2MQTT devices working after power outage — Home Assistant Community
2. All devices gone after power outage — GitHub
3. Devices not reconnecting to network after (short) power loss — GitHub
4. FAQ — Zigbee2MQTT
5. ALL Zwave devices gone after update and power failure — Hubitat Community, Feb 2025
6. HELP: Hubitat Zigbee not working anymore after Power outage — Hubitat Community
7. Device Recovery After Power Outage — Hubitat Community
8. Soft Reset — Hubitat Documentation
9. Half of my devices gone after power outage — SmartThings Community
10. All Zigbee and Z-Wave devices offline shortly after power restored from a planned power outage — SmartThings Community, Jan 2026
11. Matter devices become unavailable after power outage or power cycle — GitHub
12. Matter devices always offline after power outage — GitHub
13. Matter stopped working with after update to v2.4.2.119 — Hubitat Community, June 2025
14. Zigbee2MQTT 2.2.0 all devices offline after upgrade — GitHub
15. Zigbee2MQTT 2.6.0 device leave drops after a power event — GitHub