Addressing the end of webCoRE


#1

Without official confirmation, the end of our webCoRE was indirectly confirmed by a Samsung employee a few days ago, something I’ve been dreading for 2 years now, as webCoRE is the most important part of my smart home.

First let’s go back to 2019 and the Samsung Developer Conference, the father of webCoRE (@ady624) made a great presentation showing webCoRE running locally on the hub, using RULES API. Great, fantastic, he signed into another local instance of webCoRE and showed he could make some pistons, all running locally.

At the time, Samsung was saying how they recognised how important webCoRE was to the community, and how they would be rebuilding webCoRE to work with the new API.

The presentation was entitled “Conquer IoT Automation with a Rebuilt webCoRE”, and as ST poached Ady to work for Samsung (specifically for how amazing his work on CoRE and webCoRE was) I thought webCoRE was in good hands. In the presentation, there were no variables yet or anything complicated, but in 18 months/2 years, if Ady was working on it, they should all be possible by now, unless Samsung have had Ady working on other parts of the platform, in which case he has been taken away from the community just to work for Samsung.

Here’s my question to Ady a few days ago on an ST forum thread about the new firmware…

Hi @ady624, I’m hoping you’ll be able to answer a question I’ve been waiting 18 months to ask you actually. Many of us avid WebCoRE users earnestly watched your impressive Samsung Developer Conference 2019 presentation of WebCoRE harnessing the Rules API and running locally on the hub, in a very fast and lightweight manner. At the time, you said “soon” it would become available, as 18 months have passed now, are you in a position to say when WebCoRE will be able to run locally (even without variables if necessary)? Because as an average user of moderate intelligence there’s no way I’ll be intellectually equipped enough to use the CLI, Postman or write JSON files, it’ll never happen, so a local WebCoRE with Rules API is what many of us are waiting, hoping, praying for… :pray: :pray:

Strangely, Ady didn’t respond, even though he was active before on the thread, I posted right after him, then radio silence, which is ominous in itself. 24 hours later another Samsung employee posted, one that regularly doesn’t shy away from answering difficult questions as best they can.

“”"""

who is going to take on the job of turning webCoRE into a rule generator instead of a SmartApp generator

We are creating a web-based, rule building GUI that allows similar functionality to WebCore but based on Rule API. I’m not going to go into more details at this time since it’s still a PoC and needs additional development work, but it exists.

The functionality in the rule builder and near-term roadmap for the Rule API are based on an extensive metadata analysis of active WebCore pistons, an analysis of the core functional needs of the most popular SmartApps, and the feedback we’ve received from the community.

blkwll:

> It sure would be swell to have, at least, WC to JSON conversion

This is also in the works and will be made available before anything happens to WebCore. There will likely be some manual work involved for users (i.e. post the converted JSON to Rule API using the rule builder) but it is planned to be minimal and straightforward.

“”"""

This doesn’t sound like the rebuilt webCoRE we were promised running locally on the new platform, this sounds like the end of webCoRE that we know and love. It sounds like they are just going to release a simple web gui that may look like webCoRE in appearance, but that will turn simple pistons into rules and convert them into automations where they will live as one off pieces of code. And when they turn off groovy this year, webCoRE will be gone.

Whats particularly worrying, and VERY bad news is this part… “The functionality in the rule builder and near-term roadmap for the Rule API are based on an extensive metadata analysis of active WebCore pistons, an analysis of the core functional needs of the most popular SmartApps, and the feedback we’ve received from the community.

So no more piston states, no more sharing of pistons, copying other peoples complex pistons, no http requests, no communicating between hubs and sending variables back and forth, no nothing, we will probably be left with a simple rule builder that does 30% of what webCoRE can do today, 30% at best. No sending of photos dynamically from a Raspberry Pi to an ActionTiles tablet.

No rules like at sunset wait randomly between 1 and 30 minutes and if wind speed is less than X then open an awning but IF a certain motion sensor is active, then wait until a different motion sensor is active then open the awning, but if wind speed rises above X during the night then close the awning.

So if anyone is still waiting for some clarity or honesty from ST/Samsung about the end of life of webCoRE it’s not going to happen. So either the community somehow get together to try to save and reprogram webCoRE for the new RULES API or if we leave it to Samsung, when they turn off groovy THIS year (2021), the webCoRE that we know and love on the ST platform, will be gone forever.


#2

Thanks for posting this. I suspect that Adrian can’t comment as he will have some kind of NDA with Samsung, but we do need some solid information.

My lockdown time has been spent sorting out my home automations, moving everything to SmartThings and WebCore. I felt that doing this allowed me to build flexible and reliable integrations - it’s been quite an investment, but everything is now working perfectly and I am happy.

We need some answers. Will WebCore disappear and if so, when? Will it be re-hosted? Will we be able to migrate our pistons to a something else? We need an understanding of the plan with dates or we should all assume we need to take action immediately.

I’m going to start to look at alternatives today. What are the options? Hubitat gets a few mentions. Does Sharptools have a brighter future on SmartThings?


#3

The easiest keeping your work is to change to Hubitat. That said it can be 1:1, or it could be figuring out some device or integrations depending on what you use. It also removes most of the #1 architectural issue of ST which is everything requires the cloud to operate in one way or another. I know they mention options for local, but I have not seen anyone describe that in practical action when the internet is down for a week for a more complex automation environment.

HE’s weakness is in the mobile app. That said, many folks use homebridge (iOS phones), and this can provide direct mobile control if needed. You can create custom / nice dashboards in HE, but this requires much more effort than most other platforms.


#4

#5

@WCmore Can we move this into the original thread to which @jkp has linked?


#6

@bthrock and @jkp I appreciate your reading my post fully and wanting to engage, but please keep your posts on topic. The thread that @jkp linked to couldn’t be on a more different topic entirely, “Changes to the Legacy SmartThings Platform”, and as it says in the title “(Non WC related)”.

So either you guys are on hubitat or have ulterior motives for hiding this thread, this thread is specifically about webCoRE, for people who love and adore it, and want answers, I’m hoping the man himself will comment on its future, or else some of our more brilliant webCoRE forum users/coders can make the time to rescue webCoRE before it’s permanent demise on ST later this year.


#7

A few years ago I moved all my webCoRE automations over to Hubitat, for which I couldn’t be happier. webCoRE atomations run local and the UI will run local after setting up a local webserver, usually on a Raspberry Pi. I run a Pi3 for both webCoRE and node-RED.

Now for a bit of possible bad news. The only thing I found requiring internet access (ie. webcore.co) is for Registering a New Browser. It appears there is special code provisions that are not part of the local UI. I don’t know what would happen if the dashboard.webcore.co was turned off. I suspect whatever process they are using to authenticate comes from outside dashboard.webcore.co because I blocked all access to it through firewall options and it still worked getting the code. It would be nice if someone with working knowledge of groovy, java script, python and html to figure out how this authentication process works. If that can be addressed then it won’t matter if they pull the plug on the UI.


#8

I don’t have more information than you folks other than some experience with the code, but here is a best attempt at commenting on some of the questions in this thread:

I wish we knew the specific features, there is so much uncertainty here. I am hopeful that the rules will be shareable to allow some community to exist. The data is in a much nicer format than pistons in webCoRE Groovy, but sharing also implies anonymization – if I paste the JSON for a rule it’s going to have at a minimum all of my device IDs used in the rule.

Since it is only possible to support what the API supports we don’t gain much here. I am hopeful that ST moving forward with their own rules editor means that they can achieve a faster development pace.

Absolutely not, the costs, infrastructure, and liability of running Groovy webCoRE in the cloud on a clone of the ST platform are unfathomable.

Just to underscore this, Hubitat runs Groovy webCoRE and other smart apps and device handlers locally. I have a ST hub and a Hubitat hub with webCoRE on both accounts. I load up both locations in my webCoRE dashboard. I haven’t started any full migration yet but have a couple pistons running locally on Hubitat.

I’m not sure if everything is 100% supported but it’s trivial to export all of your pistons to a file from ST and imported them into Hubitat. Like when you restore a piston from a backup code on ST, webCoRE will prompt you to choose the devices and other missing data in the target platform.

I can’t imagine any way that ST would be able to support importing pistons into the Rules API. It may certainly be possible for simple pistons and someone might write code to do just that, but the data structure backing pistons is garish. Reverse engineering that in order to port data to a different platform, even assuming feature parity with the new platform, would be extremely difficult.

This is correct, ady624 operates several servers that do things like host up dashboard.webcore.co and the community, broker dashboard registration, collect fuel stream data, and store encrypted piston back up bins. As far as I am aware, no one else has access to the administration and billing for those.

This is a difficult question to answer. Certainly sounds like the Groovy platform will disappear. The servers I just described are at the greatest risk of eventual shutdown. Those could be reverse engineered and hosted (or made obsolete by local processing) by someone else for Hubitat.

The dashboard and smart app code is open source and forked by many so that would not be able to disappear, and it continues to run locally on Hubitat thanks to the work by the developers involved with the HE fork.

Do not rely on automated piston backup (private bin codes).
Your piston backups are encrypted based on the ST account ID and cannot be restored to a different account or to Hubitat. Hubitat users may not be able to restore private codes to a different HE hub (hardware identifier).

Use the Backup Piston(s) menu item in the dashboard regularly. Restoring from a backup is easy, it’s better to have one backup file with all pistons than one file for each piston because New Piston > Import piston from a backup file has a wizard that guides you through the import process.

Seriously, do not rely on automated piston backup.

One option would probably be providing the local network API URL for your webCoRE smart app on the registration screen rather than a code. The centralized registration code is convenient for ST but may not be necessary on Hubitat. It’s basically a shortcut so that you don’t have to copy and paste the long URL that the browser uses to communicate with your webCoRE smart app. This is also a simple API to reverse engineer.