I have a feeling that the use of for is subject to the same drawback as timers and last_changed. If Home Assistant is restarted at any time during the 6-hour period prior to 20:00 the for is reset. That’s a problem with Home Assistant; countdown periods don’t survive restarts. It’s a real challenge to make these duration-based automations immune to restarts.
1 Like
Good point but I’m not sure honestly.
I can’t really test it right now, tho.
If that fails then I guess I’ve been lucky since I don’t think I’ve run into it before…that I can remember at least.
Yeah, me too; will test it tomorrow. Can’t see how it could know about an entity’s state 6 hours ago if it restarted an hour ago. The entity’s last_changed would be set to an hour ago.
How is your building skills?
I understand that this is a way to solve the problem with software.
But I believe you need hardware this time.
As others mentioned, a restart can break it, if you need to fetch something large from the garage, someone drops by and you want to show that you can open and close the garage with voice or an app and the time is 14:05 on a Monday.
Or perhaps you took out the trash on Sunday/Monday morning and you still get notified.
I suggest a hardware solution because there can be so many reasons this can fail (I assume).
A simple distance sensor that sees if the trash can is in the garage will work great.
If you want to use mechanical ways then a load cell or force sensitive resistor below the trash can will feel if it’s there.
Or a magnet on the trash can and a reed switch.
There is lots of ways to do this and knowing for a fact that it has been done or not.
I believe the software solution will let you down a few times.
Thanks for that. I thought there had to be a simple solution but I only looked under the weekday integration and didn’t find it… because it’s under ‘time’ instead. I’ll keep it in mind for future 
Automations don’t lose their history across restarts so you could use the state change of the garage door to trigger an automation and then use the automation’s state.last_triggered to compare to current time.
1 Like
In that case it’s better to set an input datetime with the automation.
That way it’s easily accessible
Certainly could do, just adds an extra step.
Well… not really.
It creates another entity but the amount of steps is the same.
So you don’t have to create the ‘input_datetime’ in the first place ?
Ok so you are at that level… Sigh…
Don’t be a dick, I’m asking because I’ve had no experience of them before and you said it was the same!
From your response I take it it’s not automatic?
Either way is obviously far easier than your first suggestion 
I don’t know what you are talking about, but it doesn’t matter.
I will not argue anything with you.
The input_datetime does add an extra step, but, sadly, it’s the only “everything proof” way I’ve found of setting a time in the future to check for something or do something and not have it erased by restarts, reloads, automations being turned off/on, etc.
@123 FYI this now works without specifying states. It will work on any state.
- alias: Garage Door Has been closed for 6 hours on a monday
trigger:
- platform: state
entity_id: cover.garage
for: "06:00:00"
2 Likes
Even if Home Assistant is restarted during the 6-hour period?
As I understand this new feature is that it doesn’t care if the state is on for 6 hours or off for 6 hours; as long as it stays in the same state for 6 hours, it will trigger.
However, I think it’s still susceptible to being reset when Home Assistant is restarted. Anyway, one more thing to test.
That I don’t know. I just know that during the month of WTH someone ninja’d in the ability to use ‘for’ without specifying a state.
EDIT: I Just saw your edit
Yes, same goes for any other entity. Same state for 6 hours == trigger, regardless of state.
I just tested with an automation that had a “for: minutes: 5” in it and when I restarted HA after two minutes the 5 minutes started after HA restart so that method won’t work.
That said I think the best (most reliable) way is to use an input_datetime as suggested.
you’ll need two automations - one to set the input_datetime for the last time the garage was opened and then the automation for your notification.
input_datetime:
garage_opened:
name: Last Time Garage Opened
has_date: true
has_time: true
automation:
- alias: set_garage_opened_time:
trigger:
platform: state
entity_id: cover.your_gd
to: 'open'
action:
service: input_datetime.set_datetime
data:
entity_id: input_datetime.garage_opened
timestamp: "{{ now().timestamp() }}"
then modify the condition to check that now is later than 6 hours past the input_datetime:
condition:
- condition: template
value_template: >
{{ as_timestamp(now()) | int - state_attr('input_datetime.garage_opened', 'timestamp') | int > 21600 }}
- condition: time
weekday:
- mon
I haven’t fully tested it but I think it should work.
The only thing I’m not sure about is the timezone that is used using the timestamp option for now(). I assume it’s your local TZ but if it seems off by an hour or hours (depending on your TZ) you can use the slightly more complex method to be sure:
data:
entity_id: input_datetime.garage_opened
datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
1 Like
All timestamps are in unix time. Shouldn’t need any conversion with what you’re doing.
using automations last_triggered attributes myself to check in conditions, I do agree with @Bobby_Nobble this would be most straightforward and failsafe.
simple create an input_boolean.garage_open have it set by automation on open/close, and use that automation’s last_triggered to check in the condition. Fool and fail/faul proof.
1 Like