A router restart is a brief disruption that can affect a lot of things at once. Wi-Fi clients may reconnect, clients may revalidate or renew DHCP leases, and integrations may temporarily lose connectivity. Home Assistant entities can pass through unknown or unavailable before settling. If an automation treats every state that follows as a real-world event, that recovery can look like someone leaving home, a door sensor changing, or a device coming back online.
This guide is for a Home Assistant instance and network you administer. It covers ways to reduce false actions after a planned or accidental network interruption. It does not make an automation fail-safe for every outage. You still need to test alarms, locks, heaters, and other consequential actions under your own conditions.
Home Assistant’s trigger reference documents how unknown and unavailable states behave. After a network interruption, inspect the transition itself, not just the state the entity eventually settles into. The relevant reference is Unavailable and unknown state behavior in triggers.
Recovery transitions and real events
An automation has three parts. A trigger starts it, conditions decide whether it can continue, and actions do the work. Home Assistant documents this sequence explicitly, so start with automation triggers and conditions when an action occurs after a restart.
Suppose a presence group normally changes from home to not_home when the last person leaves. During a router reboot, it might take this path instead:
home → unavailable → not_home → homeThose middle values describe incomplete information. They do not necessarily mean someone walked out. A trigger that only says “run when the group is not_home” may be too broad for an action such as arming an alarm. Without more context, it cannot tell a direct departure from a recovery path.
Before editing YAML, open the automation trace or logbook. Write down the exact old state, new state, time, trigger, and action, along with whether the router, Home Assistant host, access point, or a particular integration restarted. One observation will not identify the cause. It does, however, keep you from changing the configuration based on a sequence you only guessed at.
Explicit state transitions
For a state-based automation, a from value is a simple guard that can help. If the event you care about is a group moving directly from home to not_home, specify that transition instead of triggering every time the group reaches not_home.
triggers:
- trigger: state
entity_id: group.household
from: "home"
to: "not_home"The entity name here is a placeholder. Check the entity in your own instance before replacing it. The example deliberately leaves out an action: while you are testing, a notification is safer than an irreversible action.
The from and to fields change when the trigger fires. Without that restriction, a state trigger can fire when the new state matches even if the previous state was unknown or unavailable. Home Assistant’s trigger documentation gives state-trigger examples and explains how a trigger starts the automation before conditions are checked. See the state trigger reference.
This pattern does not belong in every automation. A light that should turn on whenever a motion sensor reports on may not need a from state. An occupancy or security automation often does: a recovery transition means something different from the normal event.
Short stability checks for important actions
A direct transition guard helps, but a device can still report a temporary value after the network comes back. For an important action, consider checking that the relevant state stays true for a short period you have chosen. Home Assistant supports for with state triggers and conditions. A state trigger’s for waits before firing; a state condition’s for immediately checks how long the state has held and does not wait. Pending trigger timers reset when Home Assistant restarts or automations are reloaded. Choose the duration based on how the entity normally behaves, rather than picking an arbitrary magic number. Trigger timing explains the trade-off.
For example, a presence group that briefly reports not_home after the router returns should not arm an alarm just because it held that state for a few seconds. A ten-minute delay may suit one household and be unacceptable in another. Someone could actually leave during that delay. Once it ends, the automation should still check the current state before acting.
A cautious testing order is:
- Change the action to a persistent notification or log entry.
- Restart only the router or access point at a time when a false action has no consequence.
- Inspect the trace to confirm the actual state path.
- Repeat with the normal departure case.
- Restore the real action only when you understand both paths.
Avoid testing by repeatedly power-cycling locks, alarms, or heating equipment. The test should give you evidence about the automation without creating a new safety problem.
Unavailable states and missing evidence
A condition that simply rejects unknown and unavailable can seem like an easy answer. It may be sensible, but it tells you only the entity’s state when the condition runs. It cannot tell you whether recovery, a genuine departure, or an unrelated integration reload triggered the automation.
If you need a template, keep it small and readable. Home Assistant’s automation templating documentation covers the template functions available in automations. For example, a condition can reject a missing state:
conditions:
- condition: template
value_template: >-
{{ states('group.household') not in ['unknown', 'unavailable'] }}This guard does not prove that everyone has left. Combine it with the direct from/to transition if that matches the policy you want. If the automation relies on Wi-Fi presence alone, consider whether an action with serious consequences warrants a second, independent presence source or manual confirmation. The household needs to make that decision; there is no universally correct YAML snippet for it.
Concurrency and restart behavior
After an outage, several entities can recover close together. The same automation may trigger repeatedly while it is still waiting, and its mode determines what happens next. Home Assistant documents the single, restart, queued, and parallel modes and how each handles a new trigger. Review automation modes before adding delays or retries.
Several queued notifications may just be annoying. Repeated runs of an action that changes security or comfort can be confusing. Choose a mode based on what should happen if a second valid event arrives while the first run is active. Silencing a warning is not enough reason to choose it.
Check the integration that supplies the entity, too. Router and cloud integrations may recover at different speeds. A static address, DHCP reservation, or longer integration timeout might fix a connection problem, but do not make those changes simply to suppress an automation trace. Before changing addressing, ensure the address cannot conflict with DHCP allocations and keep a local recovery method available; incorrect settings can make the device unreachable. First, work out whether the entity is actually unreachable, its address has changed, or it is reporting a temporary state while the integration reconnects.
A short record of the recovery path
Record the date, the component that restarted, the state sequence, and the automation result. If the issue comes back, that record will tell you more than a screenshot of the final dashboard state. It also helps distinguish a router restart from a Home Assistant restart or a single unreliable device.
A local network inventory or monitoring tool such as DeviceShelf can provide another observation source for a network you administer. It may help you match a host’s return to the automation timeline. It cannot explain why Home Assistant chose a state or replace Home Assistant’s own trace. Treat it as supporting evidence, not a verdict.
You do not need to eliminate every unavailable state. The automation should act on the transition that represents the real event, wait only when there is a reason to, and leave an auditable trace when the network recovers.