Hi Matt-
You can find a summary of the State Stays logic in the following release post:
There’s two different places this can be used (Triggers vs IF Conditions) and the concept is exactly the same, but there’s some nuance in the implications of how you use it.
The concept is as it reads: the state of an attribute must stay the same value for the specified period of time.
Trigger
This is a really convenient item in a Trigger as it enables you to only run a rule if an attribute has stayed a certain value for a period of time. If we have a trigger for door stays open for 5 minutes
, then the rule will only run if the door stays open for that full duration. If the door opens, then closes anytime within the 5 minute window, then the trigger is no longer valid and is discarded. The timer basically get’s reset to 0 and the door has to stay open for the full 5 minutes before the rule is actually triggered.
IF Condition
The concept is the same within IF Conditions, but rather than set a timer and wait for the time to elapse, the IF condition looks back in time. So when you have an IF condition of door has stayed closed for 5 minutes
, then the door must have been closed for the past 5 minutes at the time the IF condition is evaluated in order for it to be true.
With that in mind, we see one common mistake with implementation of ‘state stays’ in IF Conditions. If you set your Trigger for door changes to open
and then have an IF condition for door has stayed open for X minutes
, then the IF condition will never evaluate to true. This is because the door will have just changed to open… and when the IF condition runs, it looks back 5 minutes and sees that the state has changed during that interval, so it returns false.
Depending on the goal, you could accomplish this today. The condition might be something like:
IF: Your Phone - presence is 'present'
THEN:
IF: Your Phone - presence has stayed 'present' for 5 minutes
THEN: //do nothing
ELSE:
//take your action
The idea here being that your phone must currently be present, but it must have changed to present within the last 5 minutes – hence using the ELSE path as a ‘not stayed present for 5 minutes’. And when combined with the top-level IF condition, the nested ELSE path could be read as ‘changed to present within the past 5 minutes’.
PS. If it’s something you would reuse in several rules, you could use variables to track if the presence changed to present within 5 minutes and flag it true or false accordingly.