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
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
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.
Nobody mentioned âlast_reportedâ.
Imho this is a very useful addition.
Have not analysed it yetâŠ
same idea. Voted
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
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.
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
Then the only option for that is to have a tertiary id on areas, labels, and devices. Like entity_id with entry_id.
yes, I guess it would require an additional unique_id in the backend architecture.
it would make it very consistent with other HA architecture
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
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
It made the cut but didnât make the release notes.