EDIT: Solved and working… didn’t change anything, just started working.
I am new to the HASS scene, but have already found it incredibly useful to bundle all of my smart devices in one place that is platform agnostic.
Lately my kids have accidentally left the garage door open a few times overnight. My goal to improve my wife approval factor is to create a notification that will send a pushover message when the door has been left open for a set period of time. Here is what I have now:
alias: 'Garage door notifier '
description: Sends pushover when open >15 minutes
trigger:
- platform: state
entity_id: cover.garage_door
for:
hours: 0
minutes: 30
seconds: 0
milliseconds: 0
condition:
- condition: device
device_id: 2cd8b012226884784bafcae64f5b76e2
domain: cover
entity_id: cover.garage_door
type: is_open
action:
- service: notify.pushover
data:
title: Garage Door
message: Someone left me open, please close me.
- service: timer.start
data:
duration: 00:30:00
When testing, I get too errors in the logs:
Garage door notifier : Error executing script. Invalid data for call_service at pos 2: must contain at least one of entity_id, device_id, area_id.
and
Error while executing automation automation.garage_door_notifier: must contain at least one of entity_id, device_id, area_id.
This is my first automation, so I am thinking it may be an easy fix… at least I hope.
Finity has answered the question reference the errors.
But why not have the trigger as state = door open for 30 mins and do away with the condition?
The way you have it would work, once the entity for your time is in place, however your current automation is watching for any state change on door entity that stays for 30 mins, were as all you want is it to watch for the door having been open for 30 mins.
Perhaps I have misread what you stated but it seems like you are suggesting the for option, unlike delay, resumes its countdown after a restart. If you carry out a test you’ll see the for option suffers the same fate as delay, wait_template, wait_for_trigger, etc and is reset by Reload Automations (or a restart).
This simple automation demonstrates that fact. If you set the input_boolean to on, wait a minute, and then restart Home Assistant (or just Reload Automations) it will fail to generate the notification.
- alias: Check behavior of for option
trigger:
- platform: state
entity_id: input_boolean.test
to: 'on'
for:
seconds: 120
action:
- service: notify.persistent_notification
data:
title: 'For option completed countdown'
message: '{{ now().timestamp() | timestamp_local }}'
Finity has explained why the final service call, timer.start, is the source of the error (because it’s missing entity_id) but what is this timer’s purpose?
Rossk’s suggestion is what you should do to get it to work. Use to: 'on' and remove the condition. Unless there’s some other purpose for the 30-minute timer, it seems unnecessary.
trigger:
- platform: state
entity_id: cover.garage_door
to: 'on'
for: '00:30:00'
As mentioned, pretty much everything designed to wait (for, delay, wait_template, wait_for_trigger, etc) gets reset by Reload Automations or a restart. Active timers are stopped by Reload Timers or a restart (unless you use the timer restoration system posted in the link above).
There is a way to mitigate this deficiency by using a Time Trigger. It makes the automation a bit more complicated but Time Triggers do survive restarts.
FWIW, I have converted many of my automations to use either the Time Trigger technique or timers with the timer restoration system wherever a time period greater than 30 minutes is required (for anything shorter I still use the for option).
Really? I honestly didn’t know that and obviously didn’t test it…yet.
I would have thought that there wasn’t a background process running some sort of timed function for “for:”. I would have thought that the “for:” did a continuous check (say every second) to see if the trigger condition is satisfied (‘on’ ‘for:’ 30 seconds). then the automation triggers.
the automation doesn’t trigger by the device turning on. it triggers by the device turning on and that it is in that state for the “for:” time.
I can see the other things being affected since the automation is in fact running during the time that those timed functions are being processed.
And I think that the use of ‘for:’ in a condition works the same. It should trigger the automation then check that the condition is met for the time specified before it runs the actions.
So am I correct that you are saying that in any automation trigger that has a for - no matter how long or short - won’t ever trigger if the monitored state change occurs and HA is restarted before the designated ‘for:’ is met?
While I’ve never explicitly checked that I’ve never noticed that my automations that contain a ‘for:’ don’t get triggered.
Now, I could completely agree that if the ‘for:’ time occurs at the exact time that HA is restarting then the automation wouldn’t trigger in that case since the time occurs during restart and the “checker” never sees the trigger as true and so skips right over it.
I will definitely need to do some more checking because it just doesn’t sound right. But I could be wrong…and likely am. I’ve just never seemed to have been bitten by that if that’s the case.
I always thought that the listener wasn’t assigned to the “state change” event but instead to the “state change for” event.
I can’t believe that there aren’t any reliable timer functionalities at all in HA.
Every single one suffers from this huge issue so I can’t see any reason to use them at all, especially for things that may be important.
And I can’t believe this huge issue has never been addressed since it’s such a basic function in not only HA but of any automation system at all. And a warning about this bug ought to be added to the docs.
I’ll add this one more to the list of “not recommended” timer functions. And now I’ll need to go thru to check where I use it and switch to the input_datetime work around for those as well.
EDIT:
now that I think about it I might remember having this conversation in the other “timer” thread. But I only thought we discussed timers, wait, delay, etc. but not for.
I also recently set up an automation to notify of the garage door being left open, the previous one I had generated a basic notification like yours, the new one will take a picture from a camera, and create an actionable notification for the HA companion app that shows the cam image, and allows me to close the door, or close the door AND arm the alarm, or go to the lovelace panel that shows the most recent camera snapshot and door controls.
As mentioned in some other posts, the condition is not necessary, also I am using multiple triggers, and a template which tells me how long it has been open:
alias: Alert Open Door, Garage Overhead (large)
description: 'Uses alarm zone not-closed sensors, will not work on bypass'
trigger:
- platform: state
entity_id: binary_sensor.29_large_garage_door
to: 'on'
for: '00:05:00'
from: 'off'
- platform: state
entity_id: binary_sensor.29_large_garage_door
to: 'on'
for: '00:15:00'
from: 'off'
- platform: state
entity_id: binary_sensor.29_large_garage_door
to: 'on'
for: '00:30:00'
from: 'off'
condition: []
action:
- data:
title: Security System
message: >-
Large Garage Door Left Open {% if trigger.id is defined -%}{{
('5','15','30+')[trigger.id|int] }}{%- endif %} Minutes
display_time_ms: 120000
icon: warning
app_critical: true
app_importance: high
app_color: '#FF8800'
app_id: notify_garage_door_open_1
app_click_action: /lovelace-security/garage
app_image: /api/camera_proxy/camera.lorex_182_mediaprofile_channel1_substream2
app_actionable: true
app_action_1: GARAGEDOOR1_CLOSE
app_action_1_text: Close door
app_action_2: DRIVEWAY_ARM
app_action_2_text: Close and Arm
service: script.generate_alert_notification
- service: script.script_alert_bulbs_flash
data:
color: Yellow
seconds: 60
I am using a wrapper for the notification service so that iOS and Android phones get the same code in the automation, you can infer the effective parameters in most cases from the code above, but the template code can be used with pushover to show the length of time the door has been open
This happens to me a lot, what’s worse is I end up using google and or support forum to research something that I already knew but forgot, so I think OK write it down and leave myself some notes I can reference too next time only to find out I have already done it last time but forgot where I made the notes…no hope
It contains an unnecessary State Condition. It checks for a condition that the trigger has already evaluated and confirmed.
It also uses the for option so it’s susceptible to being reset by Reload Automations or a restart (as explained above). However, as long as you don’t reload/restart during the first 6 minutes when the door is open, it’s fine.
Thanks for all the conversation around it, I didnt get a notification until I was looking for something else, but the notification randomly started working the way I intended it to without making any edits.
coming to this topic in 2023, and seems like Alert does not survive a restart – its state goes back to idle after the restart, while the state during alerting is on.
I’m still new to HA, but from what I can see, this seems to be the most comprehensive answer – especially now that timers can be restored after a restart. Just to make sure I’m not missing anything: besides the 2 automation in this answer, you still need an extra to stop the timer if you actually close the garage within the 30 minutes, right?
Nevermind – just realized that (a) you have the condition in the timer.finished event that checks whether the garage is still open, and (b) if you close/reopen in the middle, the timer.start resets the timer from the beginning. These would be the 2 situations where we could have issues, so you covered both!
