Automation data_template: how to return the friendly name of group entity that changed state

Configuration
1

I have a couple of zwave door sensors defined in a group (more on their way!):

door_sensors:
  icon: mdi:door
  entities:
    - binary_sensor.kaipule_technology_co_ltd_im20_door_window_sensor_sensor
    - binary_sensor.kaipule_technology_co_ltd_im20_door_window_sensor_sensor_2

In automations I watch for the state of that group to change to ‘on’ and then send a notification:

- id: '12345'
  alias: Door Opened
  trigger:
  - entity_id: group.door_sensors
    platform: state
    to: 'on'
  condition: []
  action:
  - data_template:
      message: '{{ trigger.to_state.attributes.friendly_name }}'
    service: notify.notify_me

However for the life of me I can’t figure out how to get at the friendly name of the entity that caused the group to change state (i.e. the door that opened). The best I’ve managed to achieve is the name of the group (‘door_sensors’ in this case).

I have assigned each sensor a friendly name under dev tools > states as the binary_sensor names aren’t useful especially with numerous sensors of the same type.

All the other examples on this forum have the entities to watch listed in the automation itself. I don’t really want to have to do that as I have a number of other door sensors on their way and use the ‘door_sensors’ group for other things such as cards on the UI (I only want to have to list the sensors in one place).

Is the friendly name of an entity from a group accessible to a date_template, or do I have to bite the bullet and list all the sensors right in the automation? This would make groups a bit useless if so.

2

The friendly name is available from the state machine. The problem is that you won’t know which one just changed. The easiest option is to list out all the sensors with their own trigger. Otherwise you’ll have to iterate through all the doors, look at the last_changed, link that last_changed to the friendly name and pull the friendly name. All in jinja. It’s possible, but it’s not easy and probably not worth the effort when you can just list them in your trigger.

1 Like
3

ok thanks, I feared that would be the answer. To make groups more useful it would be great if they had a property called ‘last_changed’ or something, some way to make groups and friendly names more accessible.

I had hoped to list all the sensors just in one place (in a group) and then re-use that group for the UI, automations etc but seems that duplication of lists is unavoidable.

4

The way you have the automation at the moment, the group is triggering the automation, so the trigger.to_state.attributes.friendly_name will always result in the friendly name of the group.

If you change the automation to list each of the door sensors themselves, when a sensor triggers the automation, trigger.to_state.attributes.friendly_name will resolve to the friendly name of the entity that triggered the automation.

So it should look like:-

- id: '12345'
  alias: Door Opened
  trigger:
  - entity_id: sensor.door_sensor1
    platform: state
    to: 'on'
  - entity_id: sensor.door_sensor2
    platform: state
    to: 'on'
  - entity_id: sensor.door_sensor3
    platform: state
    to: 'on'
  condition: []
  action:
  - data_template:
      message: '{{ trigger.to_state.attributes.friendly_name }}'
    service: notify.notify_me

You can still use the door sensors group to view all the sensors in one spot in the UI, but change your automation so that it lists each entity that could trigger the automation.

5

Thanks, yes that works I was just hoping that groups would be more useful than they are right now.

May have a look at github and see if I can suggest any improvements when I get a chance.

6

You probably already know this but you will only receive a notification the first time a sensor activates. Any additional doors or windows that open afterwards will not be reported.

That’s because you are monitoring the state of a group. The first member of a group to turn on will set the group to on and the group will remain on until all its members turn off.

7

yes I did realise that, but thanks for responding anyway.

I’m now watching the individual entities so I can pass through a friendly name to the notification, so any additional doors that now open will also trigger the automation.

So I guess there is at least one benefit to doing it this way :slightly_smiling_face:

8

Here’s one more thing you probably already know :slight_smile: you can condense multiple entities in the trigger like this:

  trigger:
  - platform: state
    entity_id:
    - binary_sensor.kaipule_technology_co_ltd_im20_door_window_sensor_sensor
    - binary_sensor.kaipule_technology_co_ltd_im20_door_window_sensor_sensor_2
    to: 'on'
1 Like
9

I think there is a bug with this currently that hasn’t been implemented yet. It may not affect this type of automation though. I can’t remember if the bug was due to delay in the action or for in the trigger.

10

I may be wrong but I think the bug was when for: is used with multiple entities (I’ll try to find the relevant post).

FWIW, I tested multiple entities with on: (as shown above) and that works OK.

Found it. It’s when the trigger uses for and either to or from.