Actually I do remember… maybe in a beta version or somewhere that we had to use true/false and that on/off was going away… perhaps that was when they upgraded the yaml version and perhaps it was reverted… in any case I think it makes sense to emphasise true/false… I do remember trawling through my packages and search/replace for that.
Yeah, I disagree (surprise! 
).
Since the resulting state is on/off it makes more sense to use on/off in the config for consistency.
But I think the way it’s going to be done now is a good compromise.
On/off will eventually go away as it’s not supported in latest yaml so eventually you will have to change lol.
If those go away then the state of the automations will have to be changed to true/false (for consistency, right?) so at that point it will make sense to use true/false again.
There were two cases where an automation could incorrectly restore as off. Both have been addressed and will be part of 94.1: https://github.com/home-assistant/home-assistant/pull/24390
6 Likes
The last_triggered being lost when the initial_state is set, is addressed in https://github.com/home-assistant/home-assistant/pull/24400 and, since it contains a potential breaking change, will be addressed in the next release. (0.95)
I’ll adjust the docs to reflect all recent changes accordingly.
5 Likes
I have to say that I have found this thread, interesting, informative and slight disconcerting.
The most fundamental part of HA, or indeed any home automation system, is surely the automations. The fact that there is so much confusion and uncertainty over whether we can rely on them even being ‘On’ is something which really needs to be addressed - and clearly is being (@frenck).
EDIT: and yes, seeing the post following this one by @123 I really should also have thanked you.
I do hope though that it is not being done in a piecemeal, stick a plaster over the wound kind of way. I’m thinking specifically of this new (to me and probably 90%+ of all users) change, albeit externally influenced, governing what constitutes valid definitions of a binary state.
If going forward, only ‘true’ and ‘false’ are to be valid (and I can understand why that might be the decision) then can we, at the same time that the other breaking changes come in, consider going the whole way and changing initial_state to (e.g.) initial_state_on?
0.94.1 will introduce one of the best breaking changes bug fixes to date:
- Failed startup will not set automations to
off. Fail-safe mode will be trulyon.
0.95 will introduce one of the best breaking changes to date:
- Optional use of
initial_statewill no longer reset the automation’slast_triggeredattribute.
Thank you balloob and frenck!
EDIT
Revised as per frenck’s comment below.
1 Like
It will not introduce a breaking change. The automations state restore is a fix and part of 0.94.1. My change is a breaking change, since we do not introduce breaking changes in minor releases, the last_triggered will be part of 0.95
Thanks for the clarification (I amended my post accordingly).
Although making fail-safe mode truly on is not technically a ‘breaking change’ it will nevertheless be a ‘breaking change in behavior’ for users who have become accustomed to salting all their automations with initial_state: true. That option will now become truly optional.
No it is not. It was a bug that didn’t show up in all the unit tests. Bugs have been fixed, unit tests are adjusted and in place to guard it from happing again in the future. PR’s are linked above, feel free to take a look.
5 Likes
These changes are all positive. I still want an option for some automations to be permanently on, i.e. no ability to turn off. This would apply to 95-100% of my automations.
Hide the automations from the UI. Make one automation send you a notification if any turn off.
1 Like
Or, better, make an automation that if those are turned off, turns them back on. It won’t stop it from being an issue if that one is turned off, but if you set it with an initial state you should be safe.
1 Like
These are all workarounds.
There are still failure modes.
Being able to turn automations off isn’t a failure mode. It’s working entirely as designed.
If you think you shouldn’t be able to turn an automation off, ever, then open a feature request or submit a PR (pull request) that provides that feature.
3 Likes
So hence forth we shall no longer recommend the befuddled newbs use initial_state. All will be well. The kill bots will be enabled by default.
I am the author of the PR mentioned above. I asked to notify me about proposed changes, that’s why I’m reading this and I have something to say regarding the situation.
There are links to discussions similar to this one in the PR’s description that show why it was created.
From my point of view the reason of these discussions was a lot of undocumented changes in HA with some of them having bugs/issues.
As you can see, I was not alone.
Even now, if you read this thread, there is still a lot of unclarity/options/open question. That’s ok, it’s still in development.
If you read a proposed draft, if’s much more complex that anything that we ever had in that Initial state section of the documentation. A lot of things had been spotted/added by other participants of this discussion as it’s hard for just one person to know/experience everything.
I made that PR because the documentation did not reflect the state of things at the time and there was no-one else willing to do so.
I agree that it has some incorrect statements (but it wasn’t completely incorrect). On the other hand, that initial_state and last_changed link has never beed reflected in documentation and was apparently a bug that will be fixed soon, making part of the proposed draft obsolete/irrelevant. That’s life. If that was a merged PR it’d have required another PR to correct it. That’s exactly what I suggested to do to the person who was asking for the reversal.
I’m really sorry if my PR made so many people confused, that definitely wasn’t my goal and I hope the documentation will be fixed soon, it’s not a big deal after all.
But I’m also very sorry to see more than one person treating others on this forum as enemies and publicly accusing them in all sins just because they made a mistake. I thought it’s a community and we are here to collaborate on something called HA, but I cannot call such an approach collaboration. And I think it has much deeper impact on the community that a bug in code or a genuinely misleading bit in documentation.
I’m not concerned about my appearance at all and I clearly stated in my response in comments to the PR that my only goal is to have an up-to-date and correct documentation for everyone to use.
I did not “take umbrage”, but after reading and analysing all related to this issue I’ll think twice every time I have something to share/contribute exactly because of those “friendly” people.
2 Likes
Except it is. You created documentation that is wrong and it only takes a minute to prove it. Better to have left it the way it was (which wasn’t wrong).
The best response is to simply take ownership of the error and correct it. Instead, you devoted your time and effort to create excuses (both in Github and yet again here).
Throughout my long career in engineering and IT management, I made it clear to my staff that mistakes will happen but what you do to correct them is how you set yourself apart.
What’s happening here is that unproductive practice commonly abbreviated as CYA. Excuses, beating of chest, and misdirection do not fix mistakes, they draw more attention to them (see ‘Streisand effect’).
That’s some measure of chutzpah to bring up ‘collaboration’ in this context. How much ‘community collaboration’ was involved in creating the incorrect documentation?
If the goal is to build a strong community then one of the pillars is clear channels of communication. That means being able to tell someone they made a mistake and here’s how to correct it. The other person owns the error and fixes it. Done. Everyone moves on, secure in the knowledge that we all make mistakes but what we do to correct them sets us apart … from the people who are more concerned about excuses and appearances and tone than just fixing their mistake.
This project would grind to a halt if identified bugs and other errors were not met with a prompt correction but with excuses, deflection, misdirection, ‘shoot the messenger’, and everything else under the sun except fixing the error.
2 Likes
In his defence, I ( @frenck ) merged the PR, therefore, in the end, I’m the responsible one here.
I’ve corrected it.