Is this for the rule Stay test rule?
TLDR:
- SmartThings is reporting the old state
- Workaround with distinct triggers (more details below)
- In Triggers, implement a separate motion = ‘active’ and separate motion stays ‘inactive’ trigger
- In the Flow compare against the
$context.event.value
to know what action to take (light on or off)
Recent Executions: Good
Looking at the recent logs, here’s what I see:
-
3:45:17 PM
motion
=inactive
IF Condition not matched (
motion = 'active'
) → ELSEPausing 15 seconds
IF Condition matched (
motions stays 'inactive' 10s
) → THENOffice Hallway:
off()
-
3:54:49 PM
motion
=active
IF Condition matched (
motion = 'active'
) → THENOffice Hallway:
setLevel(50)
-
3:54:54 PM
motion
=inactive
IF Condition not matched (
motion = 'active'
) → ELSEPausing 15 seconds
IF Condition matched (
motions stays 'inactive' 10s
) → THENOffice Hallway:
off()
And the same again at the 4:14 PM CDT executions from the active
and inactive
triggers.
Earlier Execution: Failed
It’s not clear to me exactly when the rule was saved, but I’m guessing it was after the 2:46 PM CDT evaluations since those showed the IF Condition being evaluated against the attribute name.
It wasn’t until the first 2:54:50 PM execution that the first IF Condition was evaluated against $context.event.value
properly.
-
2:54:50 PM
motion
=active
IF Condition matched (
motion = 'active'
) → THENOffice Hallway:
setLevel(50)
-
2:55:01 PM
motion
=inactive
IF Condition not matched (
motion = 'active'
) → ELSEPausing 15 seconds
IF Condition not matched (
motions stays 'inactive' 10s
) → ELSE
Unfortunately, it seems like it could some sort of delay on the SmartThings side with updating the recorded state.
Time | Step | Description |
---|---|---|
2:54:49.972 | 1 | active event |
2:55:01.000 | 2 | inactive event |
2:55:17.901 | 2c | State Stays check evaluation after delay SmartThings returns the state value/timestamp matching original event 1 |
Workaround
Since it seems like SmartThings is reporting the old state or is otherwise delayed in updating their internal recording of the state (even though the events are emitting on time), you could split the rule out into two separate rules.
This would take advantage of the enhancements we added to State Stays Triggers which uses its own internal evaluation of ‘State Stays’ based on received events so it doesn’t have to rely on querying the smart home hub for the reported state to determine if the state changed.
It would be two simple rules like:
Rule 1:
Trigger: ‘motion’ changes to ‘active’
Flow: Office Hallway: setLevel(50)
Rule 2:
Trigger: ‘motion’ stays ‘inactive’ for X seconds
Flow: Office Hallway: off()
–
Alternatively, you probably could combine these into a single rule like:
Triggers:
- ‘motion’ changes to ‘active’
- ‘motion’ stays ‘inactive’ for X seconds
Flow
IF $context.event.value = 'active' THEN Office Hallway setLevel(50) ELSE Office Hallway off()
The idea being that each trigger is distinct enough and covers the exact scenario that each needs to handle – the first trigger is only fired when the motion changes to ‘active’ whereas the second only triggers when the motion stays ‘inactive’.
That enables you to use the $context.event.value
to know that it’s either the motion immediately having become active and thus you need to turn the light on or the motion has stayed inactive and thus you want to turn it off.
Basically the immediate change to ‘inactive’ wont ever actually trigger the rule – it has to stay inactive otherwise it wouldn’t trigger the rule.