How to see log details (tap to expand)
If you take a look at the details in the log entry, you’ll see what I’m talking about further below. You might also want to enable the ‘debug’ level of logging from the filters so you can see the potential trigger events.
The initial event came in as open which is what kicked off the state-stays check 15 minutes later.
When the state-stays check ran it had the original snapshot of the event and it queried SmartThings for the current state to see if a newer timestamp came in.
In this this case, there wasn’t a newer state, so the system assumed that the value had not changed.
–
Are you using a community developed driver for this contact sensor or an official one? And do you have a solid mesh to that area of your home? The reason I ask is the multiple events coming in with the same seconds level precision combined with the SmartThings bug/deficiency of not retaining the millisecond precision in events and state is an issue. It’s something of an indeterminate state as the system can’t tell which of the events are newer.
I’ve made note to see if we can also consider the value of the state in the case that the timestamps match in a state-stays trigger… one concern I have is we were looking at moving to using our internal event cache for state-stays triggers to align with the recent enhancements we made with On Transition Only triggers. The concern is with determining which event is ‘newer’ in SmartThings and thus should be the one in the cache is ambiguous based on all three events having the same timestamps and potentially being received out of order. 