Trigger/Condition entity_id: Group entities as "list of entities"

Feature Requests
1

I would like to make the case for adding the ability to use group entities as a “list of entities”, rather than an entity itself in Home Asistant triggers and conditions (or anywhere else where a list of entities can be provided, really).

For example, instead of writing the following:

trigger:
  - platform: state
    entity_id:
      - binary_sensor.sensor1
      - binary_sensor.sensor2
      - binary_sensor.sensor3
   to: ~

I could create a group group.binary_sensors and just use that group. Pseudo code warning:

trigger:
  - platform: state
    entity_id:
      expand: group.binary_sensors
   to: ~

I am using the expand dictionary key here as an example. For one to distinguish this desired behavior from the behavior of using the group itself as one of the entities in the list and two since the expand function provides similar functionality inside of templates.

The benefit of using a group is that I can more easily add and remove entities from this group and manage them centrally if I depend on that same set of sensors in multiple locations (e.g. for multiple automations, scripts or templates). It also allows me to logically structure my entities. Instead of a somewhat unspecified and unlabeled list of entities, I can have a group who’s name makes it obvious how the sensors in that group are related to each other.

One drawback I can see is that it would require the trigger for the automation to be recreated every time the group members change. Not sure if this is already something that is easily doable within the Home Assistant automation infrastructure.

Please also note the difference of this compared to using the group itself as the entity_id. In case this isn’t obvious, the group will be ‘on’ if any of the sensors are ‘on’ and ‘off’ only when all of the sensors are ‘off’. Using a group as a “list of entities” instead, the automation would trigger whenever any of the sensors within the group changes state, compared as to when the group as a whole changes state.

Future ways to expand on this – no pun intended – could be the option to provide a list of group entities to the expand dictionary key, too. Or combine groups with non-grouped entities:

trigger:
  - platform: state
    entity_id: 
      expand:
        - group.binary_sensors
        - group.some_more_binary_sensors
      entities:
        - binary_sensor.an_additional_sensor
    to: ~

It might also be worth considering changing how entities for conditions and triggers are provided in general, similarly how this was changed relatively recently for service calls with the target dictionary key. Maybe instead of “amending” the entity_id key a new key should be added that provides the new functionality:

trigger:
  - platform: state
    observe: 
      group:
        - group.binary_sensors
        - group.some_more_binary_sensors
      entity_id:
        - binary_sensor.an_additional_sensor
    to: ~

I used “observe” here over “target” since I don’t feel “target” is a good semantic match for triggers.

2
3

If you use expand in a template sensor it will do what you want.

4

Thanks for your response. I am aware that you can use expand in a template sensor. I think this is missing the point though. The feature request here is to be able to “expand” groups for the entity_id key on triggers and conditions.

For example, if you want to trigger an automation when any of the entities in a group changes you cannot do that without having to jump through hoops, like for example creating a template sensor that determines and renders the entity_id of the most recently changed entity in a group.

The feature here is to be able to be able to skip this workaround and having the ability to “expand” groups directly in place of the trigger / condition.

5

For completeness sake, the best way I was able to come up with to do “any entity of a group of binary_sensors changes state” trigger is – as @parautenbach mentioned above – to use a template sensor using expand. I then create a “bitmask” containing a bit for each entity in the binary_group resulting in a unique state depending on each members state. To more easily reuse this across multiple groups I created a custom macro stored in custom_templates/core.jinja

{% macro binary_group_bitmask(group) -%}
  {%- set states = expand(group)|map(attribute='state')|list -%}
  {%- set ns = namespace(sum=0) -%}
  {%- for i in range(0, states|count) -%}
    {%- set ns.sum = ns.sum + (2**i if states[i] == 'on' else 0) -%}
    {# Enable following line for debugging #}
    {# {{states[i]}}={{2**i}} ({{ns.sum}}) #}
  {%- endfor -%}
  {{- ns.sum -}}
{%- endmacro %}

You then create a template sensor for each of the (binary sensor) groups you want to track:

template:
  sensor: 
    - name: Binary Sensors Bitmask
      state: >
        {% from 'core.jinja' import binary_group_bitmask %}
        {{ binary_group_bitmask('group.binary_sensors') }}

Lastly, you can trigger off of state changes of the bitmask sensor:

trigger:
  - platform: state
    entity_id: sensor.binary_sensors_bitmask
    to: ~

This approach works for this specific use-case but has several drawbacks compared to the suggested feature.

  1. It is significantly more verbose to setup and use.
  2. It requires understanding of Jinja templates as well as how binary works and is not approachable for people unfamiliar with those topics.
  3. It only works for binary_sensors. If there was a hashing function available in templates one could make it work for other sensors, too. But there isn’t.
  4. It only works for any state changes. It does not work for triggers using to or from or for, at least not with additional helper sensors*.

[*] A drop in the value of the binary mask can be interpreted as a to: 'off' and an increase in the value of the binary mask can be interpreted as a to: 'on'. However, since there is no decrease_by and increase_by numeric_state trigger, only above and below one requires additional helper template sensors to track if the bitmask sensor increased or decreased in value.

1 Like
11

Best option seems to be switching to Node Red which already have the feature.

15

Sounds like you are talking about paid software products.
This is free, so user demand is less important.

In anyway, the developers core vision will override user demand in any case.