As someone who prefers doing it the hard way (HA Core, as much of the configuration in YAML as possible) I second this reques wholehartedly.
Please allow us to define Floors, Labels and Categories in YAML files and assign them in YAML files as well (preferably this will include Locations)
With regards to point 4 in the original post: Why not add a floors/labels/categories attribute that accepts a list of floors/labels/categories? (and preferably locations as well…)
All of my automations are defined in yaml. Please allow us to define labels in yaml. thanks
I’d love to replace some or all of my groups with labels, but for that to be feasible it really would be necessary to have a way (service) to dynamically assign/remove entities to/from labels - like you can with groups …
The new labels are really great, no doubt. Big applause. 
I think a label is by definition a property of an item (automation, entity, whatever…).
But when having a lot of configurations in YAML I now have to define some/most of the properties in YAML but others in UI.
Neither looking at the YAML code nor looking in the UI gives me the whole picture.
Personally I would like to define labels in YAML too, just to keep everything together.
Yep, I wish YAML wasn’t a second class citizen.
not that I would have anything against the FR, but we can add labels on yaml defined automations? (as OP states btw)
All of my automations are yaml too, no issue adding UI labels
I know that I can do it in the UI, the request is to assign the labels in yaml. Silly to have to go back and forth between yaml and UI.
sorry, I misunderstood your request. nevermind then…
the use and flexibility of the Ui for labels is rather magical though, and will never be approached by what ever we might be able to do in our Yaml.
Changing the labels on the fly, attaching them to other entities and what have you, its all a snap of the finger in the UI.
Defining a label in could probably be done, but the UI truly is the place to be in this case (and thats coming from a real yaml user…)
That would be the best: experiment in the UI, see the changes in YAML.
I don’t want YAML just for the sake of typing “code” instead of clicking – I like YAML (one of the reasons) as it is a simple text file format that I can track with version control system (git). Not possible with GUI.
Yeah, this is really needed. I have lots of yaml defined automations without a unique id, provided by a hacs integration, and after assigning labels to all automations these have to all be excluded. Makes it not very useful if I can’t completely label all of them.
somehow that seems to be much more of an issue for your problem, than defining labels in yaml.
why not add id’s to those automations, and be completely editable in the UI. It’s a 1 time effort, and you’ll enjoy it the rest of the time using HA
Adding ids to automations is not same as migrating automations from yaml to UI.
(unrelated to the topic) I would suggest you to add ids to automations. This will give you a possibility to see traces, might be useful for debugging. Do not migrate automation to UI, this is for traces only.
And you will be able to add a label then - for testing at least.
I have not added any labels yet since still using my own “labels” (kept as attributes). Will probably add labels when a corr. support will be added for yaml.
This post seems relevant: 2024.4: Organize all the things! - #444 by KennethLavrsen.
For me, I’d prefer the ability to define labels in YAML.
I have unique IDs for all of them for the sole purpose of traces.
I don’t want to migrate my automations, since I’ll lose comments (vital, and no, I’m not hacking it via descriptions) and I’ll lose my organisation via packages.
I seem to be in the exact situation as you are with my Yaml config. All packages, important comments and links to elsewhere, nicely in Yaml, which we can find blindfolded). All automations and scripts in yaml.
Given the current automation editor, my thoughts on my yaml config for those integrations won’t change in the near future.
And yet, there is no reason for me to want to configure labels in Yaml. Especially since you have unique_id’s you can edit everything in the UI including the new labels.
Because with that you get the ultimate ease of being able to edit/change a label, and it being applied everywhere automatically by the system. (you will change them a lot, so having this automated is a huge asset)
If you’d set labels in yaml and add them per entity, you would have to edit the label itself, and all occurrences of that particular label yourself, which ultimately is rather error prone (talking to myself here… )
Why not embrace both ?
I might’ve misunderstood something about labels (and categories) then: It seemed like when a label or category gets added, the automation needs to be migrated. Is that not the case?
no, no migration required.
the only thing required is to have a unique_id to be able to edit in the UI.
Category is for organizing in the Tables (and can not be referenced by the backend logic in automations/templates etc),
Labels are built for that purpose mainly,
though one could also say you can organize the tables with them:
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
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.
