webCoRE Optional Update v0.3.111.20210130


Optional update – there are a lot of contributions in this release but the dashboard will not nag you to update. Feel free to remain on version v0.3.110.20191010; the dashboard will announce the new version just once.

Some users have experienced unexpected issues with the SmartThings platform before and after this upgrade. Please be safe and grab a back up file for your pistons at webCoRE Dashboard > Backup Pistons before updating.

Thanks to the many webCoRE users on SmartThings and Hubitat Elevation who contributed code to the project over the past year! There are improvements both to the dashboard and the SmartApp code. Code can be updated from GitHub in the SmartThings IDE at account.smartthings.com, or save and publish the code by copying it from GitHub. All of the changes in this release can be reviewed on GitHub.

While I have your attention, check out the experimental dark mode dashboard by @tyron over at https://staging.webcore.co. It is not included in this update, but may be in a future release. Please report any issues or suggestions here.

Dark mode teaser, not in this release – read above


  • Setting a value to the special *CLEAR index on a list variable resets to an empty list (@bangali and @tyron) thread
  • ST App > SmartApps > webCoRE > Settings > Security > Reset access token allows a self-service fix for certain ST account issues that have affected a number of users. Read the warnings particularly if you use External URLs for pistons.
  • New “optional updates” concept gives a one time announcement of new smart app code releases. The nag message only remains at the top of the dashboard if we release a mandatory upgrade.


  • Too many fixes and optimizations to list (@E_Sch)
  • Fixed “There was a problem loading the dashboard data.” false alarm on every fresh sign in and when switching between instances
  • Fixed hub power source events (@bjones14) pull request
  • $response populated for all 2xx statuses except 204 No Content (previously only 200 OK populated $response) thread
  • Asynchronous HTTP requests for better performance (@E_Sch) pull request
  • Significantly reduced computing overhead on dashboards that use a large number of tiles, especially those containing images

webCoRE running on the SmartThings API?

The ST Rules API seems to have remained as-is since it was announced in 2019 and I have not heard any news from SmartThings. The new webCoRE code that was under development in anticipation of that API did not advance in 2020 because the API supports only if/then, every, sleep, and sending a command to a device. SmartThings has left the groovy platform partially intact for webCoRE users but it is not clear when we will be able to work on anything new and future-proof.

Announcement - Changes to Legacy SmartThings Platform
Smartthings & Hubitat in one dashboard?
pinned globally #2


Just want to say thanks for continuing to put work into this project. I’m sure I can speak for many if not most of the other hardcore SmartThings users that webCoRE is one of the most important parts of using SmartThings.


Fuel streams and dashboard registration may be down as of a few hours ago. This is not related to the code release, just coincidentally unfortunate timing of an expired certificate. Hopefully @ady624 will be able to fix it today.


Thank you @ipaterson For maintaining webCoRE. It continues to be the rock in my smartthings world. Web core has been stable while the new ST app fluctuates too much with its level of dependability. Thanks everyone for your updates and hard work.!!


Other than the awesome dark mode contribution, I’m thinking about adding a few features related to backups. I have fulfilled a few dozen requests over the past year to restore lost pistons from backup bins. Several hundred pistons were recovered successfully but many were lost, either due to not having a private backup code to look up the remaining pistons or to not enabling piston backup.

Backup files are private and portable. You can’t restore backup bin codes from ST on a HE hub but you can restore a backup file. If your HE hub is bricked a backup file can be restored to a new hub while the backup codes will not work. The restore process is smooth and even guides the order in which pistons should be restored to ensure that the simplest pistons are created first before others that may need manual review or that use Execute Piston to call other pistons.

There has been a lot of uncertainty lately; let’s become good stewards of our data by backing up pistons regularly. Any thoughts on these ideas?

Encourage periodic piston backup

Add a backup reminder in the dashboard with an option in the smart app to control its frequency. Additional option to reset that reminder any time a piston is saved regardless of time since the last backup for the most cautious among us.

The reminder would be tracked in the smart app, so you would see it on any platform when it’s time to back up and it would be cleared by downloading a backup on any device.

Include global variables and settings in the backup

Currently the backup includes only piston data. It may be difficult to accomplish this but the ability to restore global variables and other dashboard settings would be terrific for migrations and recovering from a total loss.


Big shoutout to @ipaterson and nh.schottfam for their continued support for webCoRE. The future on the ST platform might be in question, but the portability and local performance on the HE platform will drive new user adoption for many years to come. Thank you!


Tried to update, but it gone wrong somehow.
I raw code copy/paste updated all four web apps individually , saved and published each one. Now I can not login to see my pistons again after i enter the 4 digit generated code from webcore smartapp and after that I enter authentication code, but here the spinning wheel just keeps spinning.

One thing I remenber that I forgot in the first place was to push update after each smartapp update in Samsung IDE. But did that aftewards and the smartapps turned blue again in IDE, but with no luck.

I then tried to revert back to the old version v0.3.110.20191009 release, but same issue.

Any suggestion here for this issue?


Are there any errors at account.smartthings.com > Live Logging? Sometimes if there is an error loading dashboard data you can see an error logged each time you refresh the dashboard in your browser.


Live logging response when trying to login:

19.02.03: error Dashboard: Authentication failed due to an invalid token


That sounds like it would be fixed by the new ST App > SmartApps > webCoRE > Settings > Security > Reset access token in the latest version of the app.

Basically something gets screwed up in the ST account where the token that webCoRE uses to communicate with your smart apps becomes invalid. The security option described above generates a new token for webCoRE.


Shortly I was logged in but with loading failure of devices and the request to log out and in again, but still logged out :frowning:
In Smartthings IDE live logging repeatly began to show this after I reset the token:

19.48.22: debug Generated list of null-194 of 194 devices in 11884ms. Data size is 1111

Ps and now i have two instances of webcore in live logging, but one of them is not logging anything


Managed to catch the exact failure message after login:
There was a problem loading the dashboard data. The data shown below may be outdated; please log out if this problem persists


This message is normal and with that number of devices you may see it a few times. Each request loads as many devices as it can in 10 seconds to avoid getting terminated by the ST platform, then the next request picks up where it left off. Looks like there is just a typo in the log message that causes it to show “null” rather than the actual device offset.

This is also normal; one corresponds to the Storage smart app and the other is the primary webCoRE smart app.

If version 0.3.111 seems to not be working can you try the previous version again now that the token is reset?


I updated to this new version in the IDE. However, when I launch webCoRE’s dashbord inside the SmartThings SmartApps, I get this message “A newer UI version is available, please hard reload this web page”. How do I reload this inside the app? If I go to edit any of my pistons on my PC browser, the UI version in the comments shows as being the new one. If I do the same from within the SmartApp, it shows the old UI version. Also, within the SmartApp, my piston logs are all blank except for listing the ms of each line, but not inside the web browser, where the logs look okay. I don’t get it.

I’ve tried the Clean up and rebuild cache. That did not solve anything. Bythe way, I’m also running the webCoRE app for gps tracking as a presence sensor. When I look in it, it also shows that I’m running the latest version of webCoRE.


PS. Those issues are present in the webCoRE in my SmartThings on my Samsung Android phone. I just launched ST on my iPad and it’s perfectly fine. No error messages or telling me my UI is out of date.


I tried to roll back to 0.3.110 as you suggested, but at first i didn´t help. Then I tried again, but this time I reset the token first before installation of the 4 smartapps.
thankyou for your support.

Ps do I have to udate to 0.3.111 are there important changes?


I don’t know if the SmartThings Android app allows refreshing or if it has other customizations that affect the dashboard. Please load dashboard.webcore.co in a mobile browser or use the webCoRE mobile app if it is still available from the play store.


Glad to hear it is working now. If the old version was working for you there is no need to upgrade for the bug fixes described in this thread.


Sorry, but I have not “Reset access token” in my new app …


I just see when my piston executes now this comes up in the logs:

WARNING: Results may be unreliable because the child app’s version (v0.3.111.20210130) is newer than the parent app’s version (v0.3.110.20191009). Please consider updating both apps to the same version.
Leftover from the 0.3.111 update still in the code after revert?
Does this have any kind of impact on pistons not executing well?