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:
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
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? 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.
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.
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).
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.
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.
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.