You need to separate the automations you create using the Automation Editor and the ones you create with a text editor.
If you keep them all in the same place (by default it’s the automations.yaml file) any comments you add to it are discarded the moment you use the Automation Editor to save an automation.
Here are the instructions for separating your automations.
It’s what I use and most of my automations have comments that document the evolution of the automation (date and brief summary of what I changed) and the older code commented out (that I eventually delete after I am satisfied that the new code is working properly).
Yes, I’d probably word it something like “enable/disable this step” or something. Each one should be disable-able (!) if the automation logic permits. Otherwise, yes, a toggle like this would be fantastic. I do understand there are ways to do this but they require a lot of work.
I explained commenting is allowed for automations and scripts that are created with a text editor, just not if you use the Automation Editor. You’re in luck for the ones you didn’t create with the Automation editor and out of luck for the others.
Allowing for comments in automations created by the Automation Editor is a long-standing request and has never been implemented (there are long discussions about this elsewhere). The olive-branch was the introduction of the description option.
The concept of disabling/enabling individual actions is much more than merely a toggle in the UI. It would require the introduction of an entirely new (and more complex) way of composing actions. As mentioned by Arh, the current way to achieve it would be to use choose and a helper. Effectively, that’s what the Automation Editor would have to do (automatically) for each and every action (whether it employed choose or some new construct for this purpose). The result would be far more complicated code merely for the potential convenience of disabling individual actions.
I don’t imagine too many developers will rush to implement this FR. Especially when you consider that it can be done now merely by commenting out the code (after separating the automations as described above). However, feasibility and practicality have never been a criteria for a Feature Request so don’t let my pragmatism dash your hopes.
A relatively few hours to implement some form of disable step feature vs xxxxx number of users fumbling with workarounds, probably a good tradeoff.
It’s the type of thing an experienced dev sees as superfluous, but would be valuable to the casual, mostly UI user. I would think the goal of moving automations into the UI is address those casual users.
Another path to achieve similar end result, but likely much more beneficial would be versioning for UI edited automations/scripts. Keep the last xxx versions of an automation saved off somewhere to allow for easy undo/redo operations.
Plenty of cumbersome ways to manually accomplish the same now, but the whole point of the UI is to simplify for the non-geek.
I don’t believe the hurdle would be the hours to implement (although that’s a value judgment for whoever volunteers to implement this FR) it’s that the new feature will generate bloated code for everyone, all to appease the few who want the feature for the rare case when they might wish to disable one or two actions temporarily. In my opinion, the limited use-case doesn’t justify the onerous change to the automation’s underlying structure.
I do it all the time and it’s not the least bit cumbersome. All it involves is adding # to the beginning of the line and it’s transformed into a comment. Easy-peasy.
The sole prerequisite is to graduate from the Automation Editor to a text editor (like Visual Studio Code which makes commenting/uncommenting code a quick and trivial operation). It not only allows for comments but avoids several of the Automation Editor’s quirks and limitations (such as automatically converting lists into comma-separated strings thereby completely changing the value’s type).
Edit… sorry I should have made this example a condition but the same principle applies.
The problem is for those who use the GUI.
Sure you can comment out a part but when it’s saved it’s lost.
Not everyone has the goal of using only text based automations.
I like using the GUI for the main part of it, then when I need to type a template or copy paste to create multiple choose options I use yaml.
I find the mix is good for my level of yaml coding. I always forget something when going freehand.
Your suggested enabled option would need to be supported by every type of trigger, condition, and action (service calls, delays, repeat, wait_for_template, etc). This is a non-trivial system-wide modification that requires the YAML interpreter to behave selectively (normally all YAML presented is validated and converted to JSON for execution).
FWIW, the PR for this would probably have to first pass an Architectural review because it would represent a significant modification to how automations are processed.
For Actions and Conditions, the “easy” way would be for the UI editor to wrap a “choose” around a disabled action, or an “and” around a disabled condition. That’s not bloated code for everyone, only those that disable a block. It could be implemented in the UI editor alone, without touching the core automation yaml parser code. Not sure how I would address Triggers, would need to think for a minute, it may need parser changes.
There would be untold better ways to do it if you want to touch the core automation code.
Comments <> Versioning with undo/redo.
That’s the geek answer and irrelevant to those that use the UI.
Thank you guys for debating this. I think the roadmap of HA is one of simplification and streamlining for the user, writing automations in a code editor is IMHO an opposite of that. I understand this is potentially complex but the need arises kinda often for me and I imagine I’m not the only one. “Temporarily disable” can be anything from an hour for testing up to a whole year season.
Best not to use unflattering adjectives because it might embolden someone to use one for those can’t achieve anything without the UI. It’s wrong in both cases.
We can circle this tree endlessly but the fact remains that this, like all other Feature Requests, has to attract the attention of someone willing to implement it, submit it as a PR, and be accepted by the development team.
I’ve seen a few FRs over the past 3 years and this one doesn’t strike me as one that will run the gauntlet successfully. Time will tell.