Yea I’m skeptical this will happen as well for similar reasons. I personally think it’s more likely we’ll get a feature where pressing save only reloads the automation you saved, not all. Since HA already knows how to do targeted reloads from YAML, it just needs a more precise targeting option.
And that would probably massively reduce the need for this feature since it would likely be limited to only occurring on restart. And of course saving an automation would stop any running instances of that automation but I don’t think people would be as surprised by that.
Although I do think that if this FR is not taken up the UI should probably show a warning if for or wait options exceed a threshold. The current behavior is definitely an unpleasant surprise for many folks judging by all the posts on the forum.
I didn’t suggest a UI change but I did actually try to make a documentation change a while back with a warning that the timer implementation was unreliable for long (>5 minute?) time values. If that one was accepted I was going to do the same for the rest of the time components.
It languished for a long time then was auto closed.
The concern was that it gave the impression that people shouldn’t use timers/delays/etc for long wait times and that they were unreliable. Well, yeah. They are unreliable. Which was the point.
I doubt a UI warning would fare much better for the same reason.
Yea its kind of a pickle. I think the problem is that when seeing a PR/issue like that people would rather fix the underlying issue then spend time adding a warning like that. Which is a great sentiment but its been a very long time at this point and in the meantime many users are getting into bad situations with long delays not realizing the pitfalls.
My personal feeling is that one of the following 3 should happen:
Wait steps and for options survive restarts and reloads (this WTH)
Saving one automation does not reload them all (this WTH)
A warning shows up for wait and for configurations that could take over 5 minutes (a stopgap if neither of the above happens)
#2 might ideally be combined with a documentation note that mentions restarts/updates kill running automations. But I think if that change was made its no longer egregious enough to require an in-your-face UI warning.
I wish that was the case but unfortunately that sentiment wasn’t conveyed in the PR discussion.
It only centered around the thought that we didn’t want to give users the idea that they shouldn’t use them because they were unreliable.
I was asked to tone down the warning to make it less…“warning-y” I guess.
But I couldn’t figure out how to do that and keep the actual concern conveyed by the warning intact. I actually asked for a suggestion to give me an idea what would be acceptable and that’s when things got ignored.
As much as it’s been brought up in the forums (by many of us in this thread many times) I can’t see how the devs don’t understand how much of a problem this tends to be.
