I’d like to see an action called comment or commentary.
It’s not a yaml #comment, just an empty action ( ala a NOP in assembly language)
Just like most actions it has a text field you can provide commentary, but does nothing at runtime.
Extra credit the runtime engine ignores this action during parsing
I vote for this - as former professional software developer I miss commenting my code very much!
Me too. The ui scripting is the only programming language I ever saw with no comment facilities, all the way back to PDP8 assembler. If the comments exist in the original yaml, removing them is major vandalism IMHO.
Hi,
I actually can’t believe that such a valuable and useful feature, which has been requested for a long time, hasn’t been implemented yet.
I have no programming knowledge and therefore can’t evaluate what the problem is, but I still hope that it can be implemented.
Voted for this request and hope there will more users find this request and vote for it
thx.
Hi,
I actually can’t believe that such a valuable and useful feature, which has been requested for a long time, hasn’t been implemented yet.
I have no programming knowledge and therefore can’t evaluate what the problem is, but I still hope that it can be implemented.
Voted for this request and hope there will more users find this request and vote for it
many thanks
I quite reasonably expected my commented out block of code to be preserved through the editing process. Because it wasn’t I have lost a fair bit of work that I will now have to try to recreate. At the very least, if we can’t figure out how to store both the raw YAML and the parser output, please at least implement a warning on save if comments are present in the YAML.
It is now possible to include alias of what each action does, both via YAML and via UI. Just use alias.
description: ""
mode: single
triggers:
- trigger: time_pattern
minutes: "0"
alias: Each minute
conditions:
- condition: time
after: "18:00:00"
alias: ">18h"
actions:
- alias: Turn on light
action: light.turn_on
metadata: {}
data: {}
target:
entity_id: light.light
I know comments have been requested a bit here, but this one is different.
The GUI programming interface is a great way to code for people who don’t want to work under the hood too much. Although I miss a simple feature which is best explained with this screenshot how it could look like.
I am not asking for commenting within the code, but more like being able to add a manual description directly to each code block. Hope this makes sense.
You can change the wording you see on that screen. They are auto generated right now. So where you see Conditionally execute an action you can change that to Turn up the light at night only.
Duh…I am sorry. Thanks petro, I didn’t even think that would be a possibility. Of course that absolutely does the trick. 
oh well, my excuse is that I am a newbie.
I found this topic for the obvious reason. After reading this, however, a bit of fooling around today shows that you CAN embed comments in automations, but it’s fairly limited. A single line comment (any statement beginning with “#”) is preserved when you save, leave the page and return to the YAML view provided that the comment is both preceded and followed by one or more blank lines. See snippet below. Multi-line comments will be concatenated into a single line when you save, leave the page and return. This may actually be a quirk in how the YAML=>JSON=>YAML process works as opposed to an actual feature, so this may change in the future.
Snippet:
# Default
{% set result = false %}
# DRIVEWAY Camera
{% if camera == "driveway" %}
{% set result = true %}
# HOUSE Camera
{% elif camera == "house" %}
{% set result = true %}
{% endif %}
Looks like I might have been premature with the above post. Everything I said is correct, but after some additional testing, it turns out that everything after the first comment seems to be ignored. These two automations - one with a comment and one without - will yield different results:
alias: Test Comments
description: ""
triggers:
- trigger: time_pattern
minutes: /1
conditions: []
actions:
- if:
- condition: template
value_template: |-
{% set result = false %}
# comment
{% set result = true %}
{{ result }}
then:
- action: notify.notify
metadata: {}
data:
message: It's true!
mode: single
alias: Test Comments
description: ""
triggers:
- trigger: time_pattern
minutes: /1
conditions: []
actions:
- if:
- condition: template
value_template: |-
{% set result = false %}
{% set result = true %}
{{ result }}
then:
- action: notify.notify
metadata: {}
data:
message: It's true!
mode: single
Comments in jinja must be {# comment #}, not #comment
This 100% is the answer. If you’re still looking for normal comments (i.e. support of any YAML comment), this is the way to do it.
You can still see all of the my_automations in the UI, and if you try to edit one, it even gives you a helpful warning (and offers to move it back to the main file):
Reviewing this thread since my April post, I think I’ll reiterate something here.
It’s not just nicely-formatted comments which are lost using the UI. Also white space. To me that can be as critical as the comments in trying to remember how I structured something the way I did. Jammed-together code can be hard to interpret.
And while I’m at it, giving each automation a meaningful ID, instead of the random string the UI creates, helps a bit, too. Not a huge issue, but certainly a nice-to-have.
One last thing: Having a separate my_automations.yaml file gives me another benefit: I can develop new automations in the UI, which becomes my “test” environment. Once I’ve got the basics working, I can move the automation to my “production” environment, which is the my_automations file. There I can tweak things further and add all my formatting and comments.
Same for steps in automation or script traces in the UI.
A couple of different feature requests have been merged into this one, however it looks like there’s a few different requests here.
alias)edit: I looked closer and had completely missed the ability to add an
aliasto any action, condition, or trigger. Leaving this comment because all the closed threads were much easier to find than anything aboutalias.