I just wanted to let you know that everything is working great! I am very happy and have learned a great deal from you!!
When you have time, can you show me how to do the above, just for my knowledge, in case I want to use the concept in the future. I would like to try it for the doors to take them from state reporting of “on” and “off” to state reporting of “open” and “closed” with “closed” being off.
Thank you for showing me how these things are done @pedolsky
Sure! I’ll get back to you later.
Thank you so much!!
That was a bit trickier than I thought. I wanted to cover the case that a ( second ) door was opened while no one was at home.
The problem here is the automation trigger. With the state trigger group.family to not_home it is easy. In that case it is enough to say condition = sensor state > 0. A template trigger behaves differently.
For a template trigger, we need a ‘trigger condition’ that must be true. A condition would be e.g. states.binary_sensory | count > 0.
But if a door is already open, the automation can no longer be triggered because we are already above 0; the state can no longer change to ‘above 0’.
states.binary_sensory computes a group of corresponding entities. We want to access the state change of each item.
Having said this, I have created the following example template sensor, which contains a whole set of attributes. The important attributes are count and last_id. The others are gimmicks / extended info.
Template sensor:
template:
- sensor:
- unique_id: doors_windows
name: Doors and Windows
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:door-sliding' if e == 0 else 'mdi:door-sliding-open' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'all closed' }}
attributes:
open: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|list
|count }}
ids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
last: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='name')
|list
}}
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
path: '/packages/0_sensoren/tueren_fenster.yaml'
For this have a look here: https://www.home-assistant.io/docs/automation/templating/#available-this-data
Automation:
alias: Doors/Windows Warning
mode: single
max_exceeded: silent
trigger:
- platform: state
entity_id: sensor.doors_and_windows
condition:
- condition: template
value_template: |
{{ trigger.to_state.attributes.last_id != '' }}
action:
- service: notify.persistent_notification
data:
message: |
{% set b = trigger.to_state.attributes.last_id %}
The {{ state_attr(b, 'friendly_name') }} has been opened!
cross-check: {{ b }}
time: {{ now().strftime('%d/%m/%Y, %H:%M:%S') }}
title: Doors/Windows Warning!
What does
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
do?
# Ensure that the entity has the attribute device class (otherwise an error is thrown)
|selectattr('attributes.device_class', 'defined')
# In case the device class is changed later via customize.yaml, or to cover multiple device classes
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
# Only take active sensors into account
|selectattr('state', 'eq', 'on')
# Show the state changes in reversed order
|sort(attribute='last_changed', reverse=true
# Only show one item of the last changed list
[0:1]
# After all of that, show the corresponding id
# Ensure that this entity id can be read properly in the automation ( means without [' '])
|join
So I never thought about this. So, just to make sure I understand. Does this mean that the automation below will only run on the first open door with no one home? Or does this run only at the exact moment that the family group goes from home to not home?-- As in, let’s say I haven’t been home for 2 hours and someone opens the house door. Would it trigger the notification with the automation below?
I haven’t had a chance to read and understand everything that you were teaching me just yet but wanted to throw the quick question out above first.
Thank you @pedolsky!!
alias: >-
(ACTION- AUTOMATIC- SECURITY- GEOLOCATION- NOTIFICATION) Door Opened When Away
(Choose)
description: ''
trigger:
- platform: state
entity_id:
- group.family
from: home
to: not_home
condition:
- condition: template
value_template: '{{ open |count > 0 }}'
action:
- service: notify.notify
data:
message: >
The following have been left open with no one home: {{ open |join('\n-
') }}. Maybe it's time for you to turn around and go back to close the
door.
title: SECURITY
mode: single
max_exceeded: silent
variables:
doors: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list
}}
open: |
{{ expand( (doors) )
|map(attribute='name')
|list }}
Ok, now I have had a chance to read all of this and wanted to ask a few questions to make sure I understand it all. Take your time anytime you are helping me, I am in no hurry. I am just very appreciative of you taking time to help me with some of the more important things that will make me feel comfortable with home assistant (door locks, door openings, and leak sensors)
I understand so much now that I have seen this example!
So the first question I have is: Will the automation essentially send a notification each time a door is opened with no one home? (now that we have all of the template sensors created)—> based on the trigger being “last_id”, I think it will because “last_id” will each time a new door is opened with no one home. This is great!
Ok, why do you use “list” in this one but “join” in the next one ( and in general, outside of this example, how do you know when to use each?)
last: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='name')
|list
}}
join:
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
And the last question is: What is the purpose of the below in the automation.
cross-check: {{ b }}
Thank you so much for spending the time to show me this example. I understand so much of how all of this works now!
Vorformatierter Text``Vorformatierter Text[quote=“wtstreetglow, post:25, topic:426484”]
Or does this run only at the exact moment that the family group goes from home to not home?
[/quote]
Correct. This automation merely warns you if all have left your home and a door is still open. But your thinking was to create 3 separate automations, so I didn’t took it into account.
The second automation triggers each time a door or window has been opened ( state changed to on). Add a second condition
- condition: state
entity_id: group.family
state: not_home
to receive messages only if you’re not at home. But this also won’t cover the case, someone forgot to close a door when leaving home.
You can extend your first automation by using multiple triggers:
trigger:
- platform: state
entity_id:
- group.family
from: home
to: not_home
- platform: state
entity_id:
- binary_sensor.a
- binary_sensor.b
- binary_sensor.c
from: 'off'
to: 'on'
Instead of listing all the binary sensors, you can use a template trigger or create a template sensor as in the example above.
list outputs a list, while join outputs a string.
Output list: ['binary_sensor.a]
Output join: binary_sensor.a
The filter join ensures that this entity id can be read properly in the automation ( means without [’ '].
The attribute ‘last’ and the cross-check were for illustrative purposes only.
I understand. No, that’s no problem. I follow you. I think the simplest thing on all of these would have been to do them all individually but I would prefer to learn how to do it the right way or may “more efficient” way is the best way to say that.
I follow you. I have now done that.
Ok, so I will need a total of 2 automations for open doors? 1 that checks for open doors that exist as the family goes into “not_home” and the second one that we are discussing now, is for if a door is opened and the family is already in the “not_home” state? Thank you, I believe I am following you now.
Ok, so I will add this concept to the automation so that I will have a check to see if we had any open doors before we get too far away from home. Thank you for your help with all of this. You are making it very understandable.
I understand all of this now. Thank you @pedolsky
I may post a few of the finished packages/ automations in this thread in the next few days and I would be very thankful if you could look at them for a minute or 2 just in case you could catch any issues. I trust your eye better than mine until I get some more experience and these scare me a bit more because these automations are all for the important stuff (doors/ leak sensors/ locks) and I don’t want to screw them up. I don’t think I will have more than 3-4 automations. Thank you for everything you have taught me. Now I will try a few own my own and see what happens!! Very appreciative!!
What is the best way to test these automations to see if they are working correctly while sitting at home? For instance, I think I have built the automation correctly but how do I test it rather than leaving my home zone to see if everything functions correctly?
First one is a leak package and automation. The goal is nearly identical as your door package you built for me. To tell me when a leak sensor is triggered (at all times regardless of geolocation). I took your door package/ automation and modified it.
Package:
template:
- sensor:
- unique_id: water_leaks
name: Water
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:water' if e == 0 else 'mdi:water-alert' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'no water leaks' }}
attributes:
leak: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|list
|count }}
ids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
last: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='name')
|list
}}
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
Automation:
automation:
- alias: (ACTION- AUTOMATIC- SECURITY- NOTIFICATION) Leak
description: ''
trigger:
- platform: state
entity_id: sensor.water_leaks
attribute: last_id
condition:
- condition: template
value_template: |
{{ trigger.to_state.attributes.last_id != '' }}
action:
- service: notify.persistent_notification
data:
message: |
{% set b = trigger.to_state.attributes.last_id %}
The {{ state_attr(b, 'friendly_name') }} has detected a leak!
cross-check: {{ b }}
time: {{ now().strftime('%d/%m/%Y, %H:%M:%S') }}
- service: notify.notify
data:
title: LEAK
message: |
{% set b = trigger.to_state.attributes.last_id %}
The {{ state_attr(b, 'friendly_name') }} has detected a leak!
mode: single
max_exceeded: silent
@pedolsky I thought I knew what I was doing now but I sat down to try another and feel stuck.
I am trying to write 3 more automations that involve doors and then I believe I am done. Can you give me a little guidance on how I would do the following 3 automations (in a similar way as we have done in the past-- possibly using our already setup package if it’s possible or by just adding additional “helpers” to that package–> I think I’m starting to understand things, but I’m learning, I am not there yet). I have repasted the package you came up with below so that you don’t have to look up to see what actually ended up getting implemented as we have done a good amount of conversation.
Here is the package that is currently implemented:
template:
- sensor:
- unique_id: doors_windows
name: Doors and Windows
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:door-sliding' if e == 0 else 'mdi:door-sliding-open' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'all closed' }}
attributes:
jammed: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['problem'])
|selectattr('entity_id', 'search', 'lock')
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
jammedids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['problem'])
|selectattr('entity_id', 'search', 'lock')
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
unlocked: |
{{ states.lock
|selectattr('state', 'eq', 'unlocked')
|rejectattr('entity_id', 'search', 'boltchecked_')
|map(attribute='name')
|join(' | ') }}
unlockedids: |
{{ states.lock
|rejectattr('entity_id', 'search', 'boltchecked_')
|selectattr('state', 'eq', 'unlocked')
|map(attribute='entity_id')
|list }}
locked: |
{{ states.lock
|rejectattr('entity_id', 'search', 'boltchecked_')
|selectattr('state', 'eq', 'locked')
|map(attribute='name')
|join(' | ') }}
lockedids: |
{{ states.lock
|rejectattr('entity_id', 'search', 'boltchecked_')
|selectattr('state', 'eq', 'locked')
|map(attribute='entity_id')
|list }}
open: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
closed: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|list
|count }}
ids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
closedids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
last: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='name')
|list
}}
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
1.) All doors that are closed, lock at 10 pm. A message gets sent out to the phones at 10 pm with the doors that were open and as such, didn’t get locked. Here is my attempt at this one but I don’t know how to take care of locking the unlocked doors in the automation. My goal would be to not specify the doors individually but to do it through the package we created somehow.(I added an attribute to the doors&windows template sensor we made for the “join” of the “name” (named “closed”) of the closed doors and the “list” of “entity id” (named “closedids”) for the closed doors and we had already created those for the open doors and called them “open” and “ids” respectively.
alias: (ACTION- AUTOMATIC- SECURITY) Doors Lock at Night
description: ''
trigger:
- platform: time
at: '22:00:00'
condition:
action:
- service: notify.mobile_app_weston
data:
message: >
The following doors are open: {{ open |join('\n-
') }}. These doors could not be locked by automation. All other doors have been locked.
title: SECURITY
mode: single
max_exceeded: silent
variables:
doors: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list
}}
open: |
{{ expand( (doors) )
|map(attribute='name')
|list }}
2.) All doors that are closed lock when the family goes from “home” to “not_home” and a message is sent out to the phones about any doors that we’re left open and not locked as the family group goes from “home” to “not_home”—> This is following up from our conversation at communication #26-#27 (I never did figure out how to do it)
I tried the below and I think it is working correctly. Will you review it and see if you think there are any issues? One thing I kind of don’t like about the below is written is the hardcoding of the door names into the automation (in the triggers). Is there a way to use our template sensor/ door package to stop from hardcoding the trigger entity ids that? Can you show me how to make that fix? (So that in the future if another exterior door were added to the system, it would automatically get included in this automation.)
alias: >-
(ACTION- AUTOMATIC- SECURITY- GEOLOCATION- NOTIFICATION) Door Open at Home on
Away Status Change
description: ''
trigger:
- platform: state
entity_id:
- group.family
from: home
to: not_home
- platform: state
entity_id:
- binary_sensor.front_door
- binary_sensor.back_door
- binary_sensor.garage_entry_door
from: 'off'
to: 'on'
condition:
- condition: template
value_template: '{{ open |count > 0 }}'
- condition: state
entity_id: group.family
state: not_home
action:
- service: notify.notify
data:
message: >
The following have been left open with no one home: {{ open |join('\n-
') }}. Maybe it's time for you to turn around and go back to close the
door.
title: SECURITY
mode: single
max_exceeded: silent
variables:
doors: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list
}}
open: |
{{ expand( (doors) )
|map(attribute='name')
|list }}
3.) A notification telling me if/ when a lock jammed (when it goes to the “jammed” state)
I added a “jammed” and “jammedids” to the template sensor above but now I don’t really know what to do with it/ how to use it to help in the automation or if I need more of these in different flavors. I just figured, I probably needed it.
I am going to keep trying to get them working myself but things aren’t going well so far.
First:
I played around with my first proposal for a while and I don’t like the results. Here now is the revised version (for testing still without the condition that nobody is at home):
# Template Sensor
template:
- sensor:
- unique_id: doors_bs
name: 'Doors (Binary Sensors)'
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:door-sliding-open' if e != 0 else 'mdi:door-sliding' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'all closed' }}
attributes:
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'eq', 'door')
|selectattr('state', 'eq', 'on')
|list
|count }}
last: |
{%- set on = states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'eq', 'door')
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list %}
{%- set last = expand(on)
|sort(reverse=true, attribute='last_changed') %}
{{ 'no' if last|count == 0 else last[0].entity_id }}
#-------------------------------------------#
# Automation
automation:
- id: doors_bs
alias: Doors (Binary Sensors)
mode: single
max_exceeded: silent
trigger:
- platform: state
entity_id:
- sensor.doors_binary_sensors
not_from: unknown
not_to:
- all closed
- unavailable
- unknown
condition:
- |
{% set last = trigger.to_state.attributes.last %}
{{ last != 'no' and
trigger.to_state.state != trigger.from_state.state }}
action:
- service: notify.persistent_notification
data:
message: |
{% set last = trigger.to_state.attributes.last %}
Open: {{ state_attr(last, 'friendly_name') if last != 'no' else
'ERROR' }}
since: {{ (states[last].last_changed) |string |as_timestamp |timestamp_custom('%d/%m/%Y, %H:%M:%S', now() ) }}
title: |
DOOR WARNING! {{ now().strftime('%d/%m/%Y, %H:%M:%S') }}
You can simulate state changes by setting a fake state under Developer Tools —> States
Regarding to your automations 1 and 2:
Simply add another variable states.binary_sensor and combine the messages into one (based on this automation), e. g. (untested!):
id: '1652196340033'
alias: (ACTION- AUTOMATIC- SECURITY- GEOLOCATION) Door Lock When Away
mode: single
max_exceeded: silent
trigger:
- platform: time
at: 22:00:00
condition:
- condition: template
value_template: '{{ open |count > 0 }}'
action:
- service: lock.lock
data: {}
target:
entity_id: '{{ doors }}'
- service: cover.close_cover
data: {}
target:
entity_id: '{{ covers }}'
- service: notify.mobile_app_weston
data:
message: >
{{ open |join(', ') }} left open and has been closed by
automation. {{ binary |map(attribute='name') |join }} is open and cannot closed via automation.
title: Door Open with no one home
variables:
doors: |
{{ states.lock
|selectattr('state', 'eq', 'unlocked')
|map(attribute='entity_id')
|list }}
covers: |
{{ states.cover
|selectattr('state', 'eq', 'open')
|map(attribute='entity_id')
|list }}
binary: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|list }}
open: |
{{ expand([covers, doors, binary])
|map(attribute='name')
|list }}
So the post above is a rewrite of a “any door opening” package and automation?-- I believe I follow. Sorry, just want to make sure I am using the correct terminology and it will replace the first attempt.
Ok. I have your last post implemented in my HA at the moment (code block 1- package and automation). One question I have is why did we go from
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
to
|selectattr('attributes.device_class', 'eq', 'door')?
Also, If my doors are contact sensors which are in device class “opening”. Do I need to change all of the “eq” “door” to “eq” opening?
Lastly, for the “unique_id”, you used “doors_bs” in the template sensor, but under the trigger for the automation “sensor.doors_binary_sensors” was used, should those be the same?
Also, it looks like we lost the following attribute in going to the new package? (“open”) Was it unuseful?
On the second code block in the last post. If the door is open, is there a way to keep it from sending the lock command to those doors? In an effort to keep the deadbolt from extending while it’s in the open position?
Can you send an action to a variable?
doorsclosed: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening'])
|selectattr('state', 'eq', 'off')
|map(attribute='entity_id')
|list
}}
Thank you for editing the earlier post like you did. You are making things easy to follow. I promise at the end of this. I am going to post everything we did so people after our conversation may learn from it.
Sorry, that is ‘my’ device class I’m using for contact binary sensors. Forgot to replace it.
If you are using only one device class, |selectattr('attributes.device_class', 'eq', 'yourdeviceclass') is enough.
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window']) represents a list of several device classes.
But |selectattr('attributes.device_class', 'in', ['opening']) will also work.
The unique_id has nothing to do with the sensor’s name. It’s for HA’s internal registry only.
Um, I’m afraid I’ve lost track. Where did we lost ‘open’? Or do you mean the template sensor?
On the second code block in the last post. If the door is open, is there a way to keep it from sending the lock command to those doors? In an effort to keep the deadbolt from extending while it’s in the open position?
Which one?
Can you send an action to a variable?
What do you want to achieve?
I understand this now.
Ok so where did we create this then (The sensor that is called out in the code snippet below)? This was the first time I’ve seen “sensor.doors_binary_sensors” used anywhere. Shouldn’t the unique id on the template match the sensor name that is being used in the automation? (So you used "doors_bs as the unique id of the sensor in the template so it should be the same in the entity id area of the automation trigger, in the code snippet in post 31, it’s showing “sensor.door_binary_sensors”–> Sorry if I’m confused wrongly.
trigger:
- platform: state
entity_id:
- sensor.doors_binary_sensors
Yeah, on the original template sensor, we had an attribute called open. It is pasted below. Is it not useful anymore? I think we’ve been calling some of the variables in the automations “open” and we called an attribute in the template sensor “open” orginally and it had me confused for a second.
This was in our original template sensor. Yeah, I’'m wandering, is that not really useful anymore?
open: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['opening', 'door', 'window'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
Essentially any of them. Let’s say my house has 3 doors. At 10 pm, 2 are closed. I would want those 2 to go ahead and lock. Then I would want HA to send me a notification about the 3rd door that is open but I don’t want home assistant to send the lock command to that open door because it would do no good since the door is open. Can this be done with the variable idea that I am going to talk about below? (In this instance, a variable to help me lock the doors that are closed and a variable that shows up in the notification with the “join” command to tell me about the doors that were in the open position and therefore there was no reason to send “lock” service to them)
Sorry, I realize now, you have taught me this concept, the below was in one of our previous examples You can do a variables section at the end of the automation and then call out the variables in the actions section with the curly brackets. Thank you for your help with all of this.
action:
- service: cover.close_cover
data: {}
target:
entity_id: '{{ covers }}'
This is the automation in totality. Do you see any issues with this one?–>If I have multiple garage doors, will this only fire the first time a garage door is open when I am not home or will it fire everytime like for the EDITED door package you built that you showed me how to build for my entry doors(not garage doors)? If I want the below to fire everytime a garage door is opened when I am not home, am I best to make a copy of the door template sensor you made for my entry doors and modify it to work for the “garage” class and the get a lighter and a match to burn the automation below? 
@pedolsky I am very thankful for you helping me with everything you have. I really do appreciate it.
alias: >-
(ACTION- AUTOMATIC- SECURITY- GEOLOCATION- NOTIFICATION) Garage Door Close
When Away
description: ''
trigger:
- platform: state
entity_id:
- group.family
from: home
to: not_home
condition:
- condition: template
value_template: '{{ open |count > 0 }}'
action:
- service: cover.close_cover
data: {}
target:
entity_id: '{{ covers }}'
- service: notify.mobile_app_weston
data:
message: >
The following have been left unlocked or open with no one home: {{ open
|join('\n- ') }} . They have been locked or closed by automation.
title: SECURITY
mode: single
max_exceeded: silent
variables:
covers: |
{{ states.cover
|selectattr('state', 'eq', 'opened')
|map(attribute='entity_id')
|list }}
open: |
{{ expand( (covers) )
|map(attribute='name')
|list }}
Ok, and I have a general question about everything we’ve done. If I can create variables in the automations to get entities into the variable (essentialy grouping them) in order to perform service actions on those groups at the time the automation runs. What is the purpose of the template sensor? How does it help us? I think you’ve taught me so much at this point, that I’m mixing things and getting a little confused. In our instance, with the package you built, is it helping us because we almost want like a history on a entity/ group of entities? So it will be the most helpful, on things that can change state over and over and with the way you did it with the package. It will report to us in real time?
Lastly, do you see any issues with how the below automation/ package was done. This was the one for the water sensors. I took your original package post (before the edit) and remade it into this. Do you see it failing or not reporting everyhting like it should? Or do you believe, I would be better off switching it over to the edited template sensor from earlier today also.
And I never really asked this until now but what was it that you didn’t like about the first attempt at the template sensor? Why do you like EDITED version better? Thank you for making everything so clear.
template:
- sensor:
- unique_id: water_leaks
name: Water
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:water' if e == 0 else 'mdi:water-alert' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'no water leaks' }}
attributes:
leak: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|map(attribute='name')
|join(' | ') }}
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|list
|count }}
ids: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list }}
last: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='name')
|list
}}
last_id: |
{{ ( states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'in', ['moisture'])
|selectattr('state', 'eq', 'on')
|sort(attribute='last_changed', reverse=true) )
[0:1]
|map(attribute='entity_id')
|join
}}
automation:
- alias: (ACTION- AUTOMATIC- SECURITY- NOTIFICATION) Leak
description: ''
trigger:
- platform: state
entity_id: sensor.water_leaks
attribute: last_id
condition:
- condition: template
value_template: |
{{ trigger.to_state.attributes.last_id != '' }}
action:
- service: notify.persistent_notification
data:
message: |
{% set b = trigger.to_state.attributes.last_id %}
The {{ state_attr(b, 'friendly_name') }} has detected a leak!
cross-check: {{ b }}
time: {{ now().strftime('%d/%m/%Y, %H:%M:%S') }}
- service: notify.mobile_app_weston
data:
title: LEAK
message: |
{% set b = trigger.to_state.attributes.last_id %}
The {{ state_attr(b, 'friendly_name') }} has detected a leak!
mode: single
max_exceeded: silent
You can name the unique_id as you like, it can also be ‘123456789’. The entity_id follows the name of the sensor. Thus
- sensor:
- unique_id: doors_bs
name: 'Doors (Binary Sensors)'
matches sensor.doors_binary_sensors
on the original template sensor, we had an attribute called open.
I didn’t use it in the revised automation version but you can add as many attributes as you wish to your sensor.
Let’s say my house has 3 doors. At 10 pm, 2 are closed. I would want those 2 to go ahead and lock. Then I would want HA to send me a notification about the 3rd door that is open but I don’t want home assistant to send the lock command to that open door because it would do no good since the door is open. Can this be done with the variable idea
Basically, all cases can be covered with variables. If door unlocked can mean either open or closed, but those doors have an additional binary sensor, you can take it into account (but I haven’t the time this evening to test it).
What is the purpose of the template sensor?
You asked for it. 
I will have a look at your last two automations tomorrow.
Ok, I understand. You named them similarly so they were easier to keep track of but they don’t have to be identical.
I understand
How do you know when you need a template sensor? I don’t quite understand how you know when you can just use variables in the automation and stop there or when you have to go a step further and create a template sensor.
I would really appreciate it. Thank you again!
EDIT: *** And the last one I have is could you help me with an automation for a regular door (not cover/ garage door) that can take into account both the contact sensor on the door and the lock state on the door. If the door is open, I don’t want it to lock as there would be no reason to. If the door is closed, I would want it to lock. And lastly, I would want a message sent saying which doors were open and couldn’t be locked. I will use this in 2 instances, once at night before going to bed and anytime the family group goes to “not_home”
As explained here it will fired one time only.
variables:
covers: |
{{ states.cover
|selectattr(‘state’, ‘eq’, ‘opened’)
Wrong state, must be open.
How do you know when you need a template sensor? I don’t quite understand how you know when you can just use variables in the automation
You cannot use variables as automation trigger, yet. You can use templates instead, but such a template must repeatedly evaluated as true to send a message to you whenever a door has been opened, see the link a few lines above.
I went away from my proposal to trigger on an attribute because it triggered on all state changes what I overlooked.
that can take into account both the contact sensor on the door and the lock state on the door.
I don’t know for sure. You could try to compare the object_id (see here):
# Example: binary_sensor.entry_door_lock, lock.entry_door_lock
{% set bs = states.binary_sensor
|selectattr('object_id', 'match', 'entry_door_lock')
|selectattr('state', 'eq', 'on')
|map(attribute='object_id')
|list
%}
{% set l = states.lock
|selectattr('object_id', 'match', 'entry_door_lock')
|selectattr('state', 'eq', 'unlocked')
|map(attribute='object_id')
|list
%}
{{ bs == l }}
Unlike ‘search’, ‘match’ requires the entire string to match.
I understand
Thank you for catching this! It is working now.
I understand on both of these.
So this is the last one I would like to figure out:
Let’s say my house has 3 doors. At 10 pm, 2 are closed. I would want those 2 to go ahead and lock. Then I would want HA to send me a notification about the 3rd door that is open but I don’t want home assistant to send the lock command to that open door because it would do no good since the door is open.
I may post it in a new thread and see if others have ideas.
Thank you for your idea. I just know I’m nowhere near capable enough to build it myself. I am sadly not a programmer by trade. I’m an engineer, just not a programmer 
Not enough programming classes, I would’ve failed them all. haha
There are still things you have done that seem like magic to me because I don’t fully understand the syntax you have used on some of your solutions etc. They do all work though! and for that, thank you so much!! I am very appreciative. I’m sorry, it took so many post to get it all working but I am incredibly thankful for the time you spent helping me. I wish I could repay you somehow, even if it is small. Do you have a paypal/ “buy me a coffee” something that I could send you thanks to?
I will post the last one in a new thread and this weekend when I have a little more time. I will come back here and past each automation/ package we used/ created for people in the future. Hopefully new people to home assistant will be able to learn from it all.
For anyone coming to this thread in the future, the following is what @pedolsky came up with. It is a single automation.
Sensor which needs to be put in a .yaml file in the packages directory and then use an !include statement to pull it into the configuraiton.yaml file.
The below is a water leak template sensor and automation based on the same concept that @pedolsky showed above in this threads example (Around post 28-32).
Use the developer, states tab within home assistant to ensure your entities are in the same device class and use the same states (ie. on/ off etc).
Modify this to suit your needs for doors.
template:
- sensor:
- unique_id: water
name: 'Water Leaks'
icon: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ 'mdi:water-alert' if e != 0 else 'mdi:water' }}
state: |
{% set e = state_attr(this.entity_id, 'count') %}
{{ e if e != 0 else 'no_water' }}
attributes:
count: |
{{ states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'eq', 'moisture')
|selectattr('state', 'eq', 'on')
|list
|count }}
last: |
{%- set on = states.binary_sensor
|selectattr('attributes.device_class', 'defined')
|selectattr('attributes.device_class', 'eq', 'moisture')
|selectattr('state', 'eq', 'on')
|map(attribute='entity_id')
|list %}
{%- set last = expand(on)
|sort(reverse=true, attribute='last_changed') %}
{{ 'no' if last|count == 0 else last[0].entity_id }}
Automation below needs to be pasted to GUI
alias: (ACTION- AUTOMATIC- SECURITY- NOTIFICATION) Leak Notification ONLY
trigger:
- platform: state
entity_id:
- sensor.water
not_from: unknown
not_to:
- no_water
- unavailable
- unknown
condition:
- condition: template
value_template: |
{% set last = trigger.to_state.attributes.last %}
{{ last != 'no' and
trigger.to_state.state != trigger.from_state.state }}
action:
- service: notify.persistent_notification
data:
message: >
{% set last = trigger.to_state.attributes.last %}
LEAK: {{ state_attr(last, 'friendly_name') if last != 'no' else
'ERROR' }}
Since: {{ (states[last].last_changed) |string |as_timestamp
|timestamp_custom('%d/%m/%Y, %I:%M:%S %p', now() ) }}
title: |
LEAK WARNING!
- service: notify.notify
data:
message: >
{% set last = trigger.to_state.attributes.last %}
LEAK: {{ state_attr(last, 'friendly_name') if last != 'no' else
'ERROR' }}
Since: {{ (states[last].last_changed) |string |as_timestamp
|timestamp_custom('%d/%m/%Y, %I:%M:%S %p', now() ) }}
title: |
LEAK WARNING!
mode: single
max_exceeded: silent