I know SmartThings staff hasn’t directly addressed this, but I wouldn’t consider it to be the case anymore. A SmartThings user not enrolled in any beta program can currently onboard a device and it could use an Edge driver. Specifically an Edge driver from their production channel of the Edge GitHub repo. If it looks like public, and it quacks like public, then it’s public.
Maybe, but right now to me it looks like a public Beta phase. A lot of what should be obvious glitches still in play, including the issues with multicomponent devices, broken labels, inconsistent fingerprint mapping, variable value scales, battery life, etc.
Here are a few from today. This doesn’t look like production to me but maybe I have different standards…
.
.
.
.
installed the Edge driver and it works more reliably but still, after a day of no use the ST click would take anywhere from 4 to 8 sec to turn on the light. It’s as if something in the hub goes to a deep sleep and needs to wake up, load, etc. to execute the command and send the HTTP request to the Tasmota web server. Once awoken, it works OK. Does anyone else see the same issue?
Many of you are writing about the death of WebCore, maybe it was a useful tool but too complicated for many.
I have been using SharpTools: Dashboard and Rule Engine for SmartThings, Hubitat, and Home Assistant for several days
The fee is not high, and I can automate a lot of things based on “if”, additionally I can trigger routines via webhooks, just enter a link from webhooks to the free CRON and set it to open every minute and we have the integration working all the time.
In addition, the authors are willing to help, I needed to know the date, weather and thanks to simple API queries I was able to do it, and I am a complete like who does not know programming.
Does sharptools run locally?
Unfortunately, no, everything works after the API, but it is already adapted to the new EDGE version and you can be sure that it will work.
Better such an option than never
I’m trying to make everything work as local as possible
Not sure if I should start a new thread along the lines of “Where to from here”.
I have not been giving the latest developments much attention since my two smart homes have been running stable for the past few years. I have as a result also not been frequenting this forum as often as I used to. Reading about the end of Groovy on Friday night just as I was about to go to bed, gave me a massive wake-up call and to say it messed up my weekend, is putting it mildly. (For context, according to the Smartthings IDE, I have a total of 415 actual and virtual devices between the two hubs. These devices are primarily controlled with about 140 webCore pistons. I’m using about 35 custom DTH’s)
After having been frantically reading this and other forums since Friday evening, my understanding is the following:
(a) I will no longer be able to control my 4 Harmony Hubs; Arduino custom devices (which I use to check the water level of my water reservoir and which garage is empty (to open the door of the empty garage when I arrive home)); the LaMetric displays which notify us which outside doors are opened; my Denon Heos wifi speakers and many other devices. I have also not been able to figure out how to migrate my 41 Hue lights.)
(b) Only devices showing the “device type” as “Placeholder” in the IDE, have been updated to the edge drivers (in my case, it is only about 15 devices, mainly due to switching to Tod Austin’s (@TAustin) Edge driver for the Envisalink interface; adding a new Samsung TV and a new cell phone. The rest of my devices are all still using the old drivers.) I have many Fibaro and Aeon switches, contact sensors etc., using the native Z-wave drivers. None of these has migrated automatically to date.
(c) The only way to manually / force an update to the Edge driver is to exclude and re-include devices. (I.e. climbing into the attic; getting on ladders to get to switches; moving furniture around, opening walls etc.) And if the device requires a custom driver, one has to find a new custom Edge driver before being able to re-include the device.
(d) I prefer creating my automations on a computer, and with that in mind, the Sharptools Rules engine is probably the best alternative to webCore. I have tried re-creating a few webCore pistons, it is not nearly as powerful as webCore.
(e) Re-creating my pistons in Sharptools now is going to be a waste of time because if devices do not migrate automatically to edge drivers, I will have to remove and include them. Doing that will result in having to re-add the devices one by one to the newly created Sharptools rules.
(f) The way Samsung is implementing the change, is ridiculous. One would have expected them to tell us when they will finish with the driver migration and once the driver migration has finished, give us a month or two before shutting down Groovy support. That way, we’ll know for which of our devices we must find new drivers.
(g) The IDE will eventually also disappear and the only way one will be able to manage device/device settings, will be via the Apple or Android apps.
If my understanding is correct, I would like guidance regarding the following:
(i) Are we really in a position where we must wait until the last moment to see if Samsung will migrate devices to the new drivers? If we wait too long, we’ll end up with lots of devices and automations not working.
ii) Will we be able to access webCore pistons to use them as guidelines to create new automations in whatever new system we use? I fear that once Groovy is gone, webCore will not be accessible at all?
(iii) Am I being unnecessarily pessimistic, or is this a major mess? How will other members in my position be approaching the migration?
(iv) Since I’ll have to recreate all my automation from scratch, is there any reason why one would not move to Hubitat now? At least my understanding is that one will be able to migrate current webCore pistons to Hubitat, saving the hassle of re-creating all 140 automation. And it seems that the custom handlers I need, are available in the Hubitat environment. I would prefer to stay with Smartthings, but it seems that they are dumbing down their system to the level of the other major systems and for more advanced automations, we must look elsewhere. I suppose part of my conclusion is my perception that developers of custom handlers are moving away from Smartthings.
(v) Once a device is using an Edge driver, will it be necessary to remove and add the device to change the native Edge driver for the device, to a custom edge drive should one become available? (If I’m correct that the IDE will no longer be used to manage device drivers)
Sorry for the long post, but I’m sure many other members will be waking up to the same surprise soon. Because I’ve been married to the Smartthings system for so long and I know so little of where this is going, it is impossible to make an informed decision of where to go from here. I’ll therefore appreciate your input very much.
Will there be a way to see z-wave /ZigBee routes after these changes?
Wow SmartThings, create an announcement post line this and then ignore it without responses to customers questions. Bedsides the previous unanswered questions here’s one more.
Since SmartThings is making this migration mandatory by the end of next month, then why am I not seeing the SmartThings ‘production’ drivers available on the list of available device drivers for an Edge device that I’ve connected using a SmartThings Beta or another developer’s Edge driver? Will the SmartThings default ‘production’ drivers ever appear on the list of available drivers for an Edge device?
Instead of requiring us to go through various fingerprint files to find compatible devices, why not create a web-based database that allows us to easily look up what’s been put in to production? I’m spending hours checking these damn devices against code, getting confused with what’s commented and what’s not. Help us make the transition.
And… oh… how about an app that isn’t slow as balls which more easily allows us to transition?
Move to hubitat, your be able to port all your WebCore pistons, seeing this post on Friday has made me complete the hubitat move (Hadn’t moved z-wave devices across) over this weekend I started over a year ago but Hubconnect (allows ST <-> hubitat communication which will die when groovy dies) made me lazy.
(g) The IDE will eventually also disappear and the only way one will be able to manage device/device settings, will be via the Apple or Android apps.
I think most of your a) to f) is correct: hopefully others will chime in if not.
On g), there is a programmer’s tool, the CLI (command line interface) which you have to download onto a pc and then you can write queries to get some device information, like network ID. I haven’t used it myself because I only have a tablet, no laptop, and because it’s obviously going to be awful to use with a voice reader. (I’m quadriparetic.) But there are community members using it now who can answer more questions.
@Mariano_Colmenarejo has written a detailed post on how to setup the CLI.
Otherwise the only documentation I know of is in the developer preview GitHub, but maybe there’s more elsewhere, I haven’t looked. 
Like many people, I’m hoping ST will eventually release a web interface with IDE-like information for the new architecture. But no promises.
Tagging @orangebucket @nayelyz in case there’s a documentation link for the CLI that I’ve missed.
have also not been able to figure out how to migrate my 41 Hue lights.
If they are connected via a hue bridge you don’t have to do anything. The cloud to cloud integration is already using the new architecture and the LAN integration is being automatically updated.
If you are using a custom DTH to connect them directly to a ST hub, it’s like any other custom DTH. Try asking in the author thread for that DTH.
That works on the old groovy architecture, though, right? Is there an updated version for the new architecture?
I noticed the other day that Hubitat has built in support for MQTT, so you could set up communication that way using @taustin ‘s Edge based MQTT project, but that’s pretty clunky. ST <->MQTT<->Hubitat.
Just a note to users reading this part. Do not use HubConnect at this point. When ST starts migrating directly connected devices over to Edge Drivers then HubConnect will not work as it depends on Device Handlers. There are alternative options but I leave that to you to discover. 
v) Once a device is using an Edge driver, will it be necessary to remove and add the device to change the native Edge driver for the device, to a custom edge drive should one become available? (If I’m correct that the IDE will no longer be used to manage device drivers)
You will first subscribe to the custom edge driver author’s channel and select the driver you want so it gets downloaded to your hub. That can take awhile (reports have been of up to 12 hours: I don’t know what the production standard will be).
Once it’s on your hub, you’ll be able to switch back and forth between available drivers on your hub for that device from the device details page. It will list the drivers you have for that device. Based on reports from people in the early beta, the production driver should be on that list also. (@Automated_House might know.)
The IDE will be shut down when the transition is complete so, yes, you are correct that it is not used to manage Edge Drivers.
at @JDRoberts and @jkp I wasn’t promoting HubConnect usage, I just said it made me lazy, and finding out I had 6 weeks before it broke it make me complete the move ASAP
I have been looking since this rushed announcement, one thing I am not seeing with Hubitat is a commitment to Matter. The question on the forum was kind of blown by…
To be honest, a Z wave to matter integration is going to be complicated, because most Z wave hubs don’t use IP addresses for the end devices. So that’s a lot of work. I suspect that’s why Samsung is only going to offer a one-way integration for matter: you will be able to bring Matter-compliant devices into the smartthings app, but you will not be able to add the smartthings hub to other matter-compliant apps like Apple home or IKEA Dirigera.
My guess is that most of the Z wave hub manufacturers are just going to wait on matter to see if silicon labs, the Z wave chip manufacturer, comes up with a matter solution for Z wave. maybe as part of Series 800. SI has been making some statements that imply that they might do this, but nothing specific yet.
SmartThings was willing to go to market with the one-way integration, but then they have one of the more popular home automation apps.
But this is all just speculation on my part, no one has made any public announcements that I’ve seen.
So I think we may just have to wait and see on this specific issue.
I sincerely appreciate everyone’s input regarding my questions. The chaotic manner in which Samsung is dealing with this, is beyond infuriating and makes it difficult not to make an emotional decision about moving away from the Smartthings platform.