This release looks really nice according to the release notes
Can anybody tell me if all the grouping features, labels etc. can be defined in yaml or if they are only available via the UI?
UI only. As per above.
The update to 2024.4.2 appears to have fixed the issue on my end. I suspect that the real culprit is an automation I had that used an Until loop. The latest version added a change that automatically breaks loops that execute 10,000 times, which I saw happen in the logs, and probably stopped the issue from happening.
Even in 2024.3.3 I did have some issues where the containerās RAM usage would balloon over time and eventually cause it to restart after several hours. In hindsight it was probably the same automation that caused it as well. Iāll continue monitoring this for a few days, but after updating the automation to use a wait template instead, I have not seen the issue pop up anymore.
that might be the case, and it is guarded now. I wouldnāt rest though until I had fixed that automation from looping. because that in fact is your real issue
suppose you did read the release notes and the many topics on this matter before asking ?
Enable debug logging for the integration and see if you can get more information.
sorry, very scarce internet while traveling here. not back for two more weeks.
but okay, if only ui, then well, I guess I am in for a disappointment when I get home
haha, cool. I can relate to thatā¦never update when away from homeā¦(learned that lesson the hard way)
your guess might be wrong. the combination of yaml configuration and labels and categories in the UI is a great one.
It allows you to write your YAML as you like it, and still be able to label anything (with a unique_id) you want in the UI, and edit those, and still be safe you have the right labels anywhere in your system, without having to rummage the yaml to re-edit the labels all over if you changed your mind on 1 of them.
Just give it a try and I foresee it will grow on you very quickly
Thatās the problem. I donāt want to switch to the WebUI. And when I reference a label within YAML automation, I want to stick it to the devices within YAML config as well (so I donāt have ādanglingā references).
Thatās ctrl+shift+r (search and replace) within the IDE. Easy.
Plus with text files you get the benefit of git diff to double check if everything went right. Or easy revert back with git reset / git checkout. Or git stash temporarily part of the changes. Or git branch to try a few versions and easily switch between themā¦ Etc. Etc.
Nope, UI labels are not the answer for power users.
There are technical difficulties adding labels via yaml, the same difficulties that we are plagued with when using entities from yaml. I wouldnāt hold your breath for labels, areas, or floors being added to yaml because of this. Itās time to enter that acceptance stage.
Packages are for power users. If youāre using yaml to do everything, then packages are what you should be using. Organizing the UI should be your last concern.
Personally, I use both packages and categories. I make my categories match my packages.
Labels are entirely different. I use them to key off specific entities or areas. I currently use target_light
label for on/off area templates to ensure my zwave entities use multicast. I have a script that aggregates the area entities and filters down to target_lights for that area. Then those entities are passed to a script that uses the appropriate zwave multicast information to turn them all on at the same time regardless what domain the entities reside in.
I also have a set of lights labeled ambiance. When I say turn on kitchen ambiance to my voice assistant. She properly turns on just the lights that are tagged with the label ambiance instead of the normal set of ātarget_lightsā for the kitchen.
dont think this is the perfect example of a great user experienceā¦, try to do that in the app while commuting to workā¦
(yes I am an all yaml package user, and yet easily fell in love with UI labels)
Sadface
hey, Iām still at bargaining ā donāt rush my death stages
Yep, thatās what Iām doing.
I work from home
cool haha, me tooā¦
just give it a try, have a few test labels set up, and write your templates using them, and what Petro does above. My honest guess is you wont dislike the ease of it compared to your git trickery
I use it all. I thought I liked organizing groups via yaml long term. Turns out I constantly forget to change things around when adding a new device/entity. Iām hoping that because adding devices is typically all done via the UI, that Iāll remember to label after onboarding the device.
This is coming from 8+ years experience managing a yaml configuration.
The new lists in the UI with filtering definitely make it easier to view this information instead of hunting through my packages for the correct group.
TLDR: Donāt knock it til you try it. Iām at the trying it phase.
+1 to that.
as exchanged yesterday on Discord, Iāve been able to do away with a few old style groups the current UI methods dont provide a group for yet ( device_trackers)
the only challenge migrating to label entities for my purposes was a bigger template that had an attribute for the last_changed of that particular group, and trigger automations based on that.
but even that can be easily templated (see below set last
, so bye bye group for that:
tekst: >
{% set last = (label_entities('speler_tracker')
|expand|map(attribute='last_changed')
|map('as_local')|sort(reverse=True)|first
|default(now())).strftime('%D %X') %}
{% if this.state|int(-1) != 0 %}
{% set count = this.state %}
Tracked: {{count}} -- {{this.attributes.get('home')}}
{% else %} Nothing tracked: {{last}}
{% endif %}
got to be honest: with more than a few labels, the UI is getting cluttered, both in the labels list, as under the labeled entities.
but I trust the devs will work that out with the feedback we all give them
I donāt have quite that many devices, just my two ecobees, but my homekit startup time is 11.98s on RP4.
ouch. Which device creates the Thread network, something from Apple or OTBR in HA or something else?
just found another reason why that label option in yaml wont be as straight forward using a config searchā¦
one could of course argue the concept of label
was not very well chosenā¦ but, given tag
was also already takenā¦
Just started exploring the use of labels (goal is to migrate away from the nested legacy groups I now use to organize lights, motion sensors, etc). Ideally I would like label_entities
to support more than one label.
For example, this would give me all outdoor battery-operated temperature sensors.
{{ label_entities('outdoor', 'battery', 'temperature') }}
Currently, label_entities
only supports one label argument. Maybe I am overthinking it but it seems I would need to use label_entities
three times (once for each of the three labels), convert the three resulting lists to sets and then get their intersection. Doable but not nearly as neat as having label_entities
take care of it.
Or have I missed something else that simplifies the task?