Plan for Updating WebCoRE SmartApp

I understand the benefits of processing automations on the hub. I understand that there is value in making simple automations more accessible to average users; however, doing so at the expense of making complex automations less accessible to power users is short-sighted and will be the end of SmartThings unless a responsible transition plan is developed (apparently by customers since Samsung does not seem willing to develop a responsible transition plan of their own). Samsung wants users to utilize their API for complex automations? Great! Let’s formulate a transition plan that gives users ample time to transition where both systems work concurrently, with a reasonable timeline for sunsetting the current solution. In order to do this, WebCoRE needs to continue to operate in the SmartThings ecosystem until the SmartThings team can develop a system built on their API that is as usable by non-programmer power users as WebCoRE is. If instead Samsung wants to get out of the business of complex Smart Automations, that’s fine, but they need to be honest with their customers about that intention. If the SmartThings team has no intention of building an accessible system on top of their API that can be used by the average power user, then any potential solution will need to be developed by the community of users and therefore, need to live in the cloud.
I as a very long time WebCoRE non-programmer power user am proposing that the community of power users get together and be willing to crowd fund an initiative to write a bridge on top of the new SmartThings API that will connect SmartThings to WebCoRE the way that the current WebCoRE SmartApp does. If Samsung is unwilling and uninterested in ensuring a smooth SmartThings transition, then we as customers are our only hope. I am willing to contribute money to keeping SmartThings in the business of complex home automation. Who is with me and who is willing to work on this and let us pay you for it?


There was a similar suggestion in this thread.

1 Like

I and many people would be willing to pay. You’re right it seems today it’s up to us users. SmartThings teasing their own official webCoRE based on the Rules API had kept us waiting, it seems they have no intention of releasing it, or handing over the basic code of what Adrian already built. SmartThings should of been clearer.

Especially seeing how Sharptools is so inadequate.

It seems like a reasonable approach for those who are interested in it. :thinking: There are a couple of other thirdparty alternatives that are available now, for those who would like to consider those. They are discussed in the following thread:

Replace Groovy with Automations—what’s your plan?

I agree, they have not been clear about their trajectory in their public announcements, but their actions seem transparent. They will leave the Rules API available for power users willing to go to the trouble of learning it, have the rest API for third-party integrations, and otherwise it’s basically going to be what you can do with routines.

It may be helpful to remember that at this point over 90% of their customer base doesn’t have a hub at all. They have a Samsung smart television or smart appliance, and they want to add some home automation to that, but nothing on the level of Webcore.

Samsung employees have posted multiple times to this forum that even before the unification of the apps the vast majority of their customers had 15 or fewer devices and never used any custom code.

So the people who did use Webcore were a small minority of what is now a small minority.

It may still be enough to justify the kind of project that you’re talking about, and I wish you every success if you go that route, it’s just that power users as a group are clearly not that significant to the success of smartthings long-term from Samsung’s point of view.

I’m sure they will miss us when we’re gone, but in a lot of ways it’s probably easier for them if power users go to a platform (home assistant, hubitat, homeseer, whatever) where power users are the majority.

Just my observation, there hasn’t been anything official on this.

1 Like

I really wanted to come up with a helpful response to this thread. However I have decided it is beyond me.

It just gets me too worked up.

Perhaps I need to slightly overstate my views a bit so it is clear what side I am on here. I have spent hundreds of hours trying to help out webCoRE users on this forum, the webCoRE forum, and on Facebook. I still do even though I haven’t used it myself for a year now (perhaps more). You know what? I’ll be dancing a happy dance when it goes.

It was an interesting and effective solution to a real problem in its time. That time has gone. As far as using it with SmartThings goes it is a ******* silly one now. If you want to use it going forward get a Hubitat hub. It just makes more sense there. Bespoke SmartApps are now a far better solution for complex logic.


FWIW, The Homeseer app has had less than 100,000 downloads on the Google playstore, and it’s still a viable system.

The current SmartThings app has had over 500 million downloads, so even a small percentage of that is a large group within the space.

As an ex-programmer (alas with little SmartThings knowledge) I would advise doing detailed documentation of your existing WebCoRE implementation (you may already have this). It will come in handy.
Without knowing the detailed history, I suspect WebCoRE (like Rome) was not built in a day; and it’s replacement (and there will be a replacement; in the absence of a mass exodous) will be built, over time, to a complete replacement.
That is the limit of my crystal ball; I could be wrong :slight_smile:

1 Like

You agreed with my finger slipping and submitting a post which I thought I had abandoned.

I actually don’t think there are sufficient power users for it to be viable for SmartThings to do too much to accommodate them apart from help them to help themselves. Hasn’t it always been that way though?

As an example, the Rules API is one of my three favourite things about SmartThings (another is the CLI) but I can’t actually think of a good reason why they would want to develop it too much further than it already is unless features are useful elsewhere (e.g. variables and expressions could be things in their own right). It makes more sense to move up to a custom SmartApp. Similarly it probably doesn’t make any sense to create a GUI based Rule creator unless they need one internally.


I am not willing to contribute money to this. There are better solutions out there for those who need this kind of advanced scripting and automation support - unless Samsung is willing to build the necessary ecosystem to TRULY support the advanced users, (they dont support more than 200 devices, more than 200 automations and limit the number of elements IN an automation - and walked away from an advanced scripting UI for the Rules API?) which IMHO they aren’t… So why would I put my own skin in the game?

If the platform owner isn’t invested in my success, I won’t be invested in theirs either. I’ll use my money to buy the gear / services that DO let me do what I want.

1 Like

I’m not aware that SmartThings ever teased any such thing. When @ady624 (a SmartThings employee at the time) last made a presentation on the topic some years ago, he made it clear that building a webCoRE-like interface on top of the Rules API was something that would have to be done by the community.

Unfortunately, many users interpreted this to mean something very different and false information spread in various places online, resulting in unrealistic expectations and unnecessary hand-wringing by webCoRE users.

A former webCoRE (ab)user myself, I posted elsewhere about my own transition and views on the alternatives, so I’m not going to repeat that here. While I’m still using webCoRE a little for a couple of pistons I haven’t yet been able to replicate in the Rules API, in general I agree with @orangebucket: It’s time to move on or move over (to Hubitat).

1 Like

I think there are things that make sense from an engineering standpoint, and things that makes sense from a financial standpoint.

When it comes to user interfaces, I’m a big believer that “your use case is not my use case“ and that choice is good. I can’t use my hands, so my household is all in on voice control. But I have friends who can’t verbalize well, and voice options are irrelevant to them.

There are people who will be happy to write their own bespoke smart apps, and @TAustin , @blueyetisoftware , and @lmullineux have already done some amazing things just with edge drivers. But there are other people who just want a visual interface that doesn’t look like code. SharpTools or NodeRed might work well for those, but something more specific to smartthings could be good too.

So I’m happy for anyone to invest their own time and money in whatever makes sense to them, whether individually or as a group, once they know what the options are.

Submitted with respect.

1 Like

I can empathize with the frustration of losing WebCoRE. Sorry you’re having to go through that. :worried:

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.


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.


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.


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.


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. :thinking:

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. :sunglasses:

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