state_attr was the right hint.
But for me to count light groups only once I found this to work:
{{ states.light | selectattr('state', 'eq', 'on') | selectattr('entity_id', 'in', state_attr('group.xx_li_alle', 'entity_id')) | list | count }}
With this template light groups are only counted as one single light.
Nice work; select all lights that are on then pare it down to just the ones listed in the group’s entity_id attribute. 
More a general question but I miss an important feature from the deprecated yaml configuration option:
How can I set the former scan_interval configuration for the YAML removed and GUI integrated integrations like filesize or tankerkoenig? Couldn’t find it in the UI 
Everything default in “system option”:
I want/need to limit the amount of updates of certain (filesize) sensors. Now especially my logfile and recorder database filesize sensors update like crazy every few moments.
I have seen another thread which says the idea now is to check via an automation which runs the homeassistant.update_entity service.
More information on this please. At the moment I don’t get how that (additional automation) would block the default behavior of HA updating at the standard interval.
I want LESS updates, not even more 
Turn off polling, make an automation using homeassistant.update_entity
So if the integration supports this in the UI(not 100% sure, but looking at a few of mine, I don’t think all offer the option), you disable polling for updates in the System Options menu item:
Then you’re responsible for updates using an automation. This could be as simple as a time pattern trigger (e.g. every five minutes, update the temperature) or something more complicated. For instance, I have a scrape sensor for a radio station website’s current artist and title track info. If I have that station playing on my chromecasts, I want it to update frequently (like several times a minute so it matches the audio as closely as possible), but the rest of the time, it doesn’t need to update at all, since I’m not interested in that data. In the case of the Scrape sensor, that’s still set up in YAML, so I just set the scan_interval to 86400 seconds (24 hours).
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 }}
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') }}
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.
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
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.