So, adding a label won’t count as editing the automation (and hence having to migrate it)?
I should spin up my test instance and check this out. I just don’t want to risk anything dubious with my production instance.
The categories and label work also with old yaml files.
For me the move from many yaml files to GUI was impossible to grasp without a way to categorize them. In YAML I had multiple automations in one file and also sub-directories. With categories I can now organize them in a way that is logical to me. I will mainly use the GUI automation features to support me with the syntax. I am sure I will still write most in yaml mode.
I often use my iPad for doodling with HA so being able to edit yaml in the GUI is going to be nice for me.
I do not use packages.
I have yet to use labels.
Enjoy the new categories and labels with your good old yaml files. It works. It seems the label and category info is stored in .storage json files along with names and areas etc
1 Like
One of the reasons the request to be able to add labels to a entity using yaml, was in the situation of writing packages that expand/enhance the sensors that are available within HA, or added by another integration.
For example for a brand of solar inverters/batteries/meters the integration adds the ‘basic’ sensors, however beyond this to determine flows of power or how much energy went where / saved or cost how much, it requires writing a bunch of ‘addon’ custom sensors.
Given that an end user installing these yaml packages can filter and see the original integrations sensors (using the ability to now filter by the integration itself), but this will not include all the custom sensors that are part of their solar systems overall sensors/entities, as the custom sensors would be not part of the integration and instead show as ‘template’ or ‘utility meter’ etc.
Having the abilty to simply add a label into the package yaml code, allowing these custom sensors to be easily and quickly identified would be the easier way to go, than expecting end users having to be told how to manually identify and then allocate each sensor (that may be in one case 200-300) the required label via the GUI.
3 Likes
Thanks for the explanation, Kenneth.
From what I read here is that it’s not possible to add labels through YAML. So something like below is not possible now?
- alias: "[home|vacuum] Update Alfred Map When Running"
description: Update Alfred Map every 5 minutes when Alfred vacuum is running
mode: restart
labels:
- vacuum
- alfred
- map
categories:
- vacuum_automations
trigger:
- platform: state
entity_id: vacuum.alfred
to: 'cleaning'
condition: []
action:
- alias: "Start updating Alfred map"
repeat:
while:
- condition: state
entity_id: vacuum.alfred
state: 'cleaning'
sequence:
- service: homeassistant.update_entity
target:
entity_id: camera.alfred_map
- delay:
minutes: 5
I think something like this is a must for us YAML users.
4 Likes
+1
I need to define template sensors in YAML since icon template does not work via de UI, but then I lose the hability to add labels
100% same issue for me.
+1 - Same for me.
The same, this feature needs to be implemented.
Still a big need from my part, same goes for categories if that’s possible.
1 Like
+1 to this. After being frustuated and going deep down the rabbit hole attempting to rewrite the custom integration i personally use to configure everything via yaml, came here to see the reason things are locked behind GUI and i’m incredibly dissapointed at all of this, including this ADR… Forcing the user to do manual interactions after deployment feels so 2015 in the era of infrastructure as a code. Probably made sense 10 years ago, but now that provisioning (and rotation) of secrets can be automated securely that decision makes no sense.
2 Likes
+1 to this, I prefer having version and consider the yaml less confusing then bouncing through a ui.
How is this not a thing? Is there any goal to get to parity between the YAML and GUI? Any goal to make YAML or GUI a superset of the other? Is HA moving towards a more GUI focused future, and YAML not recommended? I’m having trouble understanding the overarching design principles here.
There are many reasons to prefer text based configuration (versioning, speed of editing, organization, etc). All deficiencies like autocomplete, etc can be overcome with editor plugins. Yes, a lot of people will never be comfortable looking at text. But Home Assistant is the one tool that is powerful and useful for advanced users. It would be really unfortunate if the path forward is to intentionally leave those users behind for the sake of appealing to people who are probably using some other system anyway. These would be the people who are capable of writing integrations, addons, blueprints, etc.
At the very least, if YAML is not a priority, it should be possible for someone to write a plugin of some sort that would allow support to be added. I do not think core functionality like that is exposed in any way, but it’s possibly something to consider.
4 Likes
HI,
I do not know if I am here at the right spot. I am developing a ESPHome device, that connects to HomeAssistant. In HA I have scripts running that calculate the next deep sleep of the ESP and how long it should be. I will have “some” of these devices. I do have the ESP YAML working for “some” device, and I do have the HA YAML for each device as a yaml. Both are automatically generated if I provide a new device.
At the moment I am debugging. My aim is in debuggin to concentrate on one device. But I do need to see “everything” that has to do with this device. In the logbook I can choose a device, which gives me the sensors, but not the automations. At the moment I test with two devices, and for me it is quite confuding to oncentrate on one devide, as you can see in the screenshot.
Is there any way that I automatically give my automations a “device label” in the automatios yaml configuration? I did not find a way. Again: Sorry if this is not related; if related: please add this feature 
many thanks
Juergen
It is not there is a GitHub issue opened since 2024 apparently HA is moving more and more to a UI based tool
Yeah, and it sucks. The UI is flashy and all but you can’t bulk tweak stuff with scripts nor can you have verbose comments explaining the organization of things and grouping them logically by function like YAML packages. And its impossible to do diffs between similar stuff (e.g. upstairs vs downstairs HVAC control) in the UI like you can in YAML, nor can you restore just one set of things from a backup in the UI (e.g. if I hose my YAML, I can revert ONE file for the relevant things I touched and leave the rest as it was)
Really quite maddening!
1 Like
I do all my config through YAML via generation scripts and want to start organizing stuff with labels and areas without having to UI point and click.
So I’m working on a custom component. Here’s a sample of the YAML config.
I can’t extend the YAML syntax for template or automations to include label - though the labeler sections can be added at the package level. It will add / remove labels at startup. Thoughts?
labeler:
labels:
- name: "hvac"
description: "hvac system"
label_id: "hvac"
icon: "mdi:hvac"
color: "blue"
- name: "not_hvac"
description: "not hvac system"
label_id: "not_hvac"
icon: "mdi:hvac_off"
color: "red"
entities:
- entity_id: "sensor.sun_next_dawn_2"
labels:
- "hvac"
- "not_hvac"
- entity_id: "automation.heat_home"
labels:
- "hvac"
Why not just use an automation with the Label Management actions Frenck has included in Spook?
That approach is so “imperative” while we need a “declarative” approach, otherwise you would have to create a script that checks if a label exists and then set it if not, having it in yaml would be so much easier
Thanks for pointing that out. Much better to use existing code than writing the same code again.
Here is my current plan:
For templates, I’ll add a custom attribute “labels” in the YAML. At home assistant start run an automation that processes these. This makes it declartive, uses the actions already in spook, and is a relatively simple automation to create.