Many times I wanted to temporarily disable some steps from my automations and scripts - for example, disable notifications for a door opening but leave the light turning on enabled.
I know I can break out these to multiple automations but it would be nice to be able to just disable steps.
Even commenting out manually in YAML would be fine. Right now, #comments just get removed from the YAML.
I am by no means an expert been using home assistant for a month 
I would use a helper toggle and “choose” in the trigger section of the automation, using the helper as a condition.
That’s a complicated overkill that could be circumvented by allowing #commenting out in the YAML
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).
I like the idea. Don’t for get to upvote your own request.
If I understand it correct, you want something like this:
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.
That’s not great though. Most of my automations are a result of a combination of UI editor and manual YAML editing. Almost all of them really.
You stated:
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.
But…
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).
Not necessarily, I mean if you create an automation in GUI on numeric trigger above 0 you get this:
- platform: numeric_state
entity_id: ''
above: '0'
We all know there is a below that has not been added.
The same way could this enabled work. It’s omitted if true, else it’s added:
- platform: numeric_state
entity_id: ''
above: '0'
enabled: false
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.
The juice isn’t worth the squeeze.
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.
Not meant to be unflattering, I’m a geek, proud of it. Still your right, it can be misconstrued.
I can see the functionality making a friendlier UI. It’s something I would use if it were there, but Home Assistant currently is not something I’m developing for, with no plans to.
Like you it’s not worth my time personally, it’s easy enough for me to drop to code, but for many users that will never happen.