SmartThings timestamp issue (I think) breaking rules

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

    • :white_check_mark: IF Condition not matched (motion = 'active') → ELSE
    • :white_check_mark: Pausing 15 seconds
    • :white_check_mark: IF Condition matched (motions stays 'inactive' 10s) → THEN
    • :white_check_mark: Office Hallway: off()
  • 3:54:49 PM motion = active

    • :white_check_mark: IF Condition matched (motion = 'active') → THEN
    • :white_check_mark: Office Hallway: setLevel(50)
  • 3:54:54 PM motion = inactive

    • :white_check_mark: IF Condition not matched (motion = 'active') → ELSE
    • :white_check_mark: Pausing 15 seconds
    • :white_check_mark: IF Condition matched (motions stays 'inactive' 10s) → THEN
    • :white_check_mark: Office 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

    • :white_check_mark: IF Condition matched (motion = 'active') → THEN
    • :white_check_mark: Office Hallway: setLevel(50)
  • 2:55:01 PM motion = inactive

    • :white_check_mark: IF Condition not matched (motion = 'active') → ELSE
    • :white_check_mark: Pausing 15 seconds
    • :cross_mark: 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.

1 Like