I searched everything so far in this forum, and didn’t see this suggested. I was building an automation today to have a response based on an input, but I only want it to trigger on specific days and times.
Sure I can set conditions that create that limit, but the automation still triggers every time the trigger condition is met. I can see a future state where I might have a dozen or more automations for this trigger, and most will only be during certain days and times. This means that all of those automations will at least start processing before the condition statement shuts them down, thus filling up traces and logs with these false triggers.
Why is there not either (a) a Date/Time constraint on automations that says they can only run on certain calendar days (of year, not just week) at certain times, or (b) a logical “AND” for triggers that says both conditions have to be met for an automation to trigger (thus a more dynamic triggering system, since it would not just be date/time constraints).
Either solution would reduce the processing overhead for automations.
As I said above, the problem with using conditions for this (which is what I created today), is the Automation will still trigger based on the input, before the automation is told to stop. For one or two automations like this it probably is negligible, but you get in the dozens, and this could start to put a strain on processing power, especially on some of the lighter weight platforms that Home Assistant runs on.
The point of the WTH is to add a secondary limit that says “don’t even trigger, unless the date is between X and Y”
I guess if I put the real-world automation in here, it might help to put it in context of why I’m looking at this and thinking the reasons to make this WTH uniquely different.
My automation is triggered by my UniFi Doorbell Pro. If a person rings the doorbell on a specific day (in my case Halloween, which is tomorrow), it will play a media file back through the Doorbell’s speaker. But with the current state of the automation, it will trigger all day, every day, even when there’s only 5 hours it needs to be active on one day out of 365 days, the condition stops it, but it still takes processing time to get to that condition check.
I do not see a fundamental difference between having a condition inside the trigger vs. as a separate condition. In both cases HA needs to evaluate your date-based condition to decide whether or not to continue.
An option you could think about is implementing a second automation that turns on/off this doorbell automation based on maybe a calendar trigger or something similar.
And another option that might work in this instance is to use a template trigger which includes both your doorbell binary sensor and a calendar condition.
Technically this is exactly the same, there’s the exact same sequence of commands that would run on the backend. It would just be presented differently in the UI. Performance wise it’s the same. HA is an event driven system, so both your condition and the trigger will have to be evaluated to determine if an automation will run. The order doesn’t matter. Triggers are conditions internally in an event based system.
I don’t see how your example above matches the "don’t even trigger, unless the date is between X and Y” concept. Your normal doorbell automation is going to trigger every time someone presses the button… Why not just add a Choose to the existing action sequence?
I am not a dev, so the cumulative processing requirements of different functions is outside my scope of knowledge… but is there actually a significant difference between checking a condition each time an automation is executed and instantiating a listener for a second automation based on the same trigger with additional conditional logic?
Maybe a nested set of conditions would solve it, so you first check the date and then if the date is right, then you check the next condition.
HA support nested conditions.
That’s how it works right now. Every automation is a linear sequence of commands with some very basic if/else/switch and boolean logic. Conditions are checked one after the other.
A conditional expression is one of the most basic and fastest things a CPU can execute. At the most basic level, even a RPi4 can execute hundreds of millions of conditional instructions per second. Of course a HA condition is much more than a simple conditional branch and there’s layers upon layers upon layers above the machine level (Python is a very slow language). But even accounting for all that, evaluating a condition is a very very fast operation.