Does the state condition of an automation when used with ‘for’ statement, checks that the state matches the given value for the given time starting from the time the automation was triggered, or does it look also in the past (before the trigger time)?
I want an automation that checks that when the hvac_action goes to idle, the oil_boiler will be off, too, after 10s at most. If it is still on after 10s, then do sthg.
Are all A, B and C below correct?
If not what is the correct one and what is the meaning of the ‘for’ in A?
A:
- id: '1670953243896'
alias: Oil Boiler to off
description: Check that Oil Boiler goes off when house heating goes off
trigger:
- platform: state
entity_id:
- climate.living_room
attribute: hvac_action
from: heating
to: idle
condition:
- condition: state
entity_id: switch.oil_boiler
state: 'on'
for:
seconds: 10
action:
... // actions
B:
- id: '1670953243896'
alias: Oil Boiler to off
description: Check that Oil Boiler goes off when house heating goes off
trigger:
- platform: state
entity_id:
- climate.living_room
attribute: hvac_action
from: heating
to: idle
condition: []
action:
- delay:
seconds: 10
- condition: state
entity_id: switch.oil_boiler
state: 'on'
... // rest of the actions
C:
- id: '1670953243896'
alias: Oil Boiler to off
description: Check that Oil Boiler went off when house heating goes off
trigger:
- platform: state
entity_id:
- climate.living_room
attribute: hvac_action
from: heating
to: idle
for:
seconds: 10
- condition: state
entity_id: switch.oil_boiler
state: 'on'
action:
... // actions
Thanks.
If so, then the condition in A will always evaluate to True, because the boiler will be ON in the past because the hvac_action was ‘heating’ (in my heating system). Which is not the desired behavior.
B or C are the ones that will check the state “ahead”, after 10s, which is the desired behavior.
Conditions only look in the past.
Could we trigger a documentation update, just so that it is clear? Is it the same with the state conditions in scripts? The documentation of the conditions for the automations points to the conditions in the scripts.
You’re more than welcome to amend the condition documentation. However, personally the documentation is very clear to me.
conditions look very similar to triggers but are very different. A trigger will look at events happening in the system while a condition only looks at how the system looks right now. A trigger can observe that a switch is being turned on. A condition can only see if a switch is currently on or off.
And in it’s use in a for condition… take a look at the comment:
optional: trigger only if state was this for last X time.
condition:
alias: "Paulus not home for an hour and a bit"
condition: state
entity_id: device_tracker.paulus
state: "not_home"
# optional: trigger only if state was this for last X time.
for:
hours: 1
minutes: 10
seconds: 5
Lastly, wait_for_trigger or wait_template is what you’re looking for.
It’s clear to me now.
maybe the ‘trigger’ verb for a condition can be improved to ‘evaluates to true’, i.e., make it:
" # optional: evaluate to True only if state was this for last X time."
I’ll propose this change to the doc.
How I understand the wait_for_trigger is that it does not control after how much time I want the state to be checked. It can trigger immediately inside the timeout in my case. I think B above is the best option to use, because I want the state to be checked after the exact delay.
yes, B and C are the ones that achieve the desired behavior, as written above. But the point of the discussion here was to clarify what the ‘for’ does in the state conditions. It’s clarified now.
Thanks!
Doc fixes usually go quick because there’s no backlog because frenck is the only one adjusts the docs. Very little people help with documentation. The discord channel for docs is a ghost town too. Most of the document PRs that sit there are for future PRs to core that don’t apply yet.