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.


Webcore groovy deprecated, new integration needed. Where to start?
#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.


#9

Sorry to resurrect an older thread - but my question is relevent to the above…

If it’s possible to run a local instance of webcore for hubitat locally in your home - why should it not also be possible to run an instance of webcore for smartthings in your own home? Surely this would be an excellent solution to the end of the samsung groovy support? It seems to work ok for hubitat users.

Of course, there may be issues with this I just don’t see, with only having experience as a user.


#11

yeah, but that seems to be based on the hubitat system. I’m wondering about doing the same thing but for smartthings, so that it’s still there when Samsung’s groovy hosting disappears


#12

The piston execution code reside on the platform i.e. SmartThings (cloud) or Hubitat (local).
The webCoRE UI resides on a 3rd party platform i.e. dashboard.webcore.co

When SmartThings removes Groovy from their platform then webCoRE goes with it because it’s code is written in Groovy. If the developer decide to shutter webCoRE’s UI (dashboard.webcore.co), then that portion goes away.

If you really like webCoRE and want to keep it, then Hubitat is the best option. Pistons reside on your local Hubitat hub and the webCoRE UI can be run on a local Raspberry Pi, or you can run it in the cloud using your own website implementation.

IMO there is more development being done on Hubitat’s side than on SmartThings, and, IMO it runs far better than it ever ran on SmartThings, plus it can be 100% run locally.

The only gotcha that I can see is webCoRE’s UI makes some calls to other 3rd party sites, such as when registering a browser. I am far from a groovy or HTML coder so I don’t know enough to say if that would be a problem if the webCoRE project is terminated on SmartThings. But if the original developer pulls the plug on dashboard.webcore.co I feel pretty confident that it webCoRE will live on through Hubitat.


#13

ah, I see. I thought the groovy in hubitat was in the local RasPi. if it’s on the hub then that makes more sense. Thanks for the explanation.


#14

Strong second that opinion. If you are a webCoRE user; Hubitat is probably a slam dunk for you to migrate and enjoy. It still has some work to pick up the novice IoT user.


#15

Hi, very interesting! I just try to find a way to save webcore because it would be a big step back to loose it… Do you think it could be possible to host webcore on a home computer or something and then link it to hub devices? A kind of home made IDE to run the smart app and just send the signal to the hub when action is needed?

I use a lot of variable, web request and so to automate and its a real nightmare to me since I wont be able to do anything interesting! Just tell a light to be on when a simple event occur is pretty annoying! Sprinklers according to last 24h rain is more usefull then just telling precise time to go…

Is this so much effort to convert it? As I see it seem to be close but no ideas how to do and no guidelines…

I was thinking that webcore could maybe be converted into drivers or something… like just been able to install it on the hub and use it like with smartapp but at the end just tranfer pistons data to rules api…

Thanks!


#16

I think its so weird and a bad buisiness decision, they just had to take webcore and make it run locally with the possibility to update it and they would have something strong and they could have rules api or other things but for now webcore is superior by far and they completly rebuild a rules api…and deprecated the rest…?? They daid it ll be good for 99% of users? Not sure! We all buy those hub and devices to automate our home and the minimum would be to get stability… Now its groovy server and after that what? We need to rebuild automation and not all automation will work… Its frustrating!


#17

Just a question because I try to find solutions, Is there a way to install webcore on a pc or rasberry pi or else and then be able to link it with ST to get devices… maybe by using their new drivers or something? Because its the smartapp that need groovy to works, so maybe it could be a solution?


#18

The webCoRE user interface can be installed on a Raspberry Pi or some other Linux type of platform. I have webCoRE running local on a Pi and I also have it installed on a Oracle server just to see if I could do it.The pistons are all local on the hub. I converted from SmartThings to Hubitat a few years ago. At that time I ported about 100 pistons and it took a better part of the day, most time spent was moving the physical devices from one hub to another.


#19

can you tell me how you have done to install webcore elsewhere? With ST or Hubitat you need to install the smartapps on their groovy server… So how to make it run on the pi or somewhere else? I think I maybe find a way to link it with the new rules api to interact with devices but I just dont know where to start to install webcore… If its the only way I would buy a hub but if I can just install webcore and link it it would be nice!
Thanks!


#20

Only the web interface run on the Pi and is served by a standard web server running Apache. The actual apps are stored and executed on the Hubitat hardware that you purchase. The Hubitat forums have all the detailed instructions on how to run the web interface on a Pi. Just to be clear, you only need a Hubitat Hub to be able to run webCoRE. That is the most important thing to move on because that is the part that’s being removed from SmartThings. You can still use the same https://dashboard.webcore.co/ that you have always been using.


#21

yes, that exactly what I was thinking but was not hundred sure… I think I would have no choice! Nobody seems to worry about on the webcore side and on the ST side there is nothing to do! They want to takes all ideas and check if they could integrate it…but I know that its a hudge step back and it would never looks like webcore! Some of my pistons could be transfered if edge can send http request outside the lan but some not because of variable and also variable events… That seem to be complicated their new api and all that stuff to regress to maybe be better within 20 years… If I have known I would have buy Hubitat hub from the start!