I’m knew to HA so please forgive me if I’m misunderstanding something simple here.
I’m trying to make an automation that will welcome me home when my phone tracker arrives home and then the contact sensor on the front door is triggered (because I like gimmicky stuff like this). Eventually I’ll have Alexa say it out loud but I’m just using phone notifications for now because it’s easier to confirm that it’s working.
I assume the “wait for trigger” action is what I want but I can’t figure out how to get it to work and the instructions here are sort of vague. When I execute it manually nothing happens. What am I doing wrong?
alias: Welcome home
description: welcome me home when I open the door
trigger:
- platform: state
entity_id: device_tracker.life360_meredith_daniels
from: away
to: home
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.front_door_sensor_17b51511_ias_zone
from: 'off'
to: 'on'
- service: notify.notify
data:
message: Hope work was not too soul crushing today.
title: Welcome home!
mode: single
When you say “phone notifications”, do you mean the mobile app? Typically the mobile apps register services in the form of notify.mobile_app_<device name>. It looks like you’re using notify.notify to send the notification, I’m not really sure what that does for you. I generally avoid it because it seems almost random what actual notification service it gets tied to. Last time I tried it I received an email on my o365 address because apparently it got bound to notify.o365_email registered by my o365 integration.
Nothing else looks wrong so my suspicion is the notification service you’re using isn’t doing what you think its doing. If you click Developer Tools in the left side nav and go to the Services tab you can test individual service calls. I’d suggest you put your notification call in there and confirm it works the way you would expect before digging more into wait_for_trigger.
notify.notify sends notifications through the app for me. That’s what the Home Assistant website says to use and it’s worked fine for all my other automations that involve notifications 
I’ll try a different type of service and see what happens though
Are you literally going to leave the front door open for 2 minutes? because that is required to trigger the automation.
I thought that was designating within two minutes of the first trigger. in another thread some guy had an automation would trigger if the door was unlocked “within” 5 minutes of him arriving home - he had it as:
- wait_for_trigger:
- platform: state
entity_id: 'whatever his lock was called'
from: 'locked'
to: 'unlocked'
for: '00:05:00'
Seems odd cause like, yeah “for” 5 minutes sounds intuitively to me like what you’re saying. But no one said that was wrong so I figured I was dumb and that was what you were supposed to do lol
I guess I’ll take that part out but either way that doesn’t explain why this won’t execute manually. Still doesn’t work even with nothing in the “for” field.
I tried using
service: notify.mobile_app_merediths_iphone
data:
message: Hope work was not too soul crushing today.
title: Welcome home!
It still doesn’t execute. But both notify.mobile_app_merediths_iphone and notify.notify appear to do the same thing if I call them from the dev tools. The issue has to be with the wait_for_trigger service
I use notify.notify exclusively for mobile apps at the moment, though I will separate that for “sleeping” individuals so they dont get unimportant notifications when they should not.
That requires:
timeout:
minutes: "00:02:00"
continue_on_timeout: false
to be added to the wait trigger itself, not to the state change part of the wait trigger, though dont even bother with that until you get the trigger working.
Have you confirmed the device tracker was home before the automation ran ?
is home supposed to be ‘home’ and away ‘away’ ?
1 Like
Good call. At the moment I’m the only one in the house with the app so I hadn’t worried too much about it - my boyfriend only ever wants to use Alexa voice control for some reason. But that could change
I haven’t ever had a change to test this in real time so no I haven’t really been able to confirm what state the device tracker was in when trying to get this to trigger automatically.
But I’ve tried configuring it like this too (no specified initial state) and it still does nothing when I click execute.
alias: Welcome home
description: welcome me home when I open the door
trigger:
- platform: state
entity_id: device_tracker.life360_meredith_daniels
to: home
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.front_door_sensor_17b51511_ias_zone
to: 'on'
from: 'off'
- service: notify.mobile_app_merediths_iphone
data:
message: Hope work was not too soul crushing today.
title: Welcome home!
mode: single
I should add it’s not throwing an error either so the formatting seems to be acceptable, it’s just not calling the services properly for some reason.
1 Like
It seems like other people are accomplishing similar things by making an input boolean that tests whether a devices state has changed “recently” and then using that as a condition in an automation that triggers when you arrive home. I might just have to try that 
thanks for trying to help though
Be aware that acceptable formatting for an automation and required formatting for the platform within the automation are not the same thing.
However, clicking execute should bypass the trigger, what does the logbook like like?
I did the exact same thing as your code but with a light switch, and it worked, though I added the timeout to test it as well:
alias: Test wait trigger
description: ''
trigger:
- platform: state
entity_id: input_boolean.alarm_armed_delay_10min
from: 'off'
to: 'on'
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id: light.shelly_1pm_133
from: 'off'
to: 'on'
continue_on_timeout: false
timeout: '00:02:00'
- service: script.script_alert_bulbs_flash
data:
color: Blue
seconds: 10
mode: single
Then I toggled the boolean and watched the dev tools state, “current” changes to 1 indicating the automation is running, then 2 mins later it changes to 0, and will also change from 1 to 0 within the 2 minute timeout if i turn the light on, triggering the specified action.
so your syntax appears correct, and executing the automation manually should bypass the automaton trigger and activate the wait trigger.
1 Like
This ended up accomplishing what I wanted - I made a timer that triggers whenever I arrive home
alias: Start home arrival timer
description: turns on a switch for two minutes when I arrive home
trigger:
- platform: state
entity_id: device_tracker.life360_meredith_daniels
to: home
condition: []
action:
- service: timer.start
data: {}
entity_id: timer.2_minute_timer
mode: single
And then I made another automation that uses that as a condition
alias: Welcome home
description: welcome me home when I open the door
trigger:
- platform: state
to: 'on'
entity_id: binary_sensor.front_door_sensor_17b51511_ias_zone
from: 'off'
condition:
- condition: state
state: active
entity_id: timer.2_minute_timer
action:
- service: notify.mobile_app_merediths_iphone
data:
message: Hope work was not too soul crushing today.
title: Welcome home!
mode: single
Works perfectly
Right, duh, I mixed up for and timeout, not the same thing. 
Note that a device_tracker's state is actually not_home, not away. That was one problem with your original automation. Also, to trigger when arriving home it’s best not to specify from: not_home, because if there is any possibility that the tracker changes from another zone directly to home, that wouldn’t work. Best (as you discovered) just to use to: home.
Next, even with that addressed, once the automation triggered, it would wait forever for the front door sensor to change to on. So if your tracker changed to home, and then changed again to not_home without the sensor changing to on, the automation would still be running waiting for that. So if it then did change to on, but while your tracker was still not_home, the notification would get fired. I don’t think that’s what you wanted.
This is one way to do what I think you want (in just one automation):
alias: Welcome home
description: welcome me home when I open the door
trigger:
- platform: state
entity_id: device_tracker.life360_meredith_daniels
to: home
condition: []
action:
- wait_for_trigger:
- platform: state
entity_id: binary_sensor.front_door_sensor_17b51511_ias_zone
from: 'off'
to: 'on'
timeout: '00:02:00'
continue_on_timeout: false
- condition: state
entity_id: device_tracker.life360_meredith_daniels
state: home
- service: notify.notify
data:
message: Hope work was not too soul crushing today.
title: Welcome home!
mode: restart
Changes from your original:
- Remove
from: away.
- Add timeout to
wait_for_trigger.
- Add check after
wait_for_trigger to make sure the tracker is still home.
- Change automation mode to
restart instead of single.
FWIW, the more “traditional” / typical way to do what you want is to use the front door sensor as the automation trigger, and then add conditions that the device tracker is home and changed state less than 2 minutes ago.
Think of the automation trigger as what defines when the automation actions should run, and the conditions as if the actions should run (when an a trigger fires.) As in, the notification should be sent when the front door opens, if I’m home and I arrived home within the last two minutes.
10 Likes
Thanks mate, do i need the mode “restart” if i use a template condition?
alias: Benachrichtigung Happy Weekend
description: ""
trigger:
- platform: state
entity_id:
- device_tracker.iphone_11_shi
to: home
id: Shi kommt heim
for:
hours: 0
minutes: 0
seconds: 0
- platform: state
entity_id:
- device_tracker.iphone_sascha
to: home
id: Sascha kommt heim
for:
hours: 0
minutes: 0
seconds: 0
condition:
- condition: time
weekday:
- fri
after: "14:30:00"
before: "18:00:00"
action:
- choose:
- conditions:
- condition: trigger
id: Shi kommt heim
- condition: template
value_template: >-
{{ state_attr('automation.neue_automatisierung_3',
'last_triggered') | default(today_at(), true) < today_at('14:30')
}}
sequence:
- wait_for_trigger:
- platform: state
entity_id:
- binary_sensor.eingangsture
from: "off"
to: "on"
timeout:
hours: 0
minutes: 2
seconds: 0
milliseconds: 0
continue_on_timeout: false
- condition: state
entity_id: device_tracker.iphone_11_shi
state: home
- parallel:
- if:
- condition: state
entity_id: binary_sensor.occupancy
state: "on"
then:
- service: media_player.volume_set
data:
volume_level: 0.45
target:
entity_id: media_player.sascha_s_sonos_beam
- service: notify.alexa_media_sascha_s_sonos_beam
data:
message: >-
Happy Weekend liebe Schie! <audio
src="soundbank://soundlibrary/explosions/fireworks/fireworks_02"/>
data:
type: tts
- if:
- condition: state
entity_id: binary_sensor.prasenzmelder_badezimmer_presence
state: "on"
then:
- service: media_player.volume_set
data:
volume_level: 0.45
target:
entity_id: media_player.echo_dot_badezimmer
- service: notify.alexa_media_echo_dot_badezimmer
data:
message: >-
Happy Weekend liebe Schie! <audio
src="soundbank://soundlibrary/explosions/fireworks/fireworks_02"/>
data:
type: tts
- conditions:
- condition: trigger
id: Sascha kommt heim
- condition: template
value_template: >-
{{ state_attr('automation.neue_automatisierung_3',
'last_triggered') | default(today_at(), true) < today_at('14:30')
}}
sequence:
- wait_for_trigger:
- platform: state
entity_id:
- binary_sensor.eingangsture
from: "off"
to: "on"
timeout:
hours: 0
minutes: 2
seconds: 0
milliseconds: 0
continue_on_timeout: false
- condition: state
entity_id: device_tracker.iphone_sascha
state: home
- parallel:
- if:
- condition: state
entity_id: binary_sensor.occupancy
state: "on"
then:
- service: media_player.volume_set
data:
volume_level: 0.45
target:
entity_id: media_player.sascha_s_sonos_beam
- service: notify.alexa_media_sascha_s_sonos_beam
data:
message: >-
Happy Weekend liebe Sascha! <audio
src="soundbank://soundlibrary/explosions/fireworks/fireworks_02"/>
data:
type: tts
- if:
- condition: state
entity_id: binary_sensor.prasenzmelder_badezimmer_presence
state: "on"
then:
- service: media_player.volume_set
data:
volume_level: 0.45
target:
entity_id: media_player.echo_dot_badezimmer
- service: notify.alexa_media_echo_dot_badezimmer
data:
message: >-
Happy Weekend liebe Sascha! <audio
src="soundbank://soundlibrary/explosions/fireworks/fireworks_02"/>
data:
type: tts
mode: single
I don’t understand the question. What does using a template condtion have to do with the automation mode? Have you read Automation Modes?
Yes i read it but i dont understand it very clear im sorry, i have a template condition in my automation who execute only once per day if triggered before, I thought the “restart” mode could possibly lead to problems.
The automation mode (single, restart, etc.) controls what happens when one of the automation’s triggers fires (and the conditions are met) when the automation’s actions are still running from the last time the automation was triggered. (In this case, the automation’s current attribute will be 1 or more.)
If the automation’s actions are not currently running (i.e., the current attribute is 0) when the automation is triggered, then the mode has no effect.
So, you have to ask yourself, is it possible for the automation’s actions to be running (from a previous trigger) when a (new) trigger occurs. If it is not possible, then the mode doesn’t matter.
However, if there is any chance it is possible, then you should decide what mode makes the most sense for that particular automation. I.e., do you want it to ignore the new trigger? If so, pick single. Or do you want it to stop what it’s doing and start over? If so, pick restart. Or do you want the previous run to keep going AND start a new run so they both run at the same time? If so, pick parallel. Or, lastly, do you want the previous run to keep going, and then start a new run when the previous one finishes? If so, pick queued.
1 Like