Hi @bkr1969
I have this issue. I’m not overly concerned as my dashboard still looks fine.
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?
I just use
{{ ['outdoor', 'battery', 'temperature'] | map('label_entities') | sum(start=[]) }}
I don’t think there’s any simpler way at the moment.
Thanks! Simpler than the set intersection rigmarole I mentioned.
I’ll post an FR for enhancing label_entities
. Labels are an easy yet powerful way to organize data and it should be equally easy to select combinations of them.
Done.
It depends on what you’re searching for. I don’t think I’d search for the world label
(what for?). I’d probably search for the particular label I’m interested in.
For example, I have an input_boolean
called neighbor_guest
. I don’t search for input_boolean
→ I search for neighbor_guest
(when I want to see where it’s being used, or if I wanted to rename it, for example).
My apologies, I responded before your other posts stating you are using Thread and since I’m using WIFI it may not be an accurate comparison.
Oh, that’s interesting, as then we can assume that slow startup times of homekit_controller
are not a direct cause of waiting for the Thread network to establish. 11 seconds for only two devices are quite a bit. I hope we’ll manage to find the issue for the slow startup time of homekit_controller
.
well sure, I get that. my remark was merely to indicate the duplicity of the term ‘label’.
and yet, even in your example, you’d have to distinguish between unique_id and actual entity_id if done manually
anyways, no use trying to convince one another, hope we all can find what we are looking for to suit our systems best
Correct me if I’m wrong (which hope I am), ‘group’ is not yet ready to be replaced by labels area or floors when it comes to state ‘on’ and ‘off’? For example, I have a “house asleep” automation where I trigger on all motion sensors for a whole floor - the motion sensors are in a group (ie “downstairs motion”) and it triggers on the group state ‘on’ or ‘off’. Would this be possible to replace by using the new organizing functions?
Depends on context
If you want to send a command by a service call to the collection of entities addressed as a list from the result of a template call, sure.
But if you wanted to have a single entity on your dashboard representing them with status. Not so much. (Im working on something involving template light to do one of mine as an experiment but it’s not anything I’d recommend - it’s quite cumbersome)
if they are all binary sensors, you can group them as a helper. Those are staying as-is. You wouldn’t replace that with a label.
Labels potentially could replace old-school groups to a certain extent but there’s still missing functionality.
Petro actually you were the one I wanted to ask.
Any limitations on using a template light to address a set of rgb bulbs (using a template that maps the area id and dumps all entities of domain x in area Y with Label Z) I think you get where one could go with that.
Any reason it wouldn’t work?
That’s what I currently do… but I have it work across domains. It combines lights and switches.
{% set lbls = label_entities('target_light') %}
{{
floor_areas('downstairs')
| map('area_entities')
| sum(start=[])
| select('in', lbls)
| select('is_state','on')
| count > 0
}}
I thought so. I want to build something that uses Tom’s Label construct (ambient/main)
And autopopulates standardized room controls. This seems the right way to do it with the new tools.
Yep, this is what I’m doing. Although I have an extra layer for zwave multicast.
I’ll have to DM you on that. I think I saw one of those posts I have a bank of 6 shades that constantly acts up and needs to be moved to multicast. But I digress.
So for the rgb etc in the template just throw an average across the numeric attributes (hue/sat. Brightness or x, y color as appropriate) figure out how I want to handle multiple states (or, xor etc) and call it a day then? Seems simple enough.
RGB will be a pain in the ass. Same with XY color. Brightness will be easy.
RGB will be easier than xy. But you’ll average each r g b value and combine them. XY… I have no idea how those numbers work so I’m not sure if averaging them will work.