How are you Automation & Notifying on groups of entities - when one changes?

Configuration
,
1

I’m not finding a way to make this easy…

In my old systems (vera, Homeseer, etc) it was super simple, super fast, all UI based. What am I missing in HA that I cant figure out how to make this easy using groups or labels?

  1. Place all your ‘like’ devices in a group (Interior Motion Sensors, Exterior Motion Sensors, Windows, Doors, Smoke Detectors, Leak Detectors, etc)

  2. Create an automation which…

  • Triggers on ANY change, to ANY device within the group ** eg, not just when the group itself changes on/off
  • Sends mobile notification with message… ~device that changed~ ~new state~

Groups (which used in all other systems makes this a cake walk) but seems like that is not the case in HA?

thx for the help

3

Yeah, I’m finding out that there are more gaps in HA’s built-in automations capabilities than expected. Many automations are overly difficult, tedious and in-efficient for even mid size systems IMO…

Example:

Say you have 28 window and door sensors (these are just my parameter openings). One automation needs 28 separate triggers… vs 1 Group?

Then if you change a sensor (it dies, you change brands or protocols, etc) you need to go change ALL your automations manually.

I have multiple automations that use devices like motion, doors, windows, etc… and instead of simply changing it in 1 place, I may need to change it in 10 or 20 places.

Even Labels dont help.

4

You need 1 trigger with 28 entities.

If you use entity-focused triggers/conditions/actions, you just reuse the old entity ID for the new sensor.

https://community.home-assistant.io/t/why-and-how-to-avoid-device-ids-in-automations-and-scripts/605517/36

6

Just pointing out that many HA automations (and management methods) are greatly enhanced with the proper use of Groups, which cannot be done in HA today.

Thus that gap creates some large inefficiencies.

I put in a feature request for Groups a few days ago. I hope the devs realize what a massive gap HA has without proper implementation (as it is now).

I was hoping there was a work around but maybe there is not

7

Groups are not meant to be an especially powerful feature in HA. What an analogous feature might be used for on other platforms doesn’t bear on what role groups are intended to play on a well configured HA platform.

It isn’t really clear what specifically you want to do, so it’s hard to point you in the right direction.

For example, if you care about not having to update a list of, say, motion sensors, in multiple automations, create one automation with triggers for the motion sensors and in that automation call out to various scripts that you want to happen when something on that trigger list fires.

8

you are saying since Groups literally only do 1 thing (on / off) so they were purposefully ‘meant’ to be nearly useless? :wink:

It is totally proper to make an analogy to other systems, kinda the whole point making a system, people are trying to be better that the existing systems and thus, features/capabilities need to be the same, at minimum. In this case there is nothing, at all (baring a ton of manual coding), that can do what Group are made to do in every other system I’ve used.

Groups need this… Make Groups Useful - they lack near everything needed

Your method, while it may work is not something a new HA person can easily do… and I’d bet its not even easy for an experience person. If it was, there would be that code flying around.
Its also not great to have multiple automations/scripts just for one small outcome like ‘tell me what device changed’
more automations = more processing, more manual management (change/updates/etc), and more points of failure.

HA has multiple ways to do many things… this is a double edged sword since, as you pointed out, you many need multiple things to do something simple given the limitations they all seem to have.

Lets combine scripts, automations, scenes, etc, etc… and we have to learn multiple different ways to do stuff since and how to combine them in just the right way to make something simple (like querying entities in a group and getting values)
“create helper entities, build a script, call it from an, dip it in mustard then add the raw YAML code template – simple!” :wink:

1 Like
9

I agree there is a gap currently with the inability to properly use group’s entities, or label entities, to trigger automations. This was attempted to be addressed previously but the PR was rejected.

One workaround is to create a template sensor that updates whenever something in the group changes. You could create a template sensor and use this as the state: {{ state_attr('group.my_group', 'entity_id') | expand | map(attribute='last_changed') | list | last }}

You could also create an attribute for that sensor (if you define it in YAML) that is a list of all the entities in that group, ordered by which one changed most recently.

Then you’d have an automation that is triggered whenever this template sensor changes. And you can use templates to pull out the last changed entity from the attributes (using the trigger variable).

Q+A time!
Is this complicated? Yes.
Will most HA users know how to do this? No.
Is an improvement coming soon to fix this? Don’t hold your breath.

1 Like
11

@mekaneck I also came to that conclusion that a trigger sensor is the answer. I cant find really good examples/docs on how to create/use them and the ones I have I’m not sure are working as they should. Some examples I found and using but I’m not 100% up to speed on how to mod to make them work. I’m still trying to get my head around Templates… the ‘language’ is not like JS or VB/S

Ideally we’d be storing values into variables we could act upon, for each Entity in the Group…

  • Name — %group.groupname_entityname_name%
  • State — %group.groupname_entityname_state%
  • Last_Change — %group.groupname_entityname_last_change%

This one is working. Creates a Logbook.

  - trigger:
    - platform: event
      event_type: zwave_js_notification
      event_data:
        device_id: lock.front_entry_deadbolt
        label: Access Control
    sensor:
      - name: "Front Door Lock Event"
        state: "{{now() | as_local }}"
        unique_id: front_door_lock_event
        attributes:
          log: >
            {% set log = this.attributes.get('log', []) %}
            {% set new = [{
               "event": trigger.event.data.event_label,
               "user": trigger.event.data.parameters.userId,
               "time": (trigger.event.time_fired | as_local).isoformat() }] %}
            {{ (new + log)[:30] }}

This one is not working for me, its not creating the sensor.unavailable_entities entity at all…


  - trigger:
    - platform: time_pattern
      minutes: "/1"
      event_data:
        device_id: sensor.unavailable_entities
    sensor:
    - name: Unavailable Entities
      icon: mdi:help-circle-outline
      state: "{{ states | selectattr('state', 'in', ['unavailable', 'unknown', 'none']) | rejectattr('domain', '==', 'button')  | rejectattr('entity_id', 'search', '_device_temperature$') | rejectattr('domain', 'in', ['device_tracker', 'person']) | rejectattr('entity_id', 'search', '_charger_type$') | map(attribute='entity_id') | reject('==', 'sensor.unavailable_entities') | list | length }}"
      unit_of_measurement: entities
      state_class: measurement
      attributes:
        unavailable:            "{{ states | selectattr('state', 'in', ['unavailable']) | rejectattr('domain', '==', 'button')  | rejectattr('entity_id', 'search', '_device_temperature$') | rejectattr('domain', 'in', ['device_tracker', 'person']) | rejectattr('entity_id', 'search', '_charger_type$') | map(attribute='entity_id') | reject('==', 'sensor.unavailable_entities') | list }}"
        unknown:                    "{{ states | selectattr('state', 'in', ['unknown']) | rejectattr('domain', '==', 'button')  | rejectattr('entity_id', 'search', '_device_temperature$') | rejectattr('domain', 'in', ['device_tracker', 'person']) | rejectattr('entity_id', 'search', '_charger_type$') | map(attribute='entity_id') | reject('==', 'sensor.unavailable_entities') | list }}"
        none:                          "{{ states | selectattr('state', 'in', ['none']) | rejectattr('domain', '==', 'button')  | rejectattr('entity_id', 'search', '_device_temperature$') | rejectattr('domain', 'in', ['device_tracker', 'person']) | rejectattr('entity_id', 'search', '_charger_type$') | map(attribute='entity_id') | reject('==', 'sensor.unavailable_entities') | list }}"
13

the docs are not clear, at all (Automation Trigger - Home Assistant)

what is the correct way to have the data inserted into an entity for use?

  - action: sensor.unavailable_entities
    target:
      entity_id: sensor.unavailable_entities
15

“use the Automation Editor” “but for this you cant”
… I know how to use the Editor and export YAML but as you said… not relevant here.

“There’s no action designed to “insert” an entity’s configuration.”
… maybe the word ‘insert’ is wrong but the Logbook Template I posted above works 100% and is doing almost exactly what I want to do.

I need the Template to pull data from a Group and populate a Unique_ID (still looks like it shows up an Helper Entity!?)

If you know how to solve this please LMK exactly how. Working code would be far better than pointing to docs that doesnt help me learn how to fish, it just seem to get me tangled in the fishing line.

Template Goal:

  1. Trigger on any change to a given Group
  2. Pull in this data into attributes that can be used (without needing YAML) by a dashboard card, a notification, or Automation
  • Name
  • State
  • Last_Change