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
I’ve let Josh know this over email but I found a fix … at least it’s working for now.
If I change the driver on affected devices, ‘stays’ works again. And, you can then change back to the original driver you were using and it continues to work. So something seems to get reset on the SmartThings side when changing drivers. Hopefully this stays working (excuse the pun),
You will need another driver on your hub that supports your device. You can always delete it after doing the above if it’s not in use elsewhere.
1 Like
Unfortunately, this ‘fix’ didn’t stick. All was okay when I tested but by the evening the problem returned.
That’s too bad! I’m working on a different approach to handle State Stays that should workaround this. Unfortunately, I don’t have an ETA at the moment and the upcoming Thanksgiving holiday may delay the release a bit.
1 Like
Hi @Brian_Taylor and @Nezmo !
I’ve deployed an update to fix the State Stays trigger issue you reported. To complete the fix for your affected rules, you’ll need to trigger one event from each impacted device. This one-time step will initialize the new state-change tracking system.
The update introduces internal state-change tracking while maintaining compatibility with the existing system. For most users, this transition is automatic. However, in your specific case (where the reported state timestamp differs from the state-change timestamp), this one-time initialization is necessary.
Once initialized, the system will reliably track all state changes going forward. Please let me know if you have any questions or need further assistance.
1 Like
When checking the Rule Logs for your rules, you can verify if the internal state cache is being used.
You can tap the Filters button in the Rule Logs and enable the ‘Debug’ level which will show you potential trigger events along with the result of the deferred state-stays check (even if the trigger doesn’t match / run the rule).
Then on either the top-level success or failure log entry, if you tap the view link on the right side, when you are reviewing the Runtime Data section, you’ll see that the second comparison entry is now of type cache rather than state whenever it’s using the internal state-tracking system:
1 Like
Outstanding.
I have many Rules impacted. I should be able to see the fix in play fairly quickly. I’ll report back.
Thanks Josh.
UPDATE: I won’t be able to give good feedback until much later today. The one Rule I have that executes this time of day has ‘stays’ in the IF conditions which I know you have not addressed yet. My others Rules that come in to play later in the day should all be fixed.
1 Like