I have a simple alert when my dishwasher power usage drops to let me know the dishes are done. But it fires whenever HA restarts because the power reports initial state.
What would be the best way to prevent this from triggering?
Something similar was one of the first automations I copied from this forum. It sets an input boolean for ‘washer running’ whenever the washer power usage rises above a certain amount. That input boolean is used as a condition in the automation you mentioned.
So, if the first time sensor.dishwasher_power changes state to a numeric value below 2 happens during the first 5 minutes after restart, then this would prevent the automation from triggering.
Funnily enough, I recently encountered a situation that could’ve benefited from using sensor.uptime in that manner.
I have an automation that uses a Numeric State Trigger to turn on the pool lights when the sun’s elevation is below -4 degrees. The same automation also turns them off at 23:00.
While tinkering with Home Assistant around midnight, I upgraded and restarted it. Several minutes later, I idly glanced out into the darkness and noticed the pool lights were back on. After some thought, I concluded the cause was that the automation’s trigger was being evaluated on startup. The elevation was probably changing from unknown to -4 and causing the automation to execute.
I changed the trigger to a simple Sunset Trigger to make it “startup-proof”. However, I now know I can resolve the issue using the Uptime sensor in the automation’s condition.
You’re right, it is absolutely the most convenient way.
The only caveat I can think off: if your dish washer is ready exactly in the 5 minute windows after a restart, you won’t be notified. Whereas by using an input_boolean (whose value gets restored right after a restart), this window will be much smaller.
State based triggers (state, numeric_state, template, …) are evaluated when one of the “input” entities changes. The numeric_state & template triggers additionally remember when they’ve triggered, and won’t trigger again until the conditions are no longer met and then are met again.
So, in your case, as soon as sun.sun changed state (including when just an attribute, like elevation, changed), the trigger evaluated if the elevation was below -4. If it was, then it triggered. After that first trigger, it would have to change to -4 or above, and then back to a value below -4 to trigger again.
And, BTW, the documentation for the numeric_state trigger isn’t very explicit about this, but it defines a variable named state that is a State Object that represents the new state of the referenced entity when it changes. So you could have done this:
I’m aware that after crossing the threshold value, it must “reset” itself (by flipping back to the other side of the threshold) before the next crossing can serve to trigger it. That’s why I surmised the value must have been unknown at startup before it is was set to some negative value below -4 (corresponding to the sun’s elevation around midnight).
Because if it’s not that then I’m at a loss to explain why that Numeric State Trigger fired on startup.
For both the numeric_state and template triggers, they are only evaluated when an input entity changes. If they evaluate to “true”, then they will fire. Once they have fired they remember that they have. (For a numeric_state trigger it actually remembers on an entity-by-entity basis, since it can take a list of entity IDs.) The next time an input entity changes, and they are evaluated again, if they still evaluate to “true” they will not fire again, because it remembers it has already fired.
So what makes it fire again? Well, anything that causes it to forget it has fired will allow it to fire again (the next time an entity changes and they evaluate to “true.”) They will “forget” when they are reset (i.e., automation reloaded or turned off and on or HA is restarted.) They will “forget” when there is an error evaluating them (e.g., a template error, or the state of the entity is not a number, such as unavailable, for a numeric state trigger.) They will also “forget” when they evaluate successfully, but to “false.”
So normally the “cross the threshold” behavior applies, but not for the first time they evaluate to true after restart, or when they evaluate to true after reloading automations, or after turning an automation off and back on, or after there is an error evaluating them. If any of these things happen then they will fire again the next time an entity changes and they evaluate to true.
OK, so if I understand you correctly, it’s not because elevation was unknown at startup (then set to some negative value below -4) but because the “flag”, that records if a Numeric State Trigger has fired, is reset at startup (i.e. forgotten).
I guess this “flag” must be stored in RAM only and that’s why it’s “forgotten” on startup/reload?
While this is an old thread, still relevant. I’ve attempted to do the same thing using “uptime” to inhibit at start, but the end result is that my automation actually runs after 12 minutes (7 minute boot delay and 5 minute “for”):
trigger:
platform: state
entity_id: binary_sensor.radon_fan
from: 'off'
to: 'on'
for:
minutes: 5
condition:
#ignore this for the first 7 minutes of boot
- condition: numeric_state
entity_id: sensor.home_assistant_uptime
above: 7
This sensor is off for a few seconds at boot until it gets an incoming reading and then flips to on, so that’s around 5 minutes after boot. What I was hoping for is that this off-on transition would be ignored, because it happens during the first 7 minutes of uptime. The 12 minute (7+5) trigger after boot was unexpected.
If the binary sensor flips from off to on at the 5 minute mark, then the trigger as written will actually fire at the 10 minute mark (when it has been on for 5 minutes), which of course is after the 7 minute mark. So effectively the 7 minute condition is only “filtering out” off to on transitions that happen during the first two minutes.
If you want to filter our transitions that happen during the first 5 minutes, then the condition needs to use 10, not 7.
This thread has recent activity (Jun through Nov 2020) and some good discussion on the topic of preventing automation triggers due to HA startup… but the example usage and yaml above is now outdated. That’s because in a recent release (2020.12?), the Uptime integration changed to represent the timestamp (ie date and time) of last startup or boot.
For those new to HA and landing on this discussion, before trying examples above please make sure you read through this other thread Condition Uptime to see examples of correct syntax and usage.
