Advanced automations still require yaml, and chatGPT gives me yaml output so I am not going to re-make it in the UI editor…
I go to automations, switch to YAML editor, paste my nice yaml code, save… Nice!
It’s a difficult one so I comment the code, or maybe I want to play around and comment few lines… Nope! If you save the automation and go back there later, all comments disappear!
Oh … this!! For sure one of the top annoyances for me.
Good suggestion! The reason for this is that we use JSON to send data around in the frontend, which doesn’t support comments.
There is an alias tag in YAML for automations that allows you to include comments about what each trigger, condition, and action does, both via YAML and via the UI.
It may not be what you want, but it helps a lot.
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
This was mentioned by another user in a separate thread, but we could make comments meta data. E.g. If you have a field:
somefield: somevalue
and you add comments…
# this does abc
somefield: somevalue
it could be converted to json with a smart metadata system, e.g.
{
"__before_somefield__": "# this does abc",
"somefield": "somevalue"
}
Treat all comments as before, except any at the end where "__after_somefield__" would be used if it’s after.
This should work for all comments. The comment itself may move when whitespace is trimmed however it would be a good compromise.
This also includes comments in dashboard configs, I’m annoyed they disappear especially when one element has dozens of lines which easily can get overwhelming to search through (image elements as example with lots of entities).
Can the translation process just be instructed to ignore the comments, rather than stripping them?
Or can it “copy” the YAML into an intermediary space before stripping the comments, thus leaving the original untouched? (#NotACoder)
I use Visual Studio either embedded or PC, all comments are kept. I never use YAML editor except for a quick test.
The system would need to know where to put the comments back. The storage is not yaml, it’s json. Json doesn’t support comments, yaml does. So when a user writes things in yaml, it gets saved in json in the backend. This is why the comments are lost. We would need to design a system to keep the comments in place using JSON.
Sometimes we have old scripts or automations that were created in yaml, but can now be edited in the gui. Or some portion of a new script or automation requires yaml (or jinja…)
Whenever you just open the script or automation in the gui - even accidentally - let alone save, close, and re-open, it removes all comments.
If I put a comment in my code, it’s because I wanted to remind myself of something - perhaps years after I originally wrote it. Just leave comments alone.
Wasn’t this why the alias option was introduced for each block of yaml?
Can alias: be used outside of automations? E.g. dashboards and cards?
Sorry to ask, but I searched and only found reference under the automations doc.
You can add any option and add some text.
But you may loose UI editor (some people cannot live w/o it):
10-4, that’s a good trick. I do prefer UI as an option though.
I’ll tuck this one away. Thank you!
Storage for automations is currently in YAML though?
Jamming reminders into the title of automations, trigger items and action titles is really limiting. How about a multi line comment in automations or entity definitions so I can remember why I did something or what I changed, etc?
Indeed, also as old-skool user of HA, I wish to edit my YAML files manually sometimes, instead of using the GUI. I use comments, line and multilines, to track changes, help find automations, scripts etc.
Please find a way to keep these comments, I need to restore backup files to often now…
I guess it’s not an option to use a different JSON library that does support comments? It’s definitely true that “stock” JSON does not, but I’ve encountered a number of JSON parsers/libraries bend the rules and allow them anyway. That said, I have no idea what all that might affect, so possibly a much bigger change than it sounds like on the surface.
The most practical option is the one petro mentioned above:
This is relatively simple to implement, should not affect existing JSON, and does not require a new JSON library.
Yep, fair enough. I guess I was imagining one that would be API-compatible so it could just be dropped in, but obviously there’s no guarantee that what HA is currently using has such a variant available. 
