I want to improve the silly off/max control algorithm in my Itho HRU ventilator box. The goal is:
Run at auto mode when CO2 <600ppm (~700 rpm)
Run at autonight mode when max CO2 800-1000ppm (~1600 rpm)
Run at high mode when CO2 >1000ppm (~3000 rpm)
Boundary conditions:
Don’t change speed unnecessarily → only trigger when level changed for more than X minutes
Don’t override timer functions used for e.g. getting rid of humidity → use states.fan.itho_hru_350.attributes.preset_mode != timer1/timer2/timer3
I considered a several options, only one that meets above requirements:
Use automation with value_template to check from_state & to_state combined with a filter integration on the underlying sensor value to smoothen it. Use condition to check that states.fan.itho_hru_350.attributes.preset_mode is OK.
Other options I considered:
Set up timer job, check every 5 min and set mode according to CO2 - Pro: easy Con: trigger too often
Run automation on CO2 level and change when it crosses a boundary (i.e. platform: numeric_state) - Pro: can use ‘for’ setting to prevent spurious triggers. Con: need multiple automations? Triggers multiple times?
Use wait_for_trigger to return to low speed when ventilation is done (E.g. here). Pro: works nicely for 2 levels. Con: not sure how to expand to three levels.
Somehow I feel there might be a more elegant solution (e.g. not requiring editing configuration.yaml manually & leveraging the for option in value automations), does anyone have a suggestion?
Thanks for your reply. I didn’t know about using trigger.id as action parameter, that’s an elegant approach.
Still a question: I had something like that in mind, but won’t trigger this continuously if the value is stable at a certain value? e.g. It will trigger at 10:00, then again at 10:05 because the value was again X for 5min, and again at 10:10, etc. In that case I could also use a timer?
For this trigger to occur the sensor value must cross from above 600 to below 600 and stay there for 5 minutes.
It will not trigger again unless the sensor value goes above 600 then back to below 600 and stay there for 5 minutes.
So if your sensor is flapping about going above and below 600 you get no triggers.
If your sensor goes below 600 and stays there for 5 minutes you get one trigger. If it stays below 600 until the heat death of the universe you still only get that one trigger at the 5 minute mark.
This catches people out all the time. Instead of “numeric_state” it should really be called “numeric_threshold”. But it’s far too late for that now.