Smart home devices offline after a power outage? How to fix
Offline in app after power outage; some devices still work manually or in native app.
Last updated

When smart home devices show Offline after a power outage, do not start with a factory reset. Start by proving which layer actually failed. “Offline” can mean a device lost power, your router came back oddly, a hub radio did not recover, or the cloud platform is stale or down. The label is useful as a warning light. It is not a diagnosis.
Before deleting anything, do three cheap checks:
- Press the physical button, switch, or paddle. If the light, plug, lock, or relay works manually, it has power and its basic hardware is alive.
- Compare neighbors that use the same path. If Wi-Fi plugs recovered but Zigbee bulbs and Z-Wave sensors did not, stop blaming every end device one by one and look at the hub or its local radios.
- Compare the native app, the assistant app, voice control, and the platform status page. A device that works in its own app while Google Home, Alexa, Apple Home, or another dashboard says Offline is usually not asking to be reset.
Those checks take less time than a reset and save far more work. A reset destroys pairing, names, room placement, routines, automations, and sometimes bridge-side settings. It should be the end of a narrow branch, not the first thing you try because an app tile turned gray.
Sort the outage into device, network, hub, or platform

After a power cut, several parts of the house reboot at once. The router may take longer than the hub. A hub may boot before internet is available. Battery sensors may be asleep. Wi-Fi devices may reconnect directly to the router while Zigbee or Z-Wave devices wait on a hub mesh. Cloud dashboards may be behind reality.
That is why the first goal is not “make every tile green.” The first goal is to avoid breaking the pieces that already recovered.
| What you see | Most likely layer to inspect first | Least destructive next move |
|---|---|---|
| Device does not respond manually and has no LED or sign of power | Device or outlet | Check the breaker, outlet, plug, bulb seating, battery, or device power |
| Device works manually but is Offline in the app | Network, hub, or platform status | Do not factory-reset yet; compare native app, assistant app, and nearby devices |
| Wi-Fi devices recover, but Zigbee or Z-Wave devices stay offline as a group | Hub or local mesh radio | Inspect hub status and reboot only when it is safe |
| Device works in its native app or by voice but one dashboard says Offline | Platform or cloud sync | Check status pages and wait instead of resetting local gear |
| Only one device stays offline after router and hub are stable | That device’s connection | Power-cycle it, then delete and re-add if needed; factory reset last |
The manual test: prove the device is not dead
Walk to one Offline device and use it like a normal device. Flip the wall switch. Press the smart plug button. Tap the lock keypad. Open and close the sensor’s contact if it has a visible indicator. If the device responds locally, the app’s Offline label is already narrowed: power and the basic load-control hardware survived.
That does not mean the device is fully healthy. It may still have lost Wi-Fi credentials, missed the hub during boot, or failed to report status after the outage. But a manually working device is not the same problem as a dead device. Treating both with the same factory reset is how a short outage turns into an evening of re-pairing.
If the device does not respond manually, stay local. Check whether the outlet is live, the breaker is tripped, the bulb is seated, the switch is actually supplying power, or the battery device needs attention. App troubleshooting can wait until the device behaves like a device again.
If one platform says Offline but the device still works, wait before you reset
The cleanest warning against reset-first troubleshooting came on January 22, 2026, when Google Home users saw smart lights, switches, plugs, and other devices show as Offline during a Google smart-home outage. PCMag reported that affected devices could still work in their native apps and, in some cases, still respond to voice commands even while the Google Home app showed them offline.[1]
That detail matters more than the outage headline. If a bulb responds in the manufacturer’s app and a plug responds by voice, the bulb and plug are not asking to be factory-reset. The broken layer is above them. Deleting the device from Google Home, resetting it with a paperclip or switch pattern, and re-adding it to the manufacturer app would attack the one layer that had already proven itself alive.
Use that case as the model for your own outage check:
- If the native app works but the assistant app says Offline, check the assistant platform’s status page and recent reports before touching device settings.
- If voice works but the dashboard is stale, give the dashboard time to catch up instead of rebuilding the device.
- If multiple brands fail inside one app at the same time, suspect that app, its cloud link, or the account integration before suspecting every device.
- If the same device is dead in its native app, assistant app, and manual control, then move back down to power and device-level troubleshooting.
The do-not rule here is simple: do not reset during a suspected platform outage. A cloud outage can make healthy devices look broken, and a local reset will not repair the cloud.
If Wi-Fi came back but Zigbee or Z-Wave stayed dark, look at the hub

A different pattern points lower than the cloud but higher than individual devices: Wi-Fi devices recover, while Zigbee and Z-Wave devices remain offline as a group. In a SmartThings Community case after a planned power outage, the owner reported that Wi-Fi devices came back, but all Zigbee and Z-Wave devices went offline shortly after power was restored. The thread became an escalated, unresolved case, so it should not be treated as a universal fix recipe. It is useful because the pattern is so clear.[2]
Wi-Fi plugs, bulbs, and cameras can reconnect through the router without a Zigbee or Z-Wave radio. Zigbee and Z-Wave devices depend on the hub’s local radios and mesh. When a whole local-radio family fails together, it is usually wasteful to reset each sensor and bulb one by one. The hub, its firmware state, its radio, or its connection to the platform deserves the first look.
Start with the hub’s LED or app status. Samsung’s own troubleshooting order begins with power and LED checks, then moves through device power-cycling, native-app checks, range checks, delete-and-re-add, and only later factory reset. Samsung also warns not to unplug a hub showing a flashing or solid magenta LED, because that indicates a firmware update is in progress.[3]
That warning is not decorative. Pulling power from a hub while it is updating is one of the few “fixes” that can create a worse problem than the outage left behind.
If the hub is not updating and the app shows it online but its Zigbee or Z-Wave devices remain grouped offline, a hub reboot is a reasonable branch. If the hub itself is offline, bring the network back first. For a fuller restore sequence after storms or longer outages, use the separate restore-order guide rather than improvising a reset spree.
The bridge trap: reachable does not always mean available
There is another post-outage failure that looks absurd until you have met it once: devices are reachable on the network but unavailable through a bridge. In a solved Home Assistant Community thread, HomeKit-connected devices showed unavailable after a power outage even though the devices could be reached by ping. The fix was not re-pairing every device; the discussion centered on multicast DNS/Bonjour behavior and firewall or mDNS settings after the network restart.[4]
This is the “looks alive, still unavailable” trap. Some bridges and integrations rely on local discovery traffic, not just ordinary internet access. A router or firewall can come back in a way that allows basic reachability while blocking the discovery chatter that HomeKit, Home Assistant, or another controller expects.
The practical test is modest: if a device or bridge can be reached locally, and many bridged devices fail at once after a router restart, do not assume every accessory forgot its home. Check the bridge, VLAN, firewall, multicast, or Bonjour/mDNS settings before re-pairing. This is especially relevant in homes with separate IoT networks, mesh routers, managed switches, or security appliances.
Pick the least destructive fix that matches the evidence

Once you have sorted the layer, the action usually becomes less dramatic.
| Evidence | What to do | What not to do yet |
|---|---|---|
| Native app or voice works, but one assistant app says Offline | Check platform status and wait | Do not reset the device or delete it from every ecosystem |
| Hub LED indicates firmware update | Leave the hub powered and let the update finish | Do not unplug the hub |
| Wi-Fi devices are fine; Zigbee/Z-Wave group is offline | Inspect hub status; reboot hub only if it is safe and not updating | Do not factory-reset each mesh device |
| One powered device works manually but not in apps | Power-cycle that device; Samsung suggests unplugging supported devices for about 2 minutes in its troubleshooting flow | Do not factory-reset before trying a normal power cycle |
| One device remains unreachable after power, network, hub, and platform checks | Delete and re-add it if the platform’s normal troubleshooting says to | Do not factory-reset unless re-add fails or the device requires it |
| Device will not work manually and has no sign of power | Fix power first: breaker, outlet, switch, battery, adapter, or bulb seating | Do not spend time in cloud dashboards until the device has power |
Samsung’s support flow is a useful guardrail here because it keeps reset near the end: check power and indicators, power-cycle the device, check the manufacturer’s app, check range, then delete and re-add before treating factory reset as the last resort.[3]
For a single Wi-Fi plug that works manually but will not reconnect anywhere, a power cycle may be enough. For a battery sensor, waking it or moving it temporarily closer to the hub may tell you more than resetting it. For a group of mesh devices, the hub branch is usually cleaner. For a platform-wide outage, the fix is patience, not violence with a reset pin.
When delete-and-re-add is reasonable
Deleting and re-adding is not the same as factory-resetting, although some ecosystems blur the line. It is reasonable after you have a narrow failure: one device, not a whole protocol family; no platform outage; the hub and router are stable; the native app or hub can no longer control it; and a normal power cycle did not bring it back.
If the device has important automations, note its exact name, room, and routines before removing it. Some systems reconnect automations when the same device returns; others treat the re-added device as a stranger. That is another reason not to perform this step just because five tiles went gray at once.
Factory reset belongs after that. Use it when the device cannot be recovered through power, app-level re-add, hub troubleshooting, or manufacturer instructions — or when the manufacturer’s own process explicitly requires a reset to rejoin. A factory reset on a manually working device should feel like an admission that the narrower fixes failed, not like a shortcut.
If everything came back but states are wrong
One branch is easy to misclassify: the device is online again, but it turned on, stayed off, changed brightness, or came back in the wrong mode after power returned. That is no longer an Offline problem. It is power-on behavior, and the fix lives in device settings such as restore-last-state or default-on behavior. Use the separate guide to smart devices after a power outage for that branch.
Likewise, if you want to understand why different protocols fail differently after power loss, the deeper protocol mechanics are covered in the power-outage protocol guide. This page is only for the decision you have to make before you wipe something.
The short decision tree
- Test the device manually. If it does not work, fix power or the device itself first.
- If it works manually, compare the native app, assistant app, voice control, and status pages. If only one platform is wrong, wait or relink only that platform after the outage clears.
- Compare devices by protocol. If Wi-Fi recovered but Zigbee or Z-Wave failed as a group, inspect the hub and its radios before touching end devices.
- Check whether the hub is updating. If it shows an update indicator, leave it alone.
- If one device alone remains offline, power-cycle that device and give it a normal chance to rejoin.
- If it still will not rejoin, delete and re-add it using the normal app flow.
- Factory-reset only after the narrower branch fails or the manufacturer’s instructions require it.
For next time, outage planning belongs in a different bucket: battery backups, router and hub placement, and what still works when the internet is down. If this outage exposed bigger gaps, park the cleanup work in a smart-home hurricane preparedness checklist after the house is stable. Right now, the win is simpler: classify the Offline label before you erase a device that was never broken.
References
- Lights Out for Google Smart Home Devices as Bulbs, Switches, More Suffer Outage - PCMag - https://www.pcmag.com/news/lights-out-for-google-smart-home-devices-as-bulbs-switches-more-outage
- All Zigbee and Z-Wave devices offline shortly after power restored from a planned power outage - SmartThings Community - https://community.smartthings.com/t/all-zigbee-and-z-wave-devices-offline-shortly-after-power-restored-from-a-planned-power-outage/307207
- Samsung SmartThings devices are offline - Samsung - https://www.samsung.com/us/support/troubleshoot/TSG10007366/
- [Solved] All devices show unavailable via HomeKit after power outage - Home Assistant Community - https://community.home-assistant.io/t/solved-all-devices-show-unavailable-via-homekit-after-power-outage/431254
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.
