- 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.
- 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.
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.
@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:
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?
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.
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.
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.
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.
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!!
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.)