Why is this not triggering?

Configuration
1 
- alias: Door alert
  trigger:
  - platform: state
    entity_id: input_select.security_system
  - platform: state
    entity_id: binary_sensor.doors_unlocked
    to: 'on'
  condition:
  - condition: state
    entity_id: input_select.security_system
    state: 'Armed (Away)'
  - condition: state
    entity_id: binary_sensor.doors_unlocked
    state: 'on'
  action:
  - service: notify.pushbullet_notifications
    data_template:
      message: >
          {% set unlocked = states | selectattr('entity_id', 'in', state_attr('lock.all_locks','entity_id')) | selectattr('state','eq','unlocked') | map(attribute='name') | join(', ') %}
          The following locks are unlocked: {{ unlocked }}
      target:
      - !secret pauls_secret_email
      - !secret tracys_secret_email
     title: Doors left unlocked

binary_sensor.doors_unlocked is definitely on, and Iā€™m changing the input select to and from armed (away). Is it way that input select works? Can it be a trigger? Iā€™ve only used it as a condition before. But even so the input boolean should also trigger and it does not even when the conditions seem to be met. Iā€™m not seeing any errors in the log, just never triggers.

2

I think you can get rid of these conditions like:

- alias: Door alert
  trigger:
    platform: template
    value_template: >
      {{ is_state('input_select.security_system', 'Armed (Away)') and is_state('binary_sensor.doors_unlocked', 'on') }}
  action:
  - service: notify.pushbullet_notifications
    data_template:
      message: >
          {% set unlocked = states | selectattr('entity_id', 'in', state_attr('lock.all_locks','entity_id')) | selectattr('state','eq','unlocked') | map(attribute='name') | join(', ') %}
          The following locks are unlocked: {{ unlocked }}
      target:
      - !secret pauls_secret_email
      - !secret tracys_secret_email
     title: Doors left unlocked

I havenā€™t tested it, but this way you can paste {{ is_state('input_select.security_system', 'Armed (Away)') and is_state('binary_sensor.doors_unlocked', 'on') }} into dev-template/ and see what happens.

4

I have to agree with @letsoulfly here. The two individual triggers donā€™t matter if both conditions arenā€™t met. So might as well trigger when both conditions are met, which is what the suggestion would do. The template will be evaluated whenever either entity changes state, so itā€™s effectively equivalent to the two triggers plus the two conditions. At least I think so. :thinking:

@ptdalen, Iā€™m wondering about this in your message template:

states | selectattr('entity_id', 'in', state_attr('lock.all_locks','entity_id'))

First, is there really a lock.all_locks entity? Or is it group.all_locks? And if this is an automatically maintained group of all locks, then donā€™t you really want:

states.lock

That already would limit to only states of locks.

5

That looks interesting, and like it should work, so I had two triggers because, I wanted to get alerted if the doors became unlocked (the input boolean to on) while I was away, but also wanted to get alerted if the I left and the system armed but the doors were unlocked (more likely). I have a few other automations with multiple triggers and conditions. I guess my question is - Is there something wrong with the triggers and conditions that is keeping it from firing? I do like what youā€™ve done though, and will probably try it out, but also want to understand why mine does not trigger.

@pnbruckner - Iā€™ll check, but even it was bad, Iā€™d expect it to just send a message
" The following locks are unlocked: ", right?

6

All exampleā€™s Iā€™ve seen have lock.all_locks. Itā€™s always seemed odd to me because I would expect it to be a group (I donā€™t own any locks). However, light groups behave differently than groups and they are inside the light domain. It is possible that lock groups exist as well.

7

Looking at my at my automations I use

 - service: lock.lock
   entity_id: group.all_locks

and it works, so Iā€™ll change it, And I donā€™t have an entity for locks.all_locks
but would that cause it not to trigger?

8

not sure, it looks correct. Only thing i could say is "Can you verify that the state is actually ā€œArmed (Away)ā€ or is it just Armed.

9

Donā€™t know. But thereā€™s one easy way to find out - manually trigger the automation and see what happens. It doesnā€™t depend on the dynamic trigger variable, so you should be able to do this.

10

might this not be the fact that you check the groupā€™s state and attributes of that group. Only triggers when the group changes state.
Had this same template before for my lights, or people home, same thing happening.

11

No, I donā€™t think so, but it might trigger and then the action fails. But then youā€™d expect to see an error.

12

Good call. Manually triggering the automation also fails. Iā€™ll try changing the template to group.all_locks, when I get home and see if thats the cause. would be weird, but who knows. :slight_smile:

13

Weirdly enough, changing the template to group.all_locks seems to have fixed it. Only thing thatā€™s weird is that if only one lock is locked group.all_locks reports a status of ā€œlockedā€. I understand thatā€™s how groups work, but I saw someone else mention that itā€™s a recent change thats counterintutive.

But it does not affect this automation, because the binary sensor queries the locks individually to be on or off.

Also weird that the automation did not work with lock.all_locks. Anyway, good to go now, thanks!!

14

Glad itā€™s working! But I still think you donā€™t even need the group. (See my previous suggestion for removing that first part and replacing it with states.locks.)

1 Like
15

So this?

states | selectattr('entity_id', 'in', state_attr('states.locks','entity_id'))

or this

{% set unlocked = states.locks | selectattr('state','eq','unlocked') | map(attribute='name') | join(', ') %}
16 
{% set unlocked = states.lock | selectattr('state','eq','unlocked') | map(attribute='name') | join(', ') %}

EDIT: Assuming, of course, the domain of all the locks is lock. And assuming group.all_locks is really all lock entities.