Why Do Smart Home Devices Come Back On After an Outage?

Power comes back, the house wakes up, and one device immediately makes itself the problem. A bedroom bulb that was off before the outage returns at full white. A smart plug that was supposed to keep a modem, camera, or appliance reachable stays off. The app may even show the device online, which makes the failure more irritating: it reconnected, but it did not come back in the state you expected.

That usually does not mean the bulb or plug is broken. It means you are looking at a different problem than simple reconnection.

After an outage, two things can go wrong. A device can be unavailable because Wi-Fi, Thread, Zigbee, the hub, DNS, cloud services, or integrations have not recovered in the right order. If that is the problem, start with the smart home reconnect-after-outage recovery order. This guide is about the other failure: the device has power, may be online, and still chooses the wrong on/off, brightness, or output state.

The useful correction is simple, but it is not the one people usually reach for. Power-on behavior after an outage is primarily a device and firmware behavior. A hub can sometimes repair the state later, but it cannot make a bulb stay dark during the seconds before the bulb’s own firmware decides what to do with restored power.

The setting you are looking for has boring names

The cleanest example is Shelly’s documented Power on Default setting for the Shelly Plug S. Shelly describes three choices: On, Off, and Restore-last. That is the important part: the behavior is exposed as a device control, not as a vague promise that the smart home platform will remember what happened later.[1]

Those three choices lead to different real-world failures and different good uses.

For a bedroom lamp, On is often the 2 a.m. punishment setting. For a plug feeding network gear, Off can be worse, because the device you hoped would help you recover the network has just removed power from part of the network. Restore last sounds like the sane default, but it depends on how the device records state, how long the outage lasts, and what the manufacturer actually implemented.

This is why the location of the setting matters. A device-level setting runs as the plug or bulb boots. A hub automation runs only after the hub, network, integration, and device are far enough awake to receive commands. In a clean outage, that delay might be harmless. In an ugly one, startup order is exactly where neat automations go to misbehave.

Why bulbs often come back on

Many users first notice this with bulbs because the failure is visible. Community reports in a Wyze forum thread describe Wyze bulbs and several Wi-Fi bulbs turning on and staying on after a power failure. In the same discussion, users point out that Philips Hue exposes a per-bulb power-on behavior option, including a full-brightness default, last state, or a custom setting.[2]

There is a practical reason some bulbs are designed to turn on when power is restored: a smart bulb also has to behave enough like a normal bulb that someone can toggle a wall switch and get light. If the firmware always stayed off after power returned, a person could flip the physical switch and think the bulb had failed. That switch-compatibility logic may be defensible in a hallway. It is much less charming over a bed.

The Hue example is useful because it separates capability from guarantee. Community users describe Hue’s power-on behavior control as a workaround for bulbs returning at full brightness. One user in that thread also reported an edge case: the chosen last-state behavior worked for short flickers, but after an outage of about six hours, the bulb did not respect the last state in the same way.[2]

That report should not be treated as proof that every Hue bulb fails after long outages. It should be treated as a warning against reading “last state” as “last state under every outage length, firmware version, and device generation.” If a room matters, test the exact bulb, with its current firmware, in the conditions you care about.

Why plugs can fail the opposite way

Smart plugs create a quieter failure. The room does not light up. Instead, something that was supposed to be powered is not powered, and the app may not help if the plug is upstream of the equipment needed to reach it.

Home Assistant community reports describe many Zigbee and Matter plugs remaining off after power loss, while Kasa and other Wi-Fi plugs are reported more often as restoring last state. The same discussion includes the practical consequence: a plug used on a router or network device for remote power-cycling can break the recovery plan if it stays off after the outage.[3]

That does not make “Zigbee plugs stay off” or “Wi-Fi plugs restore correctly” a safe rule. The material supports a pattern reported by users, not a protocol law. A Zigbee, Matter, or Wi-Fi logo tells you how the device communicates. It does not, by itself, tell you what the relay will do the instant power returns.

For plugs, the correct default depends heavily on the load. A plug controlling a fan, heater, coffee maker, pump, or unknown appliance may be safer staying off. A plug powering network equipment, a monitoring device, or something expected to resume service may need to restore last state or turn on. The same setting that saves one setup can strand another.

If you use plugs for energy monitoring or standby-power control, the outage state can also distort assumptions about what is being measured or controlled. That matters in setups like a standby-power smart plug recipe, where the plug is not just a switch but part of the logic for observing or reducing load.

The protocol label is the wrong shortcut

It is tempting to make a buying rule out of the examples: avoid this protocol, buy that protocol, use this brand. The evidence does not support that kind of shortcut. The useful distinction is not Wi-Fi versus Zigbee versus Matter. It is whether the exact model and firmware expose a configurable power-on mode, and whether that behavior is documented by the manufacturer or only reported by users.

Brand names are not enough either. A manufacturer can ship different behavior across generations, firmware builds, regions, and app versions. Even when a brand has a sensible setting on one product, that does not prove the same option exists on another bulb, strip, plug, relay, or outlet.

Fix 1: use the device’s own power-on behavior setting

Start in the vendor app or the device page exposed through your smart home platform. Look for plain settings with names like Power on behavior, Power-on default, Initial state, Restore state, or After power loss. For bulbs, check both the bulb settings and room/light settings. For plugs and relays, check the device settings, not just automation rules.

• For bedrooms and nurseries, prefer Off or Restore last over full-on, then test a real power cut.
• For network gear, hubs, cameras, and monitoring equipment, confirm the plug will not remain off unless that is intentional.
• For appliances, fans, pumps, heaters, and anything with moving parts or heat, do not choose On just because it is convenient.
• For bulbs with color temperature or dimming, verify whether “restore” includes brightness and color, not only on/off state.

Then test it without being gentle. Set the device to the state you want, cut power at the switch, breaker, or power strip as appropriate, wait long enough to be meaningful, and restore power. Watch the device before the hub has time to tidy anything up. Those first few seconds tell you what the firmware really does.

If the setting exists and behaves correctly, prefer it. It is not glamorous, but it runs at the moment that matters.

Fix 2: use a startup automation only after the system has actually started

If the device has no usable power-on setting, the fallback is a hub automation that reapplies the desired state after recovery. The delay is not optional decoration. After an outage, the router, access points, hub, coordinator, integrations, and devices do not all become reliable at the same instant.

A decent startup repair automation usually does four things: waits for the hub to boot, waits again for integrations and devices to report, checks whether the outage-recovery condition is still relevant, and only then sends state commands. Without that pause, the automation can fire into a half-awake system and leave the wrong device untouched.

Home Assistant users have another specific trap: community discussion notes that dynamic scene snapshots are cleared on restart. That means “just restore the previous scene” can fail after a real outage if the hub restarted and the snapshot no longer exists.[3]

A startup automation should therefore be based on states you can reconstruct, not on temporary memory you assume survived. For a few critical devices, hard-code the desired safe state. For others, use helpers, saved preferences, or simple rules such as “turn off bedroom lights after hub startup if they are on and it is overnight.” The exact automation depends on the platform, but the principle is the same: wait until commands can land, then repair only what needs repair.

If you want the system to know when the outage happened instead of guessing at startup, pair this with an outage alert automation using UPS or NUT detection. If the bigger problem is that your modem, router, hub, or coordinator goes down too early, the better investment may be power-outage prevention and network hardening rather than more clever post-boot cleanup.

What to check before replacing or buying

Before replacing a bulb or plug, check the device you already own. Firmware updates sometimes add or change settings, and the option may be buried under device behavior rather than automation. If the setting is absent, search by exact model number, not just product family.

• Exact model number and hardware generation.
• Current firmware version mentioned in the report or documentation.
• Whether the power-on behavior is manufacturer-documented or only community-reported.
• Whether choices include On, Off, Restore last, and for bulbs, brightness/color restore or custom power-on behavior.
• Whether the setting is stored on the device or merely recreated by a hub automation.
• Whether anyone has tested more than a quick flicker if long outages matter in your area.

For rooms where outage behavior is only annoying, community reports may be enough to guide a purchase. For bedrooms, accessibility-critical lights, network recovery plugs, refrigerators, pumps, or anything safety-adjacent, look for manufacturer documentation or do your own bench test before the device earns a permanent job.

There is no safe brand-level shortcut here. Shelly’s documented control is strong evidence for that specific device behavior. The Wyze and Hue reports are useful because they show real bulb pain and available workarounds, while also showing why outage length and implementation details matter. The Home Assistant plug reports are useful because they expose a failure that protocol labels alone would hide. None of those examples lets a buyer infer power-restore behavior from Matter, Zigbee, Wi-Fi, or a familiar logo.

For the next purchase, the rule is plain: confirm that the exact model and firmware expose a configurable power-on mode before you put it anywhere the wrong state will cost you sleep, access, monitoring, or safety. Treat device firmware as the first line of recovery, and hub automation as the cleanup crew that arrives later.

References

1. Shelly Plug S Device Smart Control — Shelly
2. After power outage, smart bulbs turn on and stay on — Wyze Forum
3. Restore state of all entities after power lost — Home Assistant Community