I have an automation triggered by a sensor’s state change. The issue is it fires every time Home Assistant restarts or the configuration reloads, even when the sensor’s value hasn’t truly changed.
I want to avoid these unwanted triggers caused by startup or reload.
Here’s what I’ve tried and my thoughts:
Adding for: in the trigger delays the action until the state remains stable for that duration, but it doesn’t prevent triggering if the state changes on startup or reload. The automation triggers once the new state has been stable for the specified time.
Using not_from: and not_to: to exclude certain states isn’t a good fit because I need the automation to trigger even if the state becomes unavailable legitimately. So excluding states could block valid triggers.
Disabling the automation by default and enabling it via another automation after startup avoids the issue on restart, but it doesn’t solve triggers caused by config reloads when the automation stays enabled and still fires.
Adding delays or using wait_for_trigger to filter out startup events didn’t help.
Is there a reliable method to stop automations from firing during Home Assistant startup or configuration reload — when entity states are just restored or haven’t actually changed?
Unfortunately, it doesn’t cover the case when I reload automations or config from the UI or Developer Tools. In that case, the uptime sensor doesn’t change, and the automation still runs due to restored or unchanged states.
The first condition only works during full HA startup because homeassistant isn’t set to starting on config reload. The second doesn’t help if the sensor temporarily goes unavailable and then restores its previous state — it still counts as a state change. Still looking for a more reliable solution.
condition:
- condition: template
value_template: >
{% set from = trigger.from_state.state %}
{% set to = trigger.to_state.state %}
{{ from not in ['unavailable', 'unknown', None] and
to not in ['unavailable', 'unknown', None] and
from != to }}
The problem is that HA will not recognise that it’s restoring its “previous” state, because the actual previous state in the state engine is unavailable, while you want the state before that.
The fact that you still want the automation to trigger in cases where it genuinely goes unavailable complicates matters a bit, because you need a way to distinguish between a restart/reload and an actual issue.
This is untested, but might work. Set up 2 triggers in your automation:
First one with not_from: and not_to: unavailable/unknown.
Second one with to: unavailable for 30s (or some value more than it takes for states to restore after a restart).
That should cover your requirements and avoid unnecessary triggers with restarts, while also triggering if the entity is actually unavailable (after a slight delay).
But with this config, I lose the trigger when the sensor changes from unavailable to a real value.
To fix that, I tried adding a third trigger:
- platform: state
entity_id: sensor.example
from: unavailable
for: 30s
In reality, the third trigger still fire after 30s during config reload. The second trigger works correctly — it doesn’t fire on restarts because the sensor is unavailable for less than 30 seconds, so the condition is never met.
No, it is not effectively the same. The single trigger above (and the third trigger you posted) will lead to the issues you reported under those scenarios.
Can you try my suggestion of the 2 triggers and let me know if it works?
trigger:
- platform: state
entity_id: sensor.example
not_from:
- unavailable
- unknown
not_to:
- unavailable
- unknown
- platform: state
entity_id: sensor.example
to: unavailable
for: 30s
With this setup, the automation doesn’t fire on config reload, which is good — but I lose the trigger when the sensor changes from unavailable to a valid state.
It’s going to be next to impossible to achieve that, because using something like your third trigger will lead to false alerts.
The good news is that you will still get a trigger when your entity changes to unavailable for 30s. This is what you originally listed as a requirement, and my proposal meets those criteria:
Thanks to everyone who helped — I truly appreciate the insights and suggestions.
Special thanks to ShadowFist for taking the time to dive into the details and share solutions.
I’ve already implemented the following:
alias: HA Ready Status on Template Reload
description: Sets ha_ready false on template reload and resets it to true after 5 seconds
triggers:
- trigger: event
event_type: event_template_reloaded
- trigger: homeassistant
event: start
actions:
- target:
entity_id: input_boolean.ha_ready
action: input_boolean.turn_off
data: {}
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- target:
entity_id: input_boolean.ha_ready
action: input_boolean.turn_on
data: {}
mode: restart
This was the only working solution I found to prevent false triggers during reboots or config reloads, without losing the ability to track unavailable and unknown states.
Took me more than 10 hours to get this right — honestly frustrating that Home Assistant doesn’t handle this natively.
Upd… Additional requirement:delay: in the “ha_ready” automation must be greate then for: in the main automation trigger.
Rather than use an automation and an Input Boolean, you may wish to consider implementing it as a single, self-contained entity: a Trigger-based Template Binary Sensor.
In other words, how would you configure the State Trigger to not trigger for a particular state-change if, and only if, that state-change occurs at startup?
