I can empathize with the frustration of losing WebCoRE. Sorry you’re having to go through that. 
What do you feel is missing from SharpTools? We’ve had an influx of WebCoRE users and are actively working on features based on popular request.
5 Likes
Me too. I just came up with a specific example for the Rules API where it seems like ST may have abandoned previously announced plans, which (if true) is a decision that I can easily imagine making engineering, financial, and business sense. I can also see it making engineering, financial and business sense to provide the products and services that they do provide.
If users would like to use a GUI for Rules that is fine by me. I might use one myself. It would be nowhere on my wish list for ST to provide themselves though, and I’d much prefer it to be a community/third-party thing.
2 Likes
Wow, thank you everyone for your thoughtful suggestions and links to other useful posts. It’s caused me to rethink some of what I originally posted here regarding a long term plan for my home automation. I have nearly 40 complex automations that I’ve spent years building and thousands of dollars getting devices to support. It’s something that, years ago, I’ve devoted way too much time to, and placed way too much trust in when it comes to the functionality of my home (such as automations that control whether water even enters my home and is heated). From the posts here, there is so much support for abandoning SmartThings entirely in favor of other tools, and I really do want to get on board with that. My immediate problem is one that I think is probably shared by at least some in the community and that is that when I created all of these automations, it was a time in my life when I wasn’t working 2 jobs with 3 young children at home. I don’t even know when I’ll have time to look into options like Hubitat and Sharptools, let alone recreate everything in them. I’m not a programmer. I would rather those who are along with those power users with time for this sort of thing work this out and I’ll meet you guys at the finish line (and I’m even happy to pay you to work it out). I just can’t do any of this in the timeline that SmartThings has given us to do it and really need to move my automations gradually so that I continue to have hot water in my home (or running water at all). For that part, I would be willing to pay someone to keep WebCoRE running in SmartThings, even if just for a time to make a reasonable transition wherever the majority lands on this.
SharpTools is an add-on, not a replacement. You keep the smartthings hub, devices, and smartthings app. But when you run into an automation that you can’t create in the routines in the smartthings app, you create it in sharptools instead. It has a nice visual interface that works in any browser. They have a free trial, so it might be worth looking at, it shouldn’t take too much time. They also have a very active community if you’re stuck on how to do something.
If you need the pro features, it’s $30 a year.
Might be worth a look, I think it’s the least timeconsuming of any of the alternatives right now.
If you do find a developer interested in building a new version of Webcore or at least a visual UI for the Rules API, that’s still going to take quite a bit of time, and sharptools might help you get through the delay.
2 Likes
Porting webCoRE to an environment compatible with Edge isn’t practical or reasonable at all.
- Its 10K+ lines of Groovy, so you’d need a Groovy environment to run it locally. Porting it to another language doesn’t make sense, might as well start over or use another existing rule engine, and if you’re doing that…
- Spinning up this environment isn’t monumental, you could run a Groovy container on a Java VM locally on a PC, thin client appliance or a RaspPi, but this will require work and knowledge to do so. Its not turnkey.
- Besides being in Groovy, webCoRE uses both the SmartApp objects/methods (subscribing to events, accessing the cloud data structures, etc) and the DTH Device objects/methods in a non modularized way. It wasn’t designed to be easily ported to another environment with layers of abstraction for what platform it was on. In theory you could go thru and create these layers, and create a Groovy runtime that instead calls the Edge API as a new style SmartApp would. However…
- In order to receive events, API based SmartApps need to be accessible on the internet, so you’ll also need a bridge running in the cloud (your own, also setup by you) that would communicate with your local Groovy instance (or just run the whole thing in the cloud, but again, complexity and cost).
I’m a software engineer by trade, I’m trying to see thru the Edge transition, and I love a challenge. But unless you had a large commercial interest in seeing webCoRE stay compatible during and past the Edge transition, I wouldn’t bother. There are better options and uses of developers time (like a front end for the Rules API). webCoRE made sense when it was directly supported and written for the platform and was being hosted in the cloud for free. And it was pretty easy to install and support. Moving it to a “sorta works along side” option seems like a waste of time for not much gain. You’re not likely to gain new EdgeCoRE (ha, see what i did there?) users, only the folks that were heavy webCoRE Groovy from the old environment. Sounds like a dead/dying path to me.
If you have a large amount of automation logic invested in webCoRE it makes the most sense to migrate to Hubitat where it can be supported natively. Decide which will take more work - migrating devices to Hubitat and reusing your webCoRE rules, or keeping your devices on ST and migrating automations to the new options. Neither is easy or free, but the DIY route of home automation isn’t either.
Full disclosure: I’m not a webCoRE user so I don’t have any invested interest in either logic nor in its nostalgia for my HA needs. If I was maybe I would feel differently, but I don’t think so.
7 Likes
Take a look at what’s been done in the MQTT integration project. With a local server device you may be able to avoid the cloud piece. It’s shifting the paradigm a lot, but it might preserve the front end. 
it would be a huge amount of work, though. So to me, as you suggested, it would make more sense to use Hubitat for Webcore and maybe use MQTT between ST and Hubitat. You could keep things local but save a ton of development time.
All of which is to say I agree that there are probably more cost effective options than redesigning Webcore from scratch. I just wanted to point out that such a redesign might not require a cloud piece.
In fact, I would suggest that if Webcore junkies want to groupfund something, a local bridge with a visual interface between Hubitat and ST (again, MQTT is one option) would be the most cost effective, as well as taking less time to write. Just a thought. 
Thank you, sir. You may just be one of the most helpful people with whom I’ve ever communicated. This is what I needed to know. The best available solution to match my situation.
1 Like
Another great explanation of where we find ourselves. I really appreciate your insight.
1 Like
Hey, I also just wanted to add that this sounds like the best long term solution to me and if the development community will be the ones leading this effort, I’d be interested in pitching in monetarily to help those who do the coding. I hope that anyone working on this makes us aware of their “Donate” button. I frequented the Donate button on the WebCoRE site.
2 Likes
If power remains between 3 and 8 Watts for 60 seconds, Then do stuff.
1 Like
I had that problem too. I brought that to their attention and was treated like I was being a nuisance and they suggested a complicated work around. I found that you can now do that with the standard routines in SmartThings so I didn’t even bother with SharpTools.
I find it funny that SharpTools does not even have the same functionality that the standard routines have and they seem to be in no hurry to update it at all as all new features have to be voted on before they are considered.
1 Like
How dare they listen to voice of the customer! 
On top of dealing with the new SmartThings architecture and making an automatic migration tool, they are actively adding features to the rule engine Rules / Variables based on Date or Calendar - #56 by josh - SharpTools.io (web) - SharpTools Community
6 Likes
SharpTools introduces new features on a regular basis and, yes, they prioritize the release of those features based on user feedback—an astonishing idea that I wish others would adopt. Also, they were a little busy recently trying to prepare for the end of the groovy platform, upon which they previously relied.
Yes, for those coming over from webCoRE, SharpTools is missing a lot of valuable features. But I don’t want new features “hurried,” I want them to work.
Remember, you can always run Hubitat in parallel for those pistons you just can’t port to SmartThings or SharpTools.
5 Likes
Both of those projects are nice but you need to have the basics in place first. You shouldn’t need to ask to get the same functionality as a standard routine in the SmartThings app will get you.
1 Like
Thanks for sharing the example. You can create a rule which sets a variable true/false based on if the value is within a the desired range and then react to that variable staying true for your desired period of time.
I can understand the desire for a ‘stays between’ type of trigger and would encourage either of you to post a feature request for it. As @Automated_House and @bthrock mentioned, user feedback is a key part of how we prioritize what we work on.
Jimmy linked to an example of it where we saw an influx of WebCoRE users requesting math and date features, so I developed and released a labs feature within 48 hours to help cover the need… and within a few weeks we built it out as native feature since it gained a significant number of votes.
Is this the post you’re referring to?
5 Likes
Thanks for the example, it seems variables are required for most Sharptools rules. Should be called Sharptools Variables 
On the same theme, why can’t you use local variables? The global variables will reach in the hundreds for the average home.
And number 3, how come there’s no “If any” as a trigger? Or is that a variable workaround also?
When any of the triggers occur, the rule flow runs. (eg. triggers are always OR).
You can edit an IF Condition and switch it between ‘any’ and ‘all’ (eg. OR / AND)
The ‘average’ home probably doesn’t use variables at all and could get away with the free tier of SharpTools. I agree that many WebCoRE users fit more of the ‘power user’ profile and are more likely to use variables though.
Why? I use Routines for some things and SharpTools rules for other. I don’t need SharpTools spending time coding things I can do natively. I want them to spend time EXTENDING the native capability.
5 Likes
I think the key to switching from WebCore to SharpTools is to go into with the understanding that it is an alternative solution, not a direct 1:1 replacement and was built using different rules logic. It’s no different than when we first learned WebCore logic or now the Rules API. Things are not done the same but once you learn the logic it’s pretty easy. With all the newly added features I was able to completely move off WebCore and maintain all of my complex automations which include http actions, math and date calculations. Not to mention @joshua_lyon and Jimmy are very active and responsive in the Sharptools community and are always willing to help find solutions or workarounds.
Edited for typos
9 Likes
I mean’t, If any of Switch1,Switch2,Switch3,Switch4,Switch5,Switch6,Switch7,Switch8,Switch9,Switch10 changes to on.
Now in Sharptools it seems you have to write…
If Switch1 changes to on
If Switch2 changes to on
If Switch3 changes to on
If Switch4 changes to on
If Switch5 changes to on
If Switch6 changes to on
If Switch7 changes to on
If Switch8 changes to on
If Switch9 changes to on
If Switch10 changes to on
Quite cumbersome and not very elegant.
And number 4, it seems Sharptools can’t toggle a light like WebCoRE and the ST app.
Can’t you just insert the code to check if the light is on or off and do the opposite?
Having to write each time another rule, If Switch1 is on, then turn off Switch1, Else turn on Switch1 is quite peculiar.
A toggle would be simpler, how many votes would this need if I drum up some support for a toggle feature? Just so I know, would 20 votes be enough?