Do you mean “add labels in yaml”?
better:
label: ['system','switches']
or
label:
- system
- switches
4 Likes
I suppose we could do
{{label_entities(label_id('Great Room new name')}}
where I would have loved to be able to do
{{label_entities('great_room_new_name')}}
if my label was renamed from Great room to Great room new name
3 Likes
Had that and it went away after refreshing the page.
Yes. Now I labeled all my automations. But when I create a new yaml file I start always with a standard part. So when add label: also into this. I never have to add the label later on in HA. Its automatic done already.
Marius… But then if the ID updated your labels would no longer be attached to your other entities. Do you want this to turn into what’s become of entity_ids? Where there’s an entry_id that confuses everyone on top of entity_id and Entity Name? It’s like you aren’t willing to understand the purpose of the ID and you’re not willing to change your stance.
2 Likes
Nobody mentioned “last_reported”.
Imho this is a very useful addition.
Have not analysed it yet…
same idea. Voted
1 Like
well, no of course I dont want to confuse anyone.
I guess what I am saying is, if changing a name, one shouldnt be changing the unique_id attached to the label/area/floor.
the user should be unaware of that unique_id probably, as it is tying everything together as you justly point out.
the user should also not be forced to use these complex templates because the backend currently is organized the way it is.
compare the steps I had to take to change when I renamed an Area, and the area_id remained the same. Lets say from English to Dutch…
I wanted to use all Dutch backend templates, and couldnt because of the naming I had chosen some while ago.
Only robust way to solve was creating a new ‘Dutch’ area, move all (…) devices/entities to that new Area and delete the old.
anyways, I am aware of the nested template we can use. I am just hoping at some point a backend unique_id will be added, making life just that bit easier for the end user not having to remember that
2 Likes
This is exactly what it does right now. You change the name, the id does not change.
If you use the UI, you would be 100% unaware.
You don’t have to. Use the UI, and it does everything for you.
Yes you could, you made your template incorrectly by not taking the dutch name and using area_id on it.
No, this solves your odd way of wanting to just use the area_id (that you made up) as a string instead of using the Area Name and using area_id on it.
1 Like
So, even my undated version of code for this automation still fails with the exact same error.
Can someone please tell me why? This worked prior to the 2024.4.0 update.
cool, Im fine.
just dont think I am odd… when I see my Area called ‘Woonkamer’ have the id ‘livingroom’…
Of course I am aware there are template ways to deal with that, just wished we shouldnt have to.
if you ask me if I want the same as with eg template entities? yes, why not, that works perfectly.
we have:
unique_id: (ties everything to this entity, and allows editing in the UI, no need for human referencing anywhere
name: As you like it (in yaml or UI)
entity_id: as above, just edit as you desire or reference this anywhere and all is fine
personally Id love to keep the name and label_id identical (thats why I compared it to the entity_id where I do the same).
my confusion stems from the way current label_id (and floor_id/area_id) is/are used as unique_id.
need to bend my brains to that
Please dont see this as an argument for the sake of argumenting, I need some time to change to this
1 Like
Then the only option for that is to have a tertiary id on areas, labels, and devices. Like entity_id with entry_id.
1 Like
yes, I guess it would require an additional unique_id in the backend architecture.
it would make it very consistent with other HA architecture 
2 Likes
Not exactly sure what/how you mean, but if you create/have an integration, then in Settings/Label , you create a new label, or choose and existing
Then click the 3 dots to the right, choose entities, then Group by “Integrations” , Type the name of the integration in the search-box, by that you exclude everything else.
Then click select all(to the left) , then click add Label ( to the right ) …All entities will be marked with that label/labels you choose
But i “REALLY” miss a “Select All” REMOVE Label, Now 
(wth)
Edit: Fixed removing all, in the same way , mark all choose Label in the top-right corner(add label), “un-tick” the Label you want to remove from all marked entities
No, it would be consistent with just entity_id, nothing else.
There is bulk remove for labels? Click the label you want to remove if it has a checked checkbox
1 Like
I took a punt and upgraded but now I get frequent restarts of Core - all other services and addons are working fine - unfortunately I don’t see anything in the logs yet that may indicate the problem
More detailed description here Maybe
I’ve had 4-5 attempts at upgrading to 2024.4.0, and despite there being no errors logged, my HASS instance restarts and tells me that I’m still on 2024.3.3, with an upgrade available.
Running Supervised, with a fully patched Debian system, no additional docker containers running whilst upgrading. Quite the mystery, so really have no idea where to look first, as I can’t find any errors logged