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.
As much as I agree with the overall sentiment of this thread, this feels unfair and seems an unfortunate attitude to be presented here.
We both know that webCoRE was developed for hobbyists, not programmers, and the Rules API—fairly or not—presents itself as intimidating, unwieldy, and excessively complex to most of those who are endeavoring to transition. (It also lacks parity with webCoRE in key areas, but that’s another subject for another day.)
Many users weren’t active in the various forums who have been talking about the transition for years, and were caught unprepared by SmartThings’ announcement, thus the lack of interest until the last several weeks. I feel fortunate to have been aware and to have had time to evaluate all of my options over the past year or so.
I still remember my very first effort with the Rules API. Just to get a feel for structure and syntax, I created a stupid rule that when my office lights turned off, the kitchen lights went on and vice-versa. I had to correct a comma or bracket or two, but it worked. This is easy, I thought. But then I realized I had no clue how to disable the rule. I was half-laughing, half-panicked, but fortunately figured it out before my wife got home.
It was a deliberately colourful statement made for effect but I totally stand by it.
My basic point was that any comments ST made about feature parity are cancelled out by the failure of the community to justify their demands for that parity in any demonstrable way.
I actually commend those who have become vocal in the last six weeks. It is just the attitude that their cause has lacked for the last three years.
I have never been interested in preserving webCoRE on ST. That always seemed far fetched. My cause was the development of the capabilities of the Rules API but it is seeming like a lost cause now and I can’t see much to replace it with.
All this webCoRE bashing is quite unfair, especially from people who have never used it, or someone who stopped using it over a year ago.
I’m glad Rules API gives you all you need. But it can’t do what webCoRE can do, neither can Sharptools, so Rules API and Sharptools can’T be offered as replacements for webCoRE, they are nothing of the sort.
Rules API is not consumer friendly, I maintain, apart from ST staff, there are probably only 10 people using it at this moment. Rules API is for a particular kind of niche geek with next level computer skills, it will never take off among normal people.
SmartThings said many times, they won’t sunset webCoRE without a viable alternative, they understand how important it is, and will produce something similar, all be it possibly with some features missing. Good enough. They asked us which webCoRE features we used the most. They used some technical jargon to find out on the backend which webCoRE features were used the most.
SmartThings still haven’t said anything to the contrary yet. We are panicking now because of the lack of clear communication and other sunset dates coming up fast.
SmartThings could still announce their webCoRE alternative any day now.
Nobody knows.
I wasn’t bashing it, i was just stating the reality of supporting it on the new platform.
More likely is that locally running routines, the Rules API and being able to create your own hosted smartapps using the API is the alternative. Samsung didn’t write or support webCoRE, and while they may “know” how important it is, Edge and the direction it needs to go is more important and within their control.
Edge has been in Beta for nearly 2 years now. Would it make sense during these final months of the transition they’re gonna bust out a never announced webCoRE compatible rules engine that runs on Edge? I guess anything is possible but pretty unlikely.
Have you ever wondered what they found though?
I sincerely hope this is true, but I have little faith now.
There was clearly a lot of work to develop the Routine Creator beta at https://routinecreator.smartthings.com/
Just browsing through the JS files there using the Chrome’s developer tools, I think gives an indication that it was looking like a very good tool.
Did anyone here successfully use the routine creator beta?
Anyhow - as much I would love to see it go live, I just can’t see it happening.
As much as people in this community complain about the ST app, I think it’s pretty good (with some obvious problems discussed elsewhere). It’s the Hubitat app experience that is the only thing preventing me from making the switch to Hubitat.
I’m pleased to say I didn’t know if even existed until the last time the URL was quoted in the forum. I say pleased because it suggests that non-disclosure agreements were respected.
It sounds like the Smart Lighting app is going to become a Rules based front end and that could suck up quite a chunk of the demand for bespoke Rules. If Routines ever got an else section, that would be significant too. I’d still like to see a fully featured web client app. All these things just seem to give a lot more bangs.
Having the option to specify if/else in a single routine would also help with the routine limit and general clutter.
I have some routines that, other than the time of day and light brightness, are identical.
I feel the pain with webcore going away but I made peace with it and simply doing the best I can with what I got. For me a lot of my webcore pistons were there for the “cool” factor. Pistons that would randomly present you with a different TTS greeting when someone came home, randomized TTS for who’s going to get the clothes from the dryer, alerting on rocket launches, fancy gauges counting down an event etc.
I only discovered webcore when Stringify was being shut down and even that had me bummed as I had a lot of flows in Stringify I had to quickly replace all my flows but luckily Webcore was easy to use and seemed unlimited in what it can do. But in a way I’m used to things going away, new things replacing it etc. it’s almost never a like for like but c’est la vie.
I’m sticking around to see where the platform is heading but it’s good to see that at least some alternatives exist even though they may not be comparable to webcore. Rules api with a good front end would be nice.
There are some really good folks on here working tirelessly and I’ve seen some pretty neat drivers being released.
Or could it lead to other limits being imposed? Hmmmmm I wonder
Maybe something will be announced at the Developer Conference (next week):
