Adding comments tags to automations, scripts, scene etc

Feature Requests
1

I imagine a comment tag in the yaml so that we could add comments with more specifics about what an automation/script/scene does. Also to an entity, where is it located specifically, what component it is etc. Basically just free text. This could be displayed when you hover that entry, or show up in the popup box when you click it. Bonus if you can edit the comments from the frontend gui. Example of what i’m thinking.

- id: light_bath_dim
  alias: 'Dim down bathroom lights'
  trigger:
    platform: state
    entity_id: sensor.fibaro_fgms001zw5_burglar
    to: '0'
    for:
      minutes: 10
  condition:
    condition: state
    entity_id: light.qubino_zmnhdd1_level
    state: 'on'
  action:
    - service: light.turn_on
      data:
        entity_id: light.qubino_zmnhdd1_level
        brightness: 40
    - service: light.turn_off
      entity_id: light.sonoff_basic_3
  comment:
    - title: 'Dim down bathroom lights'
    - content: 'This automation will dim down the downlights 10 minutes after the motion sensors last motion detection on the condition that the light are still on. The condition is to avoid that the lights will be turned on if they were turned off manually. It will also turn off the mirror lights immediately.'

I personally think this is a nice touch that can make it more user friendly for the end users. How nerdy and detailed the content is, is obviously up to the person making that comment.

2

Sorry to necropost, but I desperately need something like this, and I’m disappointed to see how little discussion there has been of anything like it, or of adding custom attributes, or ANYTHING that would allow me to add further information that hasn’t been strictly predetermined by the HA develoment team. I want to be able to categorize or classify scenes by mood, style, time of day they’re intended for, etc, so that auto-entities can read the fields break them into cards, display or hide them depending on context or sensors, etc. It’d me nice to have some sort of flexible, customizable field (besides name, etc) somewhere in the schema that allowed me to define my own uses like that.

2 Likes
3

Perhaps you are referring to the lack of recent discussions. It was discussed in the past and the result was the addition of the description field to automations. Beyond that, the development team has revealed no plans for a grander scheme.

There’s no discussion about that one because it already exists for entities. You can easily define custom attributes for an entity (and reference it within a template).

4

Thanks for the reply. Pardon my newbieness, but to my extremely limited-as-yet understanding, those don’t appear to solve the problem I’m talking about.

I hadn’t run across that description field for automations in the couple of times I’ve sat down to try to find an answer to this, as I’m not using automations at all, so I guess it never came up in my searches. This may be due to my unfamiliarity with the system — I assumed scenes were the way to go to store and recall configurations of lights & their settings.

As to the custom attributes, I’ve read that page before. I think the problem is I haven’t expressed myself clearly here.

What I’d like to do is extend the schema so I when I define a new scene, I can include a new mood or time_of_day attribute and in fill it in, right there in the scene definition (or, yes, even just a freeform comment or description text-entry attribute would probably work too.) I understand that I can go to a separate section of my config, create a second entry for each specific scene (or an entire domain, or by glob, or whatever) I want to add an attribute to, and explicitly define those attributes’ names and values there, but I really hoped to avoid that, for reasons I’ll explain.

Full disclosure: I’ve been a professional database developer for almost 25 years — information architecture and data entry UX design is what I do all day. So I’m more pedantic than many about avoiding redundant data entry (such having to manually type in a primary key field, e.g. a scene name, in more than one place, and then subsequently manually keep any changes in sync forever) because I spend my workdays resolving the data entry messes created by those kinds of design decisions on the part of legacy system developers. Seriously, data normalization should be taught in our high schools, our entire economy would benefit. </soapbox>

If right now the only option is to do it with redundant separate scene entries in two different places, then so be it, that’s the only way to do it, and I’m totally grateful for everything the devs have built no matter what. But, I wanted to speak up and contribute a viewpoint in support of what I think would be better design. Perhaps someday someone will see my comments and say, “You know, that guy was right.” If I continue to get deeper into HA (and can find the time!) perhaps I’ll find a way to code the change myself someday.

Like I said, I’m a newb to HA, so if I’m misunderstanding something, please don’t hesitate to correct me — apologies and thanks in advance.

3 Likes
5

Perhaps you are referring to the lack of recent discussions. It was discussed in the past and the result was the addition of the description field to automations. Beyond that, the development team has revealed no plans for a grander scheme.

I just tried this, adding description: test to an automation. It seems to only be visible in the automation editor, not as an attribute nor in the automation dialogue. Is that it?

6

I am not sure if i am misunderstanding the request, but you can put comment tags in the automation.yaml files:

- alias: Home Power On/Off
  trigger:
  - platform: state
    entity_id: sensor.home_power
  condition:
    condition: template
    value_template: >
      {{ trigger.from_state.state != 'unknown' }}
  action:
# For debugging purposes only
#  - service: system_log.write
#    data_template:
#      message: "The state of the switch is {{trigger.from_state.state}}'den şuna geçti:{{trigger.to_state.state}}"
#      level: warning
  - service: notify.pushover
    data_template:
      message: >
        {% if is_state('sensor.home_power','True') %}
        Elektrikler Geldi...
        {% else %}
        Elektrikler Kesildi!!!
        {% endif %}

You can use # for comment line. The only downside is; if you use automation editor with this, it deletes all comments. That’s why i am using a text editor on automation.yaml files only.

1 Like
7

That’s what I do and have configured it so my automations are stored separately from the ones created by the Automation Editor (to prevent it from purging my comments). However, comments don’t provide the functionality desired by hulkhaugen:

This could be displayed when you hover that entry, or show up in the popup box when you click it. Bonus if you can edit the comments from the frontend gui.

1 Like
8

I would like to have comment field to in both automations and scripts.
Comments with # can’t be used in UI.
Dedicated field for this would be best solution.
We can call it comment or description, and in UI editor it should be displayed at the begining of the automation / script.

1 Like
10

It’s not pretty, but I’ve solved this by creating a “helper” text input text field called “comments”.

When I want to have a comment, I just call the service input_text.set_value and put whatever I want my comment to be.

2 Likes
11

GF, I have been struggling with this for a while! Some people believe REM statements are a sign of bad programming. (Young people say, "Comments are for bad ‘coders’ but I like to comment my code. When I put comments directly into the yaml code, they work, but the next time I use the UI for any code, all my comments are removed. Could you please explain how you ‘call the service’ to put comments into automations.yaml?

TIA

12

I couldn’t agree more. I’m almost embarrassed to admit how many times I’ve spent several days hammering out an automation, only to come back some time later to make a change and not being able to figure out what I was thinking when setting it up. Adding a comment here and there to remind my future self what I was thinking would go a long way. In my mind, I imagine it being much like the (relatively) new trigger IDs. To add one, you click the trigger menu drop down and select “Edit trigger ID”, except these would be with actions instead of triggers, and instead of adding trigger IDs you’d be adding comments.

3 Likes
13

We don’t need none of this tweaks, I discovered that we can write comments/free texts in the description field. In the 3 dots menu when editing an automation, open the 3 dots menu, click “rename”, and it’s possible to edit the automation name and also a long description.

2 Likes
14

Whenever I add comments in the ‘yaml’ version (to know what I’m doing e.g. when setting up a template) and switch to UI version all the comments are deleted

15

Similar as Why does dashboard not allow comments in the code

The code is stored as json, and json doesn’t do comments. For automations/scripts it is a bit more complicated, but it is first stored as json, and then converted back to yaml for automations.yaml and scripts.yaml

2 Likes
16

While there is no way to handle YAML comments for the reason TheFes said, what could be possible is adding more commenting options to the UI. Like a comment type action that does nothing but lets you insert descriptive information somewhere. Or an option to add a description to actions, conditions and triggers which is presented as a text area, as opposed to an alias which is more of a name. This would make more sense in the UI editor anyway since YAML is basically the fallback for advanced features there.

3 Likes
17

it’s not because the code is stored in json. It’s because it is stored the way which makes it impossible.

it comes from direct conversion from yaml to json. but who said the comment cannot be treaded as any other language object?
I have to admit it ‘must not be easy especially if there is no yaml-json converter which can do that.
but creating language which ‘eats’ comments without warning?

3 Likes
18

The automation editor has to parse the YAML in order to present it to you in a form-based way like it is. YAML parsers remove comments because they’re comments. By definition they are supposed to be ignored since they aren’t part of the data so why would a YAML parser do anything but ignore them?

Even if you do the “edit in YAML” option at the top its still parsing the YAML and showing you a subset. You’ll notice the if you actually look at the automations.yaml file each automation has an id field and that doesn’t appear in the UI even in the raw YAML view since changing it would break things.

The only way the automation editor could keep comments is if it didn’t parse it at all and kept it purely as text. And if that’s what you want then just don’t use the UI editor. Add a new automation block and edit your automations in the text editor of your choice.

19

Since the migration process is non-reversible it seems like this would be a good place for a big warning message, explicitly stating in the non-reversible migration all comments will be removed in your existing automations.yaml file.

It was quite a surprise when all my nicely commented and arranged yaml code disappeared.

6 Likes
20

It would be great if all objects would have a “comment” field where we could put our comments in a string. That way, they could be kept even if they would not have a functional utility.

3 Likes
21

Both Labels, Tag’s & Folders
I would like it, If an object or entity (script/Automation) had A label/tag option, that excepts “/“ that represent sub tags or Folders in the GUI & “,” as separate Tags. E.g.

  1. Tag: “Lights” shows in the GUI in the Folder “Lights”.
  2. Tag: “Light/Effects” would show in the GUI in the Folder “Effects”, nestled under the Folder “Light”.
  3. Tag: “Lights, Effects” would show in the GUI in both folders “Effects”, & the Folder “Lights”.
  4. Tag: “Light/Effects, Light” would show in the GUI in both folders “Light”, & the Folder “Effects”, nestled under the Folder “Light”.
  5. Tag: ““is empty”” or “root” would show up under the root folder in the GUI.
alias: A Light Script
tags: light, light/effects
sequence:
  - service: light.turn_on
    data: {}
    target:
      area_id: office
mode: single

And the “Tag” option can be reference via HAss Jinja2 extension’s

state_attr ( script.a_light_script, 'tags')

When moving entities in the GUI to a different folder, the GUI gives the options “Change” &or “Both”.
Reference# Labels, Tags & Folders for Automation Scripts