I have several rules which in essence, when motion or an event happens a light turns on. I have a second rule which is triggered by when switch stays on for x minutes do some action, including turn off the switch. Recently I started noticing the lights are no longer turning off. Attached arse 3 screenshots, the trigger potion of the rule, the history from smartthings (in this case the switch turns on at 7:53, with the stays on for 5 minutes, Id assume I should see on off around 7:58, but that never happens till I Manually turn it off), and the log for the rule which shows the rule was never triggered. This used to work, so I’m not sure what changed.
In the rule logs, you can enable the Debug level in the filters.
I recently received one other report about state stays conditions with SmartThings. In that case, 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.
There are 3 entries, 1 on the switch on, one when the timeout would have happened, and one when I turned it off. These are screenshots of the timeout event
Event: 23:53:09 (7:53:09 local)
State: 23:55:53 (7:55:53 local)
Wow, those timestamps are really far off if that’s the same events from your SmartThings mobile app screenshot?
That’s almost 3 minutes of difference!
Not sure what you are referring to there . In the smartthings console, the on shows 7:53. In the log the on is 7:53:03 (my last post). The off never got triggered but the log shows a trigger at 7:58:04 (my next to last) which is 5 mintes 1 second after the on. I do see the odd date timestamp in the next to last post, but thats not in line with the actual on (the last post)
The third screenshot in your first reply. 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.
Is there something I shold try, like reboot the hub?
You could try, but I suspect it’s something at the SmartThings platform level. I’m out on vacation at the moment, but when I’m back I will take a closer look and see what options we have (eg. If there’s any fixes, workarounds, or if it needs to be escalated to SmartThings engineering).
After some further research, I may know what is causing it. This switch is turned on by a motion detector. When I look at the motion detect I can see 2 motion events were triggered, one at 7:53 and one at 7:55. The rule on motion simply says turn on the switch (which the second on event should do nothing and the switch isn’t showing two on events). But it’s interesting that the state timestamp is showing the 55 timestamp. Could it be the Smartthings is updating the timestamp if there are multiple on events? Have a great vacation!
Any update on this problem? I have worked around it by using delay, but I just found the problem again on an outlet, stays on for 4 hours never gets triggered.
Hey @Brian_Taylor – thanks for the follow-up. I just received a report from @Nezmo who seems to be experiencing something similar.
I’m trying to figure out why this was only impacting you (or perhaps your devices / drivers) back in September and why it just starting impacting Nezmo just this weekend. It’s not clear if it’s a change that is unique to these particular drivers, a platform level SmartThings change, or why those timestamps for the state are updating now.
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.
What make / model switches (Brian), motion sensors (Nezmo), or other impacted State Stays devices are each of you using? And are you using an official SmartThings driver or a community driver?
Hi Josh,
My problem could have been present since September and I just didn’t notice it.
Some example devices:
- Iris motion sensor Zigbee - stock ST driver
- GE Z-Wave in-wall outlet - Custom/community driver
1 Like
Josh, the switches are leviton with account linked to smartthings. The outlet is a zigbee outlet with the default zigbee driver.
1 Like