I just use
{{ ['outdoor', 'battery', 'temperature'] | map('label_entities') | sum(start=[]) }}
I don’t think there’s any simpler way at the moment.
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.
I’ll let you know after this weekend?
I don’t know if this is related to 2024.4.2 or my change (I commented out the deprecated parameters ‘retry_on_empty’ and ‘close_on_comm_error’) and the modbus integration is working again.
Zigbee2MQTT is not longer working with this version. Rollback to 2024.3.3 via backup and all is working fine again…
Zigbee2MQTT works fine with 2024.4.x . What errors did you get ?
Not exactly true…