Why a Home Automation Stops Working After a Restart

Returning power does not restore every intended behavior

One recorded Reddit discussion describes a smart home remaining difficult to use after power returned while the internet was unavailable. A separate discussion asks what automations should run during power outages and how lights should return. These are related but different concerns: command-path availability and the physical state chosen after an interruption.

This guide addresses recovery after a device or controller restarts. Before testing, decide which lights should restore their prior state, which should remain off, and which interrupted commands should expire. A blanket replay of old commands is not a recovery policy.

Source: Not so smart smart home · What are some of your power outages automation?

Check the device’s own power-on setting

For the bulb models listed in Tapo’s US instructions, default-state options include the bulb’s last on-state or a custom brightness when it turns on. Its power-restoration options distinguish turning on from restoring the previous on/off state. Verify the actual bulb’s menu and instructions rather than assuming every smart light behaves alike.

A controller routine cannot reliably correct a lamp that has not reconnected yet. Test the device’s immediate behavior when power returns and then its behavior after communications recover. Keep hallway usability and bedroom comfort in the acceptance criteria; do not assume one setting is right throughout the house.

Source: Tapo US: Default State for Smart Bulbs

Represent a required future time explicitly

Home Assistant specifically states that a pending trigger wait configured with “for” resets on restart or automation reload. This is a documented limitation of that mechanism, not a claim that every timer in every platform loses its state. Its documentation suggests using an input_datetime helper when an explicit future time is needed.

For an illustrative porch-light shutoff, retain the intended deadline using a supported persistent design. On recovery, compare the current time and current conditions with that deadline before acting. If the deadline passed while the controller was offline, an ordinary future trigger alone may not settle what should happen now. Agree whether to act, discard the command or ask for review.

Source: Home Assistant automation triggers

Protect configuration separately from physical state

Home Assistant’s OS filesystem guidance lists unexpected power loss or failing storage as possible reasons an OS filesystem check fails. It also explains that the data partition is separate from the affected OS partitions. An outage therefore does not automatically mean the user configuration was erased.

Keep a supported backup in a location that survives loss of the controller’s storage, and verify access and the restoration procedure. Home Assistant provides a backup integration. A restored configuration still needs current device checks: restoring rules does not prove that lights, sensors and pending actions match their pre-outage state.

Source: Home Assistant OS: Filesystem Check Error · Home Assistant: Backup Integration

Match backup power to the required control path

A suitably selected uninterruptible power supply can support the controller and required network components through a limited interruption. Size and verify the supported equipment and runtime for that arrangement; a powered router is insufficient if the controller or network switch loses power.

Home Assistant’s Network UPS Tools integration communicates with a NUT server; it does not connect directly to a UPS and does not by itself promise automatic graceful shutdown. If orderly shutdown before battery exhaustion is part of the design, identify the supported power-monitoring and shutdown arrangement and test it separately from a short outage.

Source: Home Assistant: Network UPS Tools Integration

Verify staggered reconnection and current state

Use a planned supported restart test with ordinary household controls available. Test a pending wait, a device already in the target condition and a device that reconnects after the controller. A later availability event or bounded recheck may be needed; do not repeatedly send old commands without confirming the result.

Record which actions expire, which reconcile against current conditions and which require a person’s review. Retain the backup location and authorized recovery contact securely. The completed test should demonstrate the actual household outcome, not merely that the controller app opens again.

Put it into practice

A decision table to keep handy