2022.4: Groups! Groups! Groups!

[123 (Taras)]

@pedolsky

how to count lights on with the described mixed group?

You’ll probably need to use a for-loop to iterate through each entity in the entity_id attribute (because you can’t use expand due to its new behavior). EDIT Example posted above by CentralCommand while I was typing …

@parautenbach

a parameter to control the depth was considered?

The PR’s link is in my previous post and my impression is it’s a direct response to the reported Issue (i.e. nested groups fail to be expanded). In other words, it wasn’t born of a need to enhance expand (with a choice of how it should behave) but perceived to be a bug-fix.

I agree with you that it probably should have provided a “recursion” option (default false in order to maintain backward compatibility). It didn’t expand light groups in the past but now it does so that breaks existing templates that relied on its old behavior.

[parautenbach (Pieter Rautenbach)]

Thanks, the PR seemed straight forward. I’m happy to go try and log a new issue for this or an FR, but didn’t want to do so straight away in case there’s already been some lengthy discussion in a corner that I’m unaware of.

EDIT: FR logged.

[pedolsky]

@CentralCommand

{% set ns = namespace(on_lights=0) %}
{% for light in state_attr('group.all_lights', 'entity_id') if is_state(light, 'on') %}
  {% set ns.on_lights = ns.on_lights + 1 %}
{% endfor %}
{{ ns.on_lights }}

Thanks for the explanation and the example!

[dylan_09]

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.

[123 (Taras)]

Nice work; select all lights that are on then pare it down to just the ones listed in the group’s entity_id attribute.

[e-raser]

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.

[nickrout]

I have seen another thread which says the idea now is to check via an automation which runs the homeassistant.update_entity service.

[e-raser]

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

Home Assistant Core Integration

[petro]

Turn off polling, make an automation using homeassistant.update_entity

2022.5: Streamlining settings

You didn’t lose it. What I described works for all integrations, YAML and UI. I already explained it, use homeassistant.update_entity. To make it more clear… trigger: - platform: time_pattern seconds: "/1" action: - service: homeassistant.update_entity target: entity_id: sensor.xyz

[gonzotek]

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).

[e-raser]

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!

[e-raser]

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.

[thesebastianf (Sebastian)]

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?

[e-raser]

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?

[petro]

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 }}

[e-raser]

@petro

{{ 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.

[CentralCommand (Mike)]

Or alternatively just do this:

{{ integration_entities('group') }}

[e-raser]

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?

[CentralCommand (Mike)]

@e-raser

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

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.

@e-raser

I think maybe the long variant goes straight for something like > 1 element in attribute “entity_id”

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.

@e-raser

Is there maybe a certain attribute needed for groups, something I can report to the climate group custom integration author?

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.

[e-raser]

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.

@CentralCommand

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.

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.