It means wait for the sensor’s value to decrease below 800 but don’t wait longer than 10 minutes. If you do end up waiting that long, do not continue executing the rest of the action.
I don’t think using continue_on_timeout alone, without an accompanying timeout, achieves anything so it probably doesn’t negatively affect the wait_for_trigger. I would remove it or add an appropriate timeout.
In theory, your automation should trigger the moment the sensor’s value increases above 1250. It immediately sends a High CO2 notification. Then it will wait until the sensor’s value decreases below 800 after which it will send the Low CO2 notification.
You’re saying it works like this: triggered when sensor’s value increases above 1250 and immediately sends both notifications?
Thanks! It indeed seems to have to do with timeout. Upon closer inspection it seems the low notification is 1 minute after the high notification. After some debugging the following edit seems to work, and sends a high CO2 notification every 3 minutes which makes sense.
the “continue_on_timeout: false” should cancel the automation actions at that point (if the wait for trigger isn’t satisfied).
if the numeric_state trigger of the parent automation never goes below 1250 and back above 1250 the automation shouldn’t re-trigger again and keep sending notifications every 3 minutes.
@123 : somehow I think the default timeout is 1 minute, which explains that I had a 1min delay. I only don’t get why I still got the second notification as the automation should have stopped (continue_on_timeout: false), but perhaps that option is ignored if there’s no timeout. In any case the above seems to work
@finity : indeed it cancels the automation after the timeout (e.g. 3min), but since the CO2 level is still above 1250, it will trigger again and again. This makes sense, right?
In the mean time I’ve found a different problem with my automation: if the CO2 drops below the high threshold (1250) but not below the low threshold (800), I will not get the notification that the value is OK again, i.e.:
Solving my second problem, I think the below should work:
Trigger above high threshold
Use repeat until to keep looping until sensor is below low threshold
Send high notification
Use wait_for_trigger with timeout (e.g. 60min) to detect if value drops below low threshold, then send low notification
If value has not dropped, repeat loop keeps firing
This only fails if the value drops below the low threshold between wait_for_trigger timing out and repeat until, which depends on the speed of my computer but is likely <1s, so with an hourly loop almost 0 chance.
alias: High CO2 test3
description: ''
mode: single
trigger:
- platform: numeric_state
entity_id: sensor.mh_z19_co2
above: '1250'
condition: []
action:
- repeat:
until:
- condition: numeric_state
entity_id: sensor.mh_z19_co2
below: '800'
sequence:
- service: notify.notify
data:
message: High CO2 in office
- wait_for_trigger:
- platform: numeric_state
entity_id: sensor.mh_z19_co2
below: '800'
timeout:
minutes: 60
continue_on_timeout: false
- service: notify.notify
data:
message: Low CO2 in office
the automation will (should…?) only trigger again if the value goes below 1250 and then subsequently goes above 1250. A trigger only happens when the trigger condition transitions from false to true.
If it dstays true it will never trigger again.
So if it stays above 1250 the automation won’t trigger.
Ah ok, thanks. Then I didn’t understand the triggers correctly, thanks for explaining. In that case I indeed also don’t quite understand why it repeatedly triggered. Strange.
For the record: the re-triggering occurred because of another bug/configuration error: because I had two (CO2) sensors with the same name (one reporting the actual and one reporting the 24-h average), the actual sensor would trigger the automation, while the 24-h average (being lower) would immediately trigger the automation cancellation. See also this bug report.
