2022.4: Groups! Groups! Groups!

[123 (Taras)]

@pedolsky

I tested it with an old-style group containing single lights, a Hue group and one HA light group.

In Developer Tools → States find your old-style group entity and look at its entity_id attribute. The number of entities shown in its entity_id attribute will be the count returned by the template I posted.

[pedolsky]

Yes, absolutely d’accord. But how to count lights on with the described mixed group?

[parautenbach (Pieter Rautenbach)]

@123

It was considered to be a bug. FWIW, I feel it probably should have been reported as a Breaking Change in the Release Notes because its new behavior is significantly different from previous versions.

I’ll go search if you don’t know, but in case you do: Do you know whether introducing a parameter to control the depth was considered? Looks to me like what should’ve been done, because that way a default could’ve been specified to keep the current behaviour the same while introducing useful new functionality.

[CentralCommand (Mike)]

So the problem is your light group has light groups and you do not want it to recursively expand is that the gist? Yes in that case you won’t be able to use expand in this spot anymore. expand always recursively expanded group entities but did not recursively expand other types of groups (like light groups for example). Now all groups work the same with expand which is more consistent and less confusing but appears to be an issue for you.

I think your best solution here is now this:

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

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