Syncing with ST Issue - Oct 14, 22

I don’t know yet if it’s all devices but my SharpTools dashboards are not currently staying in sync with ST device states unless I manually refresh the account connection.


:information_source: Update: Long story short, we deployed a hotfix to workaround the issue where SmartThings is generating really old events.

We’ve also communicated with SmartThings so they can identify a proper fix on their side.

I’m seeing the same thing on certain devices, but I haven’t quite narrowed down what the difference is yet. For example, some older Groovy Virtual Switches are still updating status fine whereas a Zigbee RGBW bulb is not.

SmartThings had a platform issue listed earlier today and just rolled out a fix within the last hour or two. I wonder if their ‘fix’ introduced other platform issues. :thinking:


Yeah, I had the same thought.

As a counter point, I have some Groovy-based devices not updating.

This is part of a dashboard that has been working great since it was created. Today, “Garage Door 2” is stuck “ON”, but only in SharpTools. It is reporting correctly in SmartThings, (it is currently closed). It can be controlled from SmartThings, but not from SharpTools. When tapping the device in SharpTools, I get the green banner at the bottom, “command sent”, but nothing happens.

-I’ve restarted the phone
-I’ve rebooted the SmartThings
-I’ve rebooted the WIFI router.

SmartThings Screen for comparison…

Other Devices are working from the SharpTools dashboard.

Advice please…

Hey @JKB121 I moved your post into an existing thread about status update issues.

It seems like something might have changed in the SmartThings platform causing this issue. I’m actively communicating with their engineering teams at the moment.

Can you share more details about what type of device Garage Door 2 is - what driver or DTH is it using?


Thanks Josh- I didn’t see this thread…

Whoops… That is from garage door 1, but garage door 2 is the same…

1 Like

So I just noticed that I can control Garage door 1 with SharpTool, but the tile stays “closed”, as opposed to Garage door 2 which does nothing. If this is helpful…

EDIT: Scratch that, now neither door is operable from SharpTools…

What I’m seeing is that I can still issue commands from SharpTools for things like lights (since I can toggle through the ‘wrong’ states) and the commands are going across to SmartThings and to the device.

The issue appears to be that SmartThings events for some devices are coming across with bad timestamps from the 1970s.

The issue with that is the system won’t replace the existing state for certain attributes as it checks to make sure that it’s a newer event coming through before writing it. (‘switch’, ‘contact’, ‘motion’, ‘lock’, ‘door’)

Since the raw event is sent to the Rule Engine, it’s still processing rules based on those events and if you look at the details of the first trigger log entry, you can even see the incorrect timestamps in the events.

SmartThings do seem to like breaking things on Fridays, sigh.

I’d click like… but I don’t… LOL

I’m working on a hotfix on our side that will identify really old dates that aren’t reasonable and just replace them with the current timestamp.

It’s not ideal for us to inject the timestamps on our side, but it’s better than those events failing altogether. And the SmartThings team is actively looking into it, so hopefully their fix will follow soon after ours. :slight_smile:


As always Josh, I appreciate your quick response on this.


1 Like

I thought the end of WebCoRE was going to be the end of SmartThings for me. SharpTools saved them. I guess I should still consider Hubitat… But changing all those devices would be painful…

Thanks @josh !!! I appreciate you!

Hotfix is deployed on our side. :sunglasses:

As noted above, if an event comes in with an unreasonably old timestamp, this will replace that with the current timestamp at the time of event arrival.

Sidenote for State Stays Rules (tap to expand)

In all practicality, this shouldn’t have any major implications, but it’s possible that it could impact certain ‘state-stays’ conditions in rules depending on atomic time float between SmartThings servers and ours. Ideally we’ll see SmartThings fix things on their side shortly and the system will automatically use their timestamps without any further action required.

1 Like

Looking good here Josh!

1 Like

I was seeing issues with ‘Stays’ in Rules. Working now post your hotfix.

1 Like

Garage doors are working, and after walking around to trigger all motion sensors, they are now working again!

Thanks Josh!

1 Like

15 posts were split to a new topic: Simulated Switches after SmartThings Groovy Change