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.
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. 
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:
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.
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 
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.
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).
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.
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.
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.
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.
Another great explanation of where we find ourselves. I really appreciate your insight.