Example: You want to water the lawn only once a day, and only when you’re away.
So you want an automation that triggers when you’re “Away”, and then either:
Won’t run again for at least 24 hours
Won’t run again until at least the next calendar date flips over (say, at midnight the following date)
Yes, we can currently use “Single” mode with either a “wait” or a “delay” step. Or we can use “time_triggered” in a conditional. Or you can write a new automation that disables the first.
BUT…
It is such a critical feature for making smooth, natural automation experiences that I think it deserves its own dedicated, easy-to-use toggle in the automation UI.
I’m picturing a “Block Execution For:” toggle button that defaults to OFF. Turning it ON, enables an input field accepting a HH:MM:SS parameter.
Oh. I guess I didn’t really clarify this very well.
I’m talking about an automation that can trigger any time of day, but should only be allowed to run either once per calendar date, or once per X hours.
Example: You want to water the lawn only once a day, and only when you’re away.
So you write an automation that triggers when you’re “Away”, and then either:
Won’t run again for at least 24 hours
Won’t run again until at least the next calendar date flips over (say, at midnight the following date)
There are many ways to accomplish this already. But, in my opinion, it’s a feature worthy of its own dedicated section in the UI
You’re right, there are quite a few ways to accomplish it. Personally, I’d like to see it solved that with a modified Time trigger that can also take a date as well. I actually do that right now for my holiday automations by using a combination of TOD sensors along with the Date/Time component, but it’s messy.
Personally, I’d like to see it solved that with a modified Time trigger that can also take a date as well.
Hmm. I like that idea as a solution to other things, but I’m not sure I follow how this would solve the issue of an automation “cooldown”.
Like, how could you use it in the sprinkler example? If you’re triggering by date, then the sprinklers would come on when that date arrived (at time 00:00:00) rather than when you’re “Away” right?
Yup. In that instance, you would have Away as a condition. So, if you trigger on “23/08/2020 07:00”, then for a condition, you’d want to have “person.state == ‘not_home’” as a condition. What will happen in that case is that when the automation triggers and you’re home, it won’t continue and won’t fire again until the next day.
That’s way that I solve it for my evening automations: At 18:30 (or whatever my evening TOD is set to), turn on the living room lights, but only if I’m at home. To get around not having a date/time trigger, I use TOD sensors:
Ah okay. Yeah, that isn’t quite what I’m after in this WTH. I want something that triggers variably throughout the day, not at a specific time, but only executes if it’s been at least a day (or whatever) since last trigger.
I do this in multiple places already, but it requires a funky template
That would carry over a restart though I assume? Over time hopefully restarts will be required less and less but it could still potentially cause problems.
I guess it all depends on how established your instance is. With the ability to reload more aspects being built in to HA I have definitely restarted less since 115 but have still had to do a couple to fix some issues - For example I’ve had to restart today as HA banned one of my internal IPs (another issue in itself) which meant I had to remove it from the ip_bans.yaml and then restart HA.
If you’ve got everything as you need it then I definitely understand why you’d be restarting less often
What about using the last_triggered attribute of the automation and having a template condition that makes sure it wasn’t triggered in the last X amount of time? With the recent addition of the timedelta template function, this should be a bit easier than before. I’m not sure if it also gets reset after a restart though.
Yeah, I mentioned last_triggered in my post. That’s what I currently use, but I felt it should be more of a 1st-class citizen in the ui.
There are actually several new 0.115 features that will likely help here. Here’s an example using wait_for_trigger along with a time trigger set to ‘00:00’:
- id: '1600968950766'
alias: Morning Routine
description: Run this whenever I leave bed, but only once per calendar date
trigger:
- type: turned_off
entity_id: binary_sensor.bed_sensor
platform: device
# device id, etc...
action:
- service: script.alexa_tts
data:
message: Good morning! Here's two minutes of news...
- wait_for_trigger: # Blocks automation from happening again until...
- platform: time
at: '00:00' # ... midnight tomorrow.
mode: single
This is okay for the once-a-calendar-date scenario. But it doesn’t survive a restart, and not sure how to modify it to do “run once in this time frame, and once in this time frame” scenarios. Maybe with the new triggerable input_datetimes + before/after, or the new timedelta template helper you mentioned maybe?
For me, these are acceptable compromises. I still wish there were a field in the automation UI that controls this behavior, and in a way that survives restarts, but my primary beef was with how awkward it was to do this fairly-common use-case with time_triggered and time calculations.
Ha, interesting. I restart my instance manually probably once a day. But I do a lot of experimentation and grooming, and am a little anal about keeping all my HACS integrations up-to-date (many of which require restarts).
But with all the new live reload things coming out, should be fewer and fewer restarts.
Question: when I click “reload automations”, does it interrupt any waits/delays going on in other automations?
I do all this on my experimental HA’s. You can set up HA on docker on windows in about 10 minutes, start the container and play around. You just wont’ have access to things that plug directly into your HA unit.
I would assume yes but I don’t have a definitive answer.
I would assume yes but I don’t have a definitive answer.
Gotcha. I hope it’s not the case, since (I believe) any time you save any automation via the UI it reloads all automations :-\ Kinda makes delays/waits a lot less attractive as cooldown solutions.
