Best way to prevent automation trigger on startup?

Configuration
1

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?

  - id: dishwasher_ended
    alias: Dishwasher Ended
    trigger:
      platform: numeric_state
      entity_id: sensor.dishwasher_power
      below: 2
    action:
      - service: notify.text_ron_notifier
        data:
            title: "Dishwasher Done"
            message: "Dishwasher done."
2

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.

3

I ended up finding this “not_restarted_recently” sensor someone did and use this as a condition in any automations which seem to trigger on a restart.

I did end up increasing the time to longer because a couple things seem to not be loaded within the 30 all of the time.

4

There’s a standard integration – Uptime – that can be used for that. If configured for minutes, the OP could do:

  - id: dishwasher_ended
    alias: Dishwasher Ended
    trigger:
      platform: numeric_state
      entity_id: sensor.dishwasher_power
      below: 2
    condition:
      condition: numeric_state
      entity_id: sensor.uptime
      above: 5
    action:
      - service: notify.text_ron_notifier
        data:
            title: "Dishwasher Done"
            message: "Dishwasher done."

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.

7 Likes
5

Awesome, three options! Which will he choose?? drumroll please :drum:

6

I like uptime since it’s built in and I don’t have to setup another binary sensor to duplicate what it already does basically.

This only happens on startup so waiting until 5 minutes pass before allowing automation to trigger should do the trick.

7

I appreciate the tip!

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.

 - platform: numeric_state
   entity_id: sun.sun
   value_template: "{{ state_attr('sun.sun', 'elevation') }}"
   below: -4.0

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. :+1:

8

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.

All about optimizing the WAF :- :laughing:

9

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:

 - platform: numeric_state
   entity_id: sun.sun
   value_template: "{{ state.attributes.elevation }}"
   below: -4.0
10

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.

11

Possibly, but probably not.

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.

1 Like
12

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?

13

EDIT: Yes, you’ve got it.

14

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.

15

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.

16

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.

5 Likes