SmartThings timestamp issue (I think) breaking rules

[josh]

Hi Benny-
Welcome to community and thanks for posting! Sorry to hear that things aren’t working as expected.

@bennywy

The light doesn’t even reliably turn on in the scenario. I believe what’s happening is that the rule is triggered correctly when there is motion. Although the motion should be active, SmartThings reports an inactive motion from slightly earlier (less than a second)

There’s a better rule design that can be used here. Instead of querying the smart hub for the current state, you can directly use the triggered event in the comparison using a Context Variable for the Event Value. That way the rule is directly comparing against the same event value that triggered the rule rather than trying to query the smart home hub where there could be discrepancies (old values if the new value hasn’t persisted yet, or fast changing new values already reported)

Context Variables (Rule Engine) - SharpTools Knowledge Base

---

@bennywy

At first I thought it was an issue with the “stay” command (very similar to what this user was having - [Stays on no longer working in rules - #3 by Brian_Taylor]), but now I just think it is an issue with the timestamps that SmartThings is reporting back to Rule Engine.

Once the comparison against the triggering event value is fixed, it would be interesting to see the logs for the State Stays nested condition.

It is possible that you’re experiencing a similar issue with the weird timestamp reporting with certain drivers. That issue is specific to State Stays comparisons though as the

Explanation of State Stays and the Trigger Issue (tap to expand)

@josh

…when we checked the details of the rule log showing the state stays failed, we saw that the timestamp of the state was 2 seconds later than the reported event timestamp which is why the system was thinking that another event must have occurred (per the timestamp from the state being later than the original triggering event) and thus the state stays condition wasn’t passed.

@josh

After the specified state stays delay in your rule, the system asks SmartThings for the current state so it can compare the timestamp and make sure it hasn’t changed since the originally received timestamp. Something funky seems to be going on as SmartThings is replying that the timestamp associated with the current state is several minutes after the timestamp of the event that the system received…so the system thinks that another event must have come through since the timestamps are so different.

@josh

Normally when a device reports its state, if it reports the same state again, SmartThings keeps the existing timestamp recorded for the state (even though it might internally record an ‘event’).

It seems like in both of your cases, the state is showing a newer timestamp at a later point when the State Stays part of the rule checks to verify that the current state matches the originally snapshotted state from when the event first came in.

The workaround that I deployed in December is for incorrect timestamps reported within State Stays within the Trigger of a rule. It basically snapshots event values as they come across so it can locally cache its own interpretation of when the state changed rather than having to query the smart hub (SmartThings) to ask for the current state so it can use the reported value + timestamp to determine if the value changed or not (eg. if it’s the same timestamp and value as the original event, then it didn’t change).

For State Stays within a condition, the rule engine must query the hub to ask for the current state (value+timestamp) and then it compares if that timestamp is older than the duration you are interested in.

The approach you used with using a shorter State Stays duration compared to your delay is a good approach as with distributed systems there’s a possibility for slight time skew and such.