I have 2 multi-purpose sensors on my garage door, because quite frankly I can’t trust that they report the open/close state of the door 100% reliably. I have a rule that sends a Pushover notification if the door has been open for 15 minutes, and again at 30 minutes, and it tells me which sensor was open.
At 10:33 am I got alerted that the door has been open for 15 minutes from sensor 2, and again at 10:48 am (the 30 minute mark). My Sharptools dashboard shows both sensors are closed. The ST app shows both sensors are closed. Since I am home I could check and the door is indeed closed. The history for both sensors shows a closed entry for sensor 1 at 10:18 am, and a closed entry for sensor 2 also at 10:18 am. The only difference I can see in the history between the two sensors is that sensor 1 also has a “No vibration” entry at 10:18 am right after the closed entry, but sensor 2 does not have any “No vibration” entry.
Why did these rules trigger? This time I was home so I could actually see the door is closed, but I set these rules up for when I am not at home.
And in case you were wondering, the $Garage15Warning and $Garage30Warning variables are to prevent back to back messages due to the timing difference from sensor 1 at the top of the door vs. sensor 2 near the bottom. I can confirm that the variables were set to false at 10:18 am from the log of the rule that sets them to false:
Can you share a screenshot of the device history? Feel free to share the Rule ID and I would be happy to take a closer look at the rule logs myself.
In particular, you would want to check the details of the ‘State Stays’ log entry by tapping the ‘view’ link to the right of that log item.
The two closed events in your second rule log screenshot is particular suspicious. Why are there two ‘Garage door 2 contact is closed’ events at 10:18:19? I suspect that the sensor sent multiple open and close events within the same second… and SmartThings has a bug where the events are sent with millsecond precision but querying the state from SmartThings only returns the seconds level precision.
In any normal scenario, this isn’t a problem as it’s very uncommon for a device to send so many events within a single second. But the logs in the last screenshot make it look like the device reported some odd events within the same second.
I appreciate that, if you have the time to look at it. Here’s the ST device history. You are correct, the device had 2 open/close sequences back to back. But I know the door was only opened and closed once. Sensor 1 only has one open/close sequence.
Even if the variable reset rule detected the device fired twice, the final result of both is that the device is closed. Which is the correct state. And this rule only resets my variables so that they are in the correct state to execute my timer rule.
One further piece of info, I am using the Mariano Zigbee Contact Mc driver for those contact sensors. Been using it for a long time.
I guess the question is, if everything points to the device being closed, why does the Stay-state say the contact is open?
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.
I am using the Mariano Zigbee Contact Mc driver for those contact sensors. But I’ve been using it for quite a while because I originally found the official driver to be really poor in the multi-sensors.
As for solid mesh, well that’s up in the air. The sensors are about 25 ft from the ST hub, but through a couple of walls as well.
As with everything ST, I find this stuff works most of the time. Of course the failures are the ones that bug me.
And further info. My wife went out the garage door about 25 minutes ago. This time my reset rule only has two entries, spaced about 5 seconds apart as I would expect.
