So just to be clear, I’m still in old connection, which means I’d have to use beta to use next gen sharptools correct? And now that next gen is live for new users, world old users with beta automatically merged (migrated) to release version of next gen?
We’re still wrapping up the migration tools for users with legacy connections, but once they’re available you’ll authenticate using the next-gen connection and then run through the migration process which will update your rules and dashboards to use the new connection.
Yes, if you already have a legacy SmartThings connection, you can join the beta to setup a next-gen connection side-by-side your existing connection. We’re still working on the migration tools, but if you’re fairly new to SharpTools and only have a few rules, you could always manually update your rules. 
2 Likes
What a bummer, ST is nearly useless without WebCoRE. The new rule engine cant even come close to the complex pistons in use out there. I’ll keel over before I pay a subscription to any alternative service just to keep my home automation running! Take me back to 2014!
1 Like
not sure why you’re concerned, aren’t you using Hubitat now?
TBH, the risk was always there using a free, third party service. The current webcore devs have chosen to not make it work with the new ST platform. Perhaps if they were paid they would be more motivated to adapt it 
2 Likes
I have family still on ST, who I reluctantly act as tech support for.
I thought they made ad revenue from it and donations?
It looks like Adrian recently left Samsung, lets get him back in the CoRE saddle! (is his account still active here?)
no, his account doesn’t exist anymore
1 Like
I believe his account was deactivated here and on the webcore forum. I’m sure he had some interesting terms he had to agree to both joining and leaving Samsung…
3 Likes
So in conclusion, webcore in SmartThings is really going to die…
2 Likes
yes, on September 30th
3 Likes
There is a non subscription option, but it requires running 3 systems and being ok with a very Rube Goldberg approach…
- use ST for whatever you like about ST
- use hubitat to run Webcore and whatever other groovy you can’t bear to lose.
- set up virtual devices as proxies.
- use MQTT to communicate between ST and Hubitat, thanks to @taustin’s new project. (You need another device here to host the new platform smartapp that manages the MQTT
integration on the ST side.)
It’s complex and only for power users, but it should be doable. 
1 Like
The base SharpTools Rule Engine is free too. A subset of features like Variables and HTTP Actions are part of our paid tier which more advanced WebCoRE users might need… but if you aren’t using those and just want complex conditions, nested conditions, etc. you get all those for free with SharpTools Rule Engine.
2 Likes
September 30 is the switch off of groovy smartapps? That’s too soon…
I spent the weekend migrating my webCoRE pistons over to SharpTools. For the most part I succeeded. However, since SharpTools doesn’t allow multiple separate routines in one rule like webCoRE does, I had to change the logic on a few routines and split quite a few into separate rules.
The interface of SharpTools Rule Engine is pretty, but it’s a bit too much (and too large). I would like the ability to change the view of a rule to look similar to that of a webCoRE piston. I ran out of real estate real fast when setting up complicated rules with multiple IF>THEN ONLY IF>THEN statements.
I also ran into an issue with webhooks not working. However, that’s more of an issue with Plex and not webhooks in general since Plex uses a non-standard way of sending JSON data. I posted the problem in the SharpTools forum and their staff was very quick to respond and after discovering the issue they said they would look at fixing it in a future update. I like that support. (Thank you @joshua_lyon)
I’m sad to see webCoRE die, but if SharpTools continues to keep the platform updated it’s the closest alternative.
4 Likes
We pushed an update to support the weird Plex format too (very bizarre JSON encoded inside a multi-part form format)! 
4 Likes
Really sad to see webcore go because you simply cannot do certain complex automations within ST itself, which is a real shame. Imagine being able to run these complex automations and also have it run locally.
I can but dream. Or move system.
Their plan has been that the Rules API would have feature parity with Webcore, but would be able to run at least some recipes locally. They aren’t there yet, but it does offer a lot more complexity than what is available in the basic app routines. And it is still in development, so hopefully more to come.
Is this what we’re hoping the "Custom Routine Creator?
The stated plan was for the Rules API to have broadly similar capabilities to webCoRE, with the understanding that webCoRE has a few incongruous features. I am a fan of the Rules API and the only reason I have any Routines is because they have access to Rules that haven’t been made public yet, and the only reason I use Scenes is because there isn’t an action for executing another Rule yet. However the Rules API doesn’t seem to have developed significantly in terms of capability over the last three years compared to the stated aims. Much of what I have seen happening could perhaps be described as refactoring that has, in my opinion, improved things greatly, and there has also been rationalisation. The ‘was’ rule has been deprecated, for example, but as far as I could see it wasn’t doing anything that couldn’t be done by ‘remains’ and a basic grasp of binary logic. So what it does it is doing much better, but it doesn’t seem to be doing a great deal that it couldn’t already do quite a while ago.
What I am not seeing is any of the headline features like variables, or any sign of loops. I think there is a lot to be said for variables being a ‘thing’ anyway.
There was talk of a graphical front end for the Rules API. I’ve always had mixed feelings about this as a key strength of the Rules is that they are text.
That sound a long long way to go if they are really “aiming” toward the stated goal, and if they do that will be fantastic for users who rely on webcore pistons!
It would be good to know if that is still the aim. I would quite understand if plans had changed after a period of reflection but someone really needs to say something as a courtesy to the users who have been led to expect so much more.
6 Likes