Ah great! This way it makes totally sense. Checked both affected integrations (filesize, tankerkoenig) and both support disabling polling. I’m gonna create a general update entities automation for that, use one (or more) time pattern trigger and decide depending on the integration/entity if update service shall be called. Nice! 
Zones now have a value (number of persons in that zone).
But: can we make the values shown as graph?
Is:
Want:
(just an example)
In customize.yaml I used
zone.home:
state_class: total
unit_of_measurement: ""
and after a sensor update now everything is fine.
Just wondering why it hasn’t been set as default? Maybe someone is willing to raise a feature request for this on GitHub.
is there a way to have for the Action → more - info to show all members of the group for individual control and not the group itself?
Before using the helper groups or when still using the groups via YAML this gave/gives an entity of domain “group”, which was/is obviously quite easy to get using {{ states.group | list | length }}. So I could say “group.*” are all my groups. Now they span over various domains, but are still presented as an entity which could be just ONE entity, not a group.
Long story short:
How to check with templating if a group created e. g. as “binary_sensor” group really is a group?
Do we need to count the number of elements in the attribute “entity_id” or is there a smarter way?
count
{{ states | rejectattr('domain', 'in', ['scene','sensor']) | selectattr('attributes.entity_id', 'defined') | selectattr('attributes.entity_id', 'iterable') | rejectattr('attributes.entity_id', 'string') | list | count }}
entities
{{ states | rejectattr('domain', 'in', ['scene','sensor']) | selectattr('attributes.entity_id', 'defined') | selectattr('attributes.entity_id', 'iterable') | rejectattr('attributes.entity_id', 'string') map(attribute='entity_id') | list }}
3 Likes
Thanks! I think I would have never built that on my own. Please note for the entities line there’s a pipe missing before the map.
Or alternatively just do this:
{{ integration_entities('group') }}
3 Likes
That indeed is ways shorter. While switching to this I noticed, {{ integration_entities('group') }} does not catch my climate group generated by GitHub - daenny/climate_group: Home Assistant Climate Group (using this custom one cause HA still does not provide it out of the box) with the following attributes:
hvac_modes: auto, heat, off
min_temp: 7
max_temp: 32
current_temperature: 18.5
temperature: 16.5
entity_id: climate.trv_a, climate.trv_b, climate_trv_c, climate.trv_d
friendly_name: All TRVs
supported_features: 1
Why? What is missing for this climate group so it is not catched/counted by {{ integration_entities('group') }}, but it is by using
{{ states | rejectattr('domain', 'in', ['scene','sensor']) | selectattr('attributes.entity_id', 'defined') | selectattr('attributes.entity_id', 'iterable') | rejectattr('attributes.entity_id', 'string') map(attribute='entity_id') | list }}
?
I think maybe the long variant goes straight for something like > 1 element in attribute “entity_id”. As the {{ integration_entities('group') }} seems to be not aware of custom groups, it can’t count it.
Is there maybe a certain attribute needed for groups, something I can report to the climate group custom integration author?
Right, because that entity isn’t created by the group integration. It’s created by the climate_group integration.
The integration_entities filter is very simple, it returns you a list of all entities created by the integration you name. It has no idea what a group actually is. Entities made by climate_group aren’t made by group so they aren’t included. If you want them included in the list then do this:
{{ integration_entities('group') + integration_entities('climate_group') }}
As an aside if you have non-group entities in here then you may have some issues using this list, or at least some inconsistencies. Like if you try and call expand on this list that’s going to behave differently with entities created by climate_group then with entities created by group. Since when you expand an entity created by group it expands to a list of entities within that group but when you expand anything else it just gives you back that entity.
Yes, that’s exactly what’s happening. Hence why petro’s template is specifically excluding scene and sensor. Sensor entities are never groups but may have that attribute. Scenes are never groups and always have that attribute. You wouldn’t want either to accidentally show up. It’s also possible there’s other types of entities that can’t be grouped which are accidentally in that list due to customization or how a particular integration you’re using works, those are just the obvious ones.
It’s not really a bug. There’s nothing the author can change within that integration that would affect this. It’s a different integration from group so its entities won’t show up when you do integration_entities('group').
The only thing they could do is enhance group in core with support for climate-type entities and deprecate that custom integration. But since climate entities don’t have a binary state I’m not really sure that would be accepted. Not really sure how you group them tbh. Seems like what you would really want is the universal integration to add support for climates. Since a “climate group” sounds a lot more like a “universal media player” then a “light group” to me.
1 Like
Thank your for your explanation, learned quite something - again 
I tried {{ integration_entities('*group') | count }} before to “just catch anything” but it does not support wildcards, so I’ll end up with the line you wrote.
Indeed, a climate group is quite similar to a universal media player. I want to
- play a certain music in all rooms (of that group)
- set the temperature for all rooms (of that group)
It’s the same. A bit tricky is the state, currently the climate group custom integration uses the arithmetic medium of all climate entities to create the current temperature value of the climate group. I think that could lead to discussions (and it might be a bit more tricky than with a generic media player which has defined states like playing, idle etc. - not a range of states on a numeric scale), even that state is not that important. Maybe there’s a better, smarter solution.
Where’s the best place to bring up this “feature request” of a universal climate group?
I am aware of the feature request section of this community, but does the HA Core GitHub repo offer this too? (I think the HA iOS Companion app team does so)
Tbh I was wondering why it didn’t exist when upgrading to 2022.4, there are so much other useful group types, only climate group is (still) missing.
Core just uses Feature Requests
Well not the only one. If memory serves most controversial one at the time of this release was lack of support for person groups in the UI since legacy groups supported grouping person entities. Also notification groups are still only in YAML but issues with that one were specifically called out in the release notes.
And I mean universal media players aren’t ui-configurable right now either. Basically this release made it so if there is a type of entity with a binary state you can easily make groups of them. Entities that don’t have a binary state can’t be grouped by the group integration, they’ll have to be grouped some other way. That wasn’t part of this release but certainly could be done.
Did you find a solution for this?
As far as I remember I restarted HA and the issue was gone. I learned that restarting HA once or twice after an upgrade can magically fix issues.
Thanks. I notice restarting fixes this indeed though it sometimes takes like 8 or so restarts.
This means I can’t schedule any regular restart because the chance that Telegram doesn’t work after 1 restart is very big.
I see the Problem. But what if they all have the same types? Why not resticting to merge different HVAC types meanwhile?
The type doesn’t really matter, its a question of how to set the state. A group entity has a binary state, on or off. climate entities don’t, their state is equal to their heating mode. So its not binary and there’s really no clear way to make them binary.
I can’t remember if I said it here or elsewhere but what you should look at as an example here is universal media player:
There’s no media player group for the same reason there’s no climate group - media players don’t have a binary state. Instead we have the universal integration, which allows you to create a parent media player which has its state set from its children and commands all of them with a single service call.
I believe what you really need is for the universal integration to add support for climate entities. And also become ui-configurable. At least in my opinion, perhaps the code owner disagrees, idk.
EDIT: Actually, why not, it is WTH month after all:
Oh. Weird, guess I’m wrong then. Whats the point of universal media player then?
Either way that’s clearly not binary state so I guess a climate group could work if groups have been expanded. Someone just needs to lay out logic for what state the group is in when the members are in different modes
The logic makes sense, could probably be extended to climates
For example, you have separate devices to combine: Maybe it’s a separate amp and TV. Maybe it’s an old dumb audio player with a Pi connected to it and the player connected to a smart plug.