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.
@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.
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.
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.
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.
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
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.
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.
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…
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!
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?
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.
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!
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.
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!
Thanks @brutal for updating this thread with the news.
The other good news of course is that ST users who are all in with webCoRE and don’t want to lose it, can continue to use webCoRE on ST after Groovy shuts down by having it run on a hubitat hub, their devices stay on ST, and everything works as before.
As the chief tester of the app that makes this possible, Replica, and the author of this thread, I couldn’t be happier honestly. Also happy this thread got the attention it deserved and wasn’t merged into a broader thread as was asked for below.
@Bloodtick_Jones is one of our more brilliant webCoRE forum users/coders I wrote about above, and came through for us, just in the nick of time!
