Anyone else having issues with sharptools widgets staying in sync since the hub update?
Yeah, just noticed too that SharpTools widgets are not working…troubleshooting now
@joshua_lyon is this news to you?
This is the first I’ve heard of it, but I’m looking into it now. Have either of you tried creating a new widget to see if that will stay in sync?
And are the widgets just not staying in sync at all or they are slow to update? Last night, I noticed that my home was really slow to react to any actions that were running through the cloud, so I’d like to rule-out slowness.
Just an update:
- I tried creating a new widget with my test account and it seems to be maintaining the state as expected.
- The widgets from my main account from before the hub/platform update still seem to be working as expected.
Please let me know if newly created widgets are maintaining their state as expected for you.
1 Like
Reinstalling app and widgets cleared the issue thanks
2 Likes
I’m glad I found this. All day my state Change subscription have been super slow to respond. For testing purposes I have Tasker say when something is turned on and off. I’d turn a light off and sometimes it would be minutes later before I got the confirmation. A reinstall seems to have helped but still delayed.
I noticed the same thing this week. I had to uninstall and reinstall.The app. After that all has been working fine. V1 Hub and Samsung Galaxy 5 running lollipop 5.0 on Verizon.
1 Like
Old thread, but timely topic. Recently installed the app for the first time and purchased the widget feature. I have over a dozen widgets for lights and heaters running through the mochad bridge on Raspberry Pi, and all of them have at one time or another lost state throughout the day. This is even when the device in question has not changed state for days, but SharpTools will decide it’s now “on” instead of “off”.
Feel free to shoot me an email by using the Send Feedback option in SharpTools and I’d be happy to help troubleshoot. Of particular help would be the logs immediately after you experience an out-of-sync event – especially if you have a way of directly reproducing/triggering the issue.
In case it’s any help in diagnosing, SharpTools uses push events to change the widget state. So when you setup a widget, SharpTools sets up a subscription on the SmartThings platform which will push the event to your phone through Google’s Firebase cloud messaging system.
The reason I mention this is if your phone is having trouble receiving messages for any reason, these messages might queue up waiting for delivery… and then if your phone reconnects, the events would be delivered and SharpTools would update the state at that point. (Sending over the FCM ID from SharpTools Settings > Manage Push events will let me track down if any messages are getting delayed)
And for what it’s worth, I’m also looking at adding a backup mechanism to SharpTools which will poll the SmartThings servers every so often to resync state.
1 Like
Sorry for the delay in responding, I’m back from a trip, and I notice that many of the widgets are out of sync, including those that are straight up SmartThings, and not just the ones that use the mochad to X10 bridge.
I’ll turn on a light using SmartThings, but the widget won’t update for days (even when connected the entire time by WiFi), and will still show the light is off. When I click the widget, it will remain in the “off” state, and the light will turn off, at which point it’s in sync again.
I’d be happy to send you any logs you need if you can tell me how to find them.
Thanks for the update! I would follow the troubleshooting steps from this article:
I would be particularly interested in knowing if the test messages come through quickly, getting a copy of your FCM ID (PM it to me), and seeing a copy of the IDE Live Logs to make sure the events are consistently being triggered and being send to Google for delivery.
Sorry, looks like my replies didn’t get through by email. I tested the widget some more, and it never updated. Once I opened SharpTools, the widgets all seemed to catch up with the state of things. I tried a test message and got the expected responses, and I’ll PM you shortly.
1 Like
Can you send me a copy of the SmartThings IDE Live Logs via PM (viewed while triggering an event for your widgets)? Since the test message is coming through, it sounds like push events are working as expected from the Google side of things as that test bypasses SmartThings. I’d like to review the Live Logs to make sure the events are being triggered as expected and then handed off to Google as expected.
Unrelated but is anyone else having extreme lag or no response from sharp tools
Where are you seeing the lag? When you try to control a device within the main SharpTools app? With push events/widgets? Is it only slow on the first command - eg. do immediate subsequent commands execute fast?
Feel free to PM me or use Send Feedback in app if it’s unrelated to widgets so we don’t hijack this thread. 
I had been using a widget for a while that was working just fine for a Z Wave Lock Reporting device. Today I switched the device type to the RBoy Universal Z-Wave Lock With Alarms. Now the widget is a gray eye looking thing that never changes state. The widget functions normally to toggle the state.
In the app the device shows as a lock as expected and will lock or unlock as expected, though locking results in a quick flash showing locked, then immediately toggles back to unlocked ( lock actually stays locked ).
I have deleted the widget and recreated it several times.
@TimH can you send me your list of Things using the “Send Things” feature from the drop down menu in SharpTools Settings? It sounds like the device type handler may be reporting the on/off or locked/unlocked state differently than SharpTools expects to see it.
For more reference, check out the following post which explains how SharpTools determines how to highlight the icon inside the device cards and widgets:
Tim-
It looks like the door lock supports the motion capability and attribute, so it’s showing that instead of the lock state. Per the thread I linked to in my previous post, I plan on reordering the logic to bump lock toward the top so I expect this to be fixed in a future release.
I’ll reach out to you via email in the meantime.