That is my understanding, an automation that has a trigger where an entity has to be in a certain state for a period of time before the automation is executed, is not running, so I can’t see why it should affect it. Every entity has a last_changed attribute which makes it easy to calculate how long an entity has been in the desired state, it’s only a core restart that resets all of that.
EDIT: If it does indeed affect automations with triggers that require a certain state for a period of time, it is not something that has ever caused me any issues, and I edit automations constantly…
@ServiceXp , there are some people out there, who will try to remind your mistakes all the time, you can safely ignore these people. That is my learning with my last 1 year experience. Focus on the results.
Do not worry, either you are a veteran or a new joiner, it is always ok to make a mistake, as long as it is not intentional. Enjoy your solution thanks to helpful community members.
The “for:” option in the trigger is effectively the same as adding a “delay:” or “wait_for_trigger:”, etc. and it suffers from the same limitations as all of the other timer functions in HA - they are all impacted by an automations reload or restart of HA.
The way the “for:” option works is that the automation listens for the state to change to the desired state and then it starts the wait for the “for:” time. So even tho the automation hasn’t technically triggered yet there is still stuff going on in the background waiting for the time to expire after the state change before it runs the actions. And that waiting period will be cancelled on the above mentioned restart/reload events.
It would make sense if the “for:” in the trigger worked the way you thought (so did I for a long time) but unfortunately it doesn’t.
There are literally no reliable timed functions in HA that aren’t affected by a reload of automations, etc.
EDIT:
I actually tried to make a change to the documentation to add a warning to users of the limitations of HA timer functions but the powers-that-be didn’t like that it was too informational (I guess…?, ) and when I couldn’t come up with a more succinct way to get the point across it has been languishing in PR purgatory ever since.
So they can list automations dynamically by area and device, so they know what devices and things are involved, but they can’t check all the relevant trigger conditions on a reload. That is stupid, it’s surely less overhead to check the state’s last changed time and then calculate what time it would be when the requirement would be met, and then check then - instead of having an internal timer.
Ah yes, those people who clearly point out why this simple problem took dozens of posts to resolve. Their advice should be ignored because it’s far better to talk circles around the problem and drag out its resolution.
Very true. What’s needed is the concept of an incremental reload where only new/modified automations are reloaded (by default); unmodified automations are left undisturbed. FWIW, this already exists in other products, including the 20 year-old automation software I use in addition to Home Assistant.
I feel I mentioned this in a Feature Request but don’t recall which one (probably in the one for reducing the need for complete restarts … and a great deal of that has been implemented).
Anyway, the current state of affairs means ought to employ certain design patterns in one’s automations to mitigate the “reset” behavior of Reload Automations. However, that’s out of scope for this thread.
Sorry, i missed to add /s to end of my previous post, forgive me. That is a total miss from my end and it had caused to consume your valuable and precious time, so you had to remind me about /s. You should somehow set a community to find the most proper way to punish people.
Sorry again. Please do not bother to answer any of my comments, save your valuable time and energy.
Learning a little more this afternoon. Taking @tom_l suggestion on using a script (well I think that is what you meant ),
I know it’s stupid simple for you guys but quite the accomplishment for me and my kind…
Automation
2 Time Helpers (I think that’s what they are called)
A Group
A Script
So now, all the ‘heavy’ lifting is done by the script in one place. I should probably check for a null or incorrect input value, but one step at a time.
For future reference, moving an automation’s actions into a separate script (and then having the automation call the script) is usually done for a specific reason: something else also needs to execute the same actions. Calling a centralized script, from two or more other places, avoids code duplication and simplifies maintenance.
However, if the actions are used exclusively by one automation, there’s little benefit to moving them out of the automation and into a separate script. In fact, it makes maintenance slightly less convenient because the automation’s trigger and actions are no longer together.
) and when I couldn’t come up with a more succinct way to get the point across it has been languishing in PR purgatory ever since. 
),
