Trigger for time automation strategy (which way: One-shot style with choose or Trigger and wait_for_trigger resolve?)

With all the wildfires in the northwest USA we’ve been dealing with a lot of smoke in the atmosphere. I want to start filtering my house air so we aren’t breathing in a bunch of smoke. To that end I’ve built ESPHome AQI sensors and I bought a Blueair 280i air purifier. I’ve been working with another Home Assistant guru (@aijayadams) to beef up the support for Blueair and now we can control the device, which is excellent!

I want to set up a hysteresis for my air purifier based on an air quality sensor (pm25). Something simple like this:

if pm25 > 10 for 10 minutes:
   turn on purifier
if pm25 < 5 for 30 minutes:
   turn off purifier

However, I know I can build the automation two ways:

  1. ONE-SHOT: To trigger the automation on either “if statement” above and issue the control to the purifier using choose to determine the action to take turn_off vs. turn_on
  2. WAIT_FOR_TRIGGER: I could build the automation to trigger only once to turn the device on and use wait_for_trigger to perform the turn_off when it’s satisfied.

I’m wondering what the community’s thoughts are on these two approaches, specifically: if I should choose one over another and why.

P.S. whenever I post anything with back ticks in this forum (for in-line code and codeblocks) when I try to post it always pops up the UNFORMATTED CODE WARNING complaining about unmatched back tick usage, but my back ticks are always coherent. Do others have this same problem or is specific to me? :confused: I noticed there’s a “Don’t show this message again checkbox” but I don’t want to miss a screwed up post – but it always happens so I guess I’d never know. :smiley:

If it takes for a long time for the air purifier to get it down below 5, then wait_for_trigger is not advisable. The reason is because if your HA server crashes or reboot while waiting, the automation won’t work.

  - platform: numeric_state
    entity_id: sensor.air_quality
    attribute: pm25
    above: '10'
    for: '00:10'
  - platform: numeric_state
    entity_id: sensor.air_quality
    attribute: pm25
    below: '5'
    for: '00:30'
  - platform: homeassistant
    event: start
  - choose:
      - conditions:
          - "{{ state_attr('sensor.air_quality', 'pm25') | int > 10 }}"
          - service: switch.turn_on
              entity_id: switch.air_purifier
      - conditions:
          - "{{ state_attr('sensor.air_quality', 'pm25') | int < 5 }}"
          - service: switch.turn_off
              entity_id: switch.air_purifier

The above code contains a flaw when HA is crashed or restarted - it does not count how long has it passed (pm2.5 > 10 for 10 minutes or pm2.5 < 5 for 30 minutes).

Not only a crash or reboot but simply restarting HA or reloading automations will cause a disruption in the automation function.

It’s best to use separate turn on and turn off triggers if the wait/delay etc is “long”.

Unless it doesn’t matter if the purifier runs longer (or forever until you notice it) then the wait is ok to use.

Thanks @ardysusilo! I can make another trigger via home assistant startup to handle those cases, right?
EDIT: Wait, it looks like you covered that case already – I guess you just meant that it won’t count how long it’s been up when the system comes up, it’ll just set the state it should be based on above or below (and leave it, if between).

Thank you @finity. I think I will do the one-shot, using @ardysusilo’s suggested code above.

You can change the Template Conditions to State Conditions. It supports the use of for.

I have not tried it yet, but does Numeric State Condition supports the use of for? There are no example in the documentation regarding the use of for - so I am uncertain.

See Taras’ post #14. Numeric_state condition does not supports the use of for.

It does. I’m using it in other automations. :slight_smile: Just not sure if I want it to bother waiting if HA just got restarted or not…

My mistake. I suggested to use State Condition but this automation requires Numeric State Condition. Its documentation doesn’t indicate it supports for so I am not sure why SpikeyGG said that it does.

I’m using numeric_state with for: in at least one of my automations and it works. The docs are probably not aligned to the programming.

This is the trigger from the automation I’m using and it works!

      - platform: numeric_state 
        entity_id: sensor.pihole_a_cpu_thermal_1_temperature
        above: 153
          minutes: 10

Pay no mind to the temp… these Raspberry Pi’s operate hot!

ah, I see. I think I might have to build an input_number simulation space to test this out…

The example you posted isn’t a Numeric State Condition.

Feel free to confirm it doesn’t support for.

1 Like