webCoRE is going away and it’s not coming back. PLEASE quit asking, no one is going to invest the time to try and repackage it for the new API. Even if they managed to do so it would be buggy and everyone would complain about how the groovy based webcore did this or did that.
It’s going away, embrace the suck and rework you system or go to hubitat.
I think each person has to decide for themselves what they want to do, including trying to organize a new version of Webcore or a new UI for the Rules API if that’s the direction they want to go. Maybe they’ll make it, maybe they won’t but it’s their time and money.
Way back when Adrian first suggested Webcore I was one of several people who didn’t think he’d be able to do it. And obviously I was way wrong on that one, it was brilliant work. 
Since then I’ve learned not to try to guess what other people are going to be able to come up with. This is a very creative community. I’ve been really amazed at what some people have already been able to do with edge drivers. And @taustin ‘s MQTT integration is awesome. Plus I never in 1 million years would’ve thought that @lmullineux would be able to build an edge Driver for harmony that didn’t require a server device.
https://thingsthataresmart.wiki/index.php?title=Quick_Browse_Lists_for_Edge_Drivers
I don’t know what will happen with Webcore other than the fact that there won’t be a free Groovy cloud to run it in. 
As you say, it’s going to keep running over on Hubitat and that’s a definite option for a lot of people. People who want to stay with ST May find SharpTools A good choice, or be willing to put in the work to learn the rules API. 
As far as complaining… i’ve been complaining since 2018 when they first broke voice navigation in the app and it’s never been fixed. I try not to be meanspirited about it, and I accept it when anybody else says they love the app. But it’s still painful and I still complain from time to time, particularly about the distance between their mission statements and their product delivery in this particular area. and I still keep a little bit of hope that someday they’ll fix it. 
Anyway, if it makes somebody feel better to vent a little, I don’t mind. Again, as long as they’re not hostile about it. The change is aggravating and infuriating and annoying and all that. And we each have to pick the path forward that works best for our own needs and preferences.
So if you love what’s coming, great. If you hate what’s coming, I understand, and as a community we can do the best we can to help each other figure out what the alternative options are.
We can’t say we weren’t warned: the smartthings terms of service which everyone agrees to when they set up a SmartThings account says the company can change anything at any time without notice. No promises of continued operation. But that doesn’t mean the changes come without pain.
JMO, of course.
@JDRoberts I completely agree with you. However it’s getting old seeing almost everyday someone complaining about it or wish some programmer is going to popup and recreate something that took years to build in just days.
It sucks that it’s going away. I was heavily invested into it and I just embarrassed the suck and converted my stuff over to routines, rules and SharpTools rule engine.
All the complaining in the world isn’t going to have your system ready for when things start shutting down. Less complaining and more converting your stuff over.
WebCore users could always pool some money together for a bounty. Maybe a developer would be willing to port it for $$$. I’m sure it will generate comments about being free on other platforms, but I’m pretty sure people pay for SharpTools. As a developer, I would like to find a way to monetize my work. It’s a big investment when you are integrating these devices.
That was the exact post that caused this one.
Is there anything others can do to help get this fixed? I would think Samsung would want to make sure their apps were accessible. Do you use the iOS or Android versions? I looked on Google App Store and there didn’t appear to be any standards for reporting against accessibility.
Im a firm believer for accessibility for all so I would love to try and help somehow.
I use iOS. I have reported the issues formally multiple times and twice SmartThings employees were tasked with getting more details, but the issues were never fully resolved. Sometimes a few things get better, sometimes a few things get worse, but it’s just not usable.
I’ve gone into some of the issues in considerable detail in this forum as well. At one point I was told they had hired a UI designer with experience in the W3 accessibility standards, but they still don’t meet those.
So it just doesn’t seem to be a very high priority for the company, although they put out great mission statements about accessibility for all.
I have also suggested on multiple occasions that they get in touch with the National Federation of the Blind, who have lots of resources for web developers and app developers. I don’t think that ever happened.
It’s obvious that they never had anyone test the app using a voice reader.
Just as an example, in the most recent app version there are sometimes ads that appear. But they quite commonly have images instead of text, making them very confusing in terms of navigation
The following screenshot was taken today. There is an ad very near the top of the screen. But I think the descriptive information is an image, not text. The only thing I hear is “dismiss“ and “view details.“ Which is really confusing when you are just trying to navigate the app.
]There are also multiple pages where the focus changes so you can’t get off of the page again or you can’t get to the actionable areas.
And the tutorials in the app are really fun. Not. 
Another screenshot example, this one from a tutorial.
The instruction should be: “3. To add actions that your routine will perform, tap the plus sign that follows the condition part of the statement.“
But what are you hear is “to add actions that your routine will perform tap below.“ which makes you think you’re supposed to tap on this screen. Which you are not. And since the pretty little + is an image, the screen reader doesn’t read it, so you have no clue what they are trying to explain to you.
Like I said, clearly never tested for accessibility.
Sample screenshot showing the tutorial page.
It’s just really frustrating, especially because there are so many resources these days to help UI programmers meet accessibility standards. 
Any sign the newish webapp is any better?
No. Sigh. But I don’t want to hijack this thread any further, this is just an example of something where I do keep complaining from time to time, I just try not to be too hostile about it. Meanwhile, for your entertainment:
If The SmartThings UI team designed wheelchair access (a series of photos of real life accessibility fails):
Designed, not tested:
Multiple design teams
Unclear on the concept
Excellent mission statement. Unusable execution.
Or, run ST and Hubitat in parallel, as I do in in order to maintain a couple of very large and highly complex pistons that cannot be reworked with routines, SharpTools, or the Rules API. It doesn’t have to be all or nothing.
on one hand, I get webcore is a beloved tool that many people use.
On the other:
But to be fair, SmartThings said publicly several times that Webcore would not be shut off until the new system offered feature parity. Only it doesn’t.
It’s too bad there isn’t a straightforward way to link the two systems. HubConnect will die with the Groovy shutdown.
There are things in Hubitat that I miss from SmartThings and vice versa.
I do think MQTT could be the answer to this, if you don’t run into the device maximum ceiling.
I’d love to see somebody in either community write this up as a project report with step-by-step how to use to connect the two systems locally through Mosquitto. 
I’ve had that thread bookmarked for a while to look at more closely. I am subscribed to his related channel, so it seems I started down that path and got sidetracked.
I do have HA, Mosquitto, and Node-Red all running in containers on my Raspberry Pi4 8GB, OMV 6 powered NAS.
I’ve found it fairly straightforward for the subset of devices I want to interact with via webCoRE in Hubitat. For any of those devices in SmartThings, I create a matching virtual device in Hubitat that is mirrored to its matching ST device. The mirroring is handled in one of two ways, depending on the direction.
When the ST devices changes state, an ST routine sends a local web request to a webCoRE piston on the Hubitat with {device} {state} arguments that changes the state of the virtual device on the Hubitat.
When the state of the virtual device on Hubitat is changed programmatically by a rule or piston, I send a web to the SmartThings API
It’s also easy to mirror the devices using SharpTools, but I prefer to use the local connection rather than a cloud service whenever possible.
I always considered that the prerequisite for that was some evidence of a real demand for those features. It is all very well users saying that they need X, Y and Z but if they already have X and don’t show the remotest in it there is a loss of credibility. Until the last six or seven weeks no one has expressed the remotest interest in doing anything about transitioning webCoRE to the Rules API, realistically or otherwise, and an overwhelming majority of users who have expressed an opinion would seemingly rather **** in their hands and clap than try to use the Rules API.
May I just add that I have spent a couple of years waiting in vain for more activity on the Rules API front and it has been incredibly frustrating. So it sticks in my throat finding myself defending that seeming lack of activity. They’d better fix the sunrise/sunset bug though, it’s been a year now and I am not that reasonable.
