Hi all. I must have completely missed that a lot of my old driver could stop working in a couple months. Now that I see the forums first page I can tell this must have been going on for a while!
Anyway, is there something I can do to see if a driver needs an update? How can I see this indicator in my ST IDE pages? Is there a community “Beginners Guide” or something to help those who just want to make sure things keep working on our systems?
At this point, when you open a device in the ST app, click on the 3 dots in the upper right of the screen, and click on “Driver”… you can see the Edge Driver assigned along with the Date of that Driver. Drivers are updated automatically after ST or the Developer of Community Drivers push them out. These updates are received by the hub within a day. The user is no longer required to update community Drivers like they needed to from IDE.There is currently no other info provided in the app for Edge Drivers but you do have the ability to select other Drivers to use with a Device.
Note: Driver in the menu under the 3 dots does not appear until the device has received an Edge Driver.
Is there a community “Beginners Guide” or something to help those who just want to make sure things keep working on our systems?
and here is a starting point for CLI which you can get some equivalent information that was provided in IDE:
If you look in the IDE any devices listed as “Placeholder” are using the new architecture and are ready to go. These are WiFi devices using official cloud to cloud (c2c) integrations or Z-wave, ZigBee or Lan devices using the new Edge Drivers.
Any non-placeholder devices will eventually need to be upgraded.
From another thread:
If they are using stock DTHs, you don’t need to do anything, they should be automatically converted as the transition goes forward. But any devices in that list using custom DTHs would be the ones “at risk.“
They should still be automatically converted to a stock edge driver as part of the transition as long as the fingerprints match, but then you might lose some functionality. So you might prefer to start researching and see if there is a custom edge driver with the same features as the old custom groovy DTH. 
you can try checking the author thread for the groovy DTH you are using to see if anyone has posted there about an equivalent Edge driver. If not, You can find existing custom edge drivers by looking on the quick browse lists in the community-created wiki.
We really should have a topic title on
"How to exclude and re include my device’ with users helping each other on how to exclude devices they use
If a devices fingerprint is released by Smartthings and installed onto a hub automatically the next time a users device is excluded and re included it ‘should’ use the edge driver ST released
A user can try to include there current devices and re on board to catch an edge driver
The problem going forward can be many things but one of the issues is how to exclude a device a user installed 2 years ago and cant remember how to exclude
A thread on device exclusion could be very useful
A little complication to be aware of… Below is a device that was migrated automatically as part of the beta program. All of the devices that were migrated that way continue to show as attached to the hub, but this one is peculiar in that it still shows the DTH instead of placeholder.
Best advice for users at this point is wait and let ST migrate their devices automatically. 
Now, with the official end of Groovy only days away, this “best advice” may no longer be the best, unless you want to risk some of your devices stop working from January, 1st. It would have been great if Samsung gave the user a chance to force migration of devices to Edge drivers without deleting and re-pairings them. Not so. They have decided that only they themselves can do this kind of migration, and we’re relying on them to do it properly. Of which I have my doubts, for good reasons (as in: total chaos in transitioning from the “old” to the “new” app, with several features NEVER being migrated).
I have therefore manually transitioned many of my devices, and it is a real pain. The main point is, another very bad design decision on Samsung’s part, that all automations/routines containing a to-be-manually-migrated device will be deleted and have to be constructed again. So, it is not a simple “delete and re-pair” process as often said. As a result, I am eagerly waiting for Samsung to transition my last five devices (all of which ARE supported by standard edge drivers, just not on my hub), because it would be at least two hours of work to re-create and properly test all automations these devices are part of. The very least thing they could do would be to offer a method to force migration the way THEY do the migration. I am really not in the mood to tinker my smart home automations and driver stuff during the holiday season…
Thus, I would say the best advice now is to prepare everything for the migration - check which devices are in actual danger to stop working, discontinue the use of WebCore and create alternative solutions using “automations” (very limited capabilities, though), make sure that you’re not using any “SmartApps” (maybe except “smart lighting”, which MAY be migrated in one form or the other), and check for community drivers for your devices if the standard drivers lack functionality (which is very often the case) that you are used to from dedicated DTHs. Just “waiting” jeopardises your smart home unless you have only very few standard devices (in which case you most probably are not reading this forum anyway).
I decided after researching that this would be quite complex for me. With the lack of really simple guidance integrated into the IDE or App, I went for Hubitat on Black Friday and will instead migrate to that next week. Wish me luck!
I don’t know if this is a change from when it was first published, but the official transition FAQ currently says only
We expect the majority of supported devices to be fully migrated by the shutdown date for Groovy integrations on December 31, 2022
So they left themselves however much extra time they might need after that date.
It’s a goal date, not a drop dead date at this point.
Well, isn’t that only days away? 15 days until “the shutdown date for Groovy integrations”, to be precise.
I think you misunderstood - they will shut down Groovy in 15 days from now, and what has been migrated until then will work, and the rest won’t, for the foreseeable future at least. So, not THEY left themselves extra time, YOU will need extra time to make things work. It is not like “it will continue to work until Samsung has figured everything out”. If you only have devices that they consider worthy of migration until then: good for you. If you have others: prepare to see inoperable “Things” in your Smartthings app and hope someone else will make them work, somehow, sometime. Maybe Samsung themselves, but they do not promise this anywhere, so it’s safer to assume it won’t happen. Compare the case with many Zigbee devices that NEVER worked with the Samsung-provided device handlers. I know because I wrote quite a few device handlers myself to make things work. Counting an Samsung for any kind of help after Groovy shutdown may be fruitless. They will find other things to do (make Matter and Thread work, for example), and migration away from Groovy will not their priority after December 31.
I don’t believe that. Every other date on the timeline has slipped. I fully expect them to leave Groovy operational until they’ve finished migrating all user devices. At the worst, devices will migrate as a “Thing” and you’ll need to find a driver after the fact, but I don’t see any way that they’ll just cut users off as you’re suggesting.
This has already happened for at least some users; possibly everyone, and people just haven’t noticed.
@MarkTr, you’re totally entitled to your belief. I personally have seen Samsung take away functionality several times before, and I see no reason to believe they won’t do it again. And migrating working devices to inoperable “Things” is exactly what cutting off users means.
Regarding “Smart Lighting”, it may have happened to some people, but it has happened to me for sure. Nor have I seen the Weather alert That’s one part of the problem: the whole transition is very unpredictable, it happens for some people for some devices at one time, for others some time else.
I may have misunderstood, but as @marktr mentioned, these dates have now slipped multiple times. I read the statement above to mean that they understand they aren’t going to get everything migrated by December 31st, so migration will continue after that date for some devices.
That’s consistent with what staff have told me directly as well as what some of the developers like @Rboy have said, who have much more of an inside track than I do.
All of that said, that’s just my interpretation and I could well be wrong. Maybe devices that haven’t migrated by December 31st just won’t work on January 1. Interpreting it that way would certainly fit a better safe than sorry approach.
As you know, smartthings does have a history of promising more than they end up providing in these kinds of transitions. Even now the rules API isn’t fully completed and certainly doesn’t match Webcore functionality.
So I’m not disagreeing with you, I’m just going by what I’ve been told.
The FAQ doesn’t make the best choice of words in some places. To me it is pretty clear that what they are trying to say is that end user involvement in Groovy integrations ends on 31st December as the intention is to shutdown as much of the IDE as they can on that date. It doesn’t mean that existing integrations stop working and nor that migration stops on that date as it is clearly stated that the process is expected to take a ‘few months’ from October 15th and although ‘few’ is ambiguous I would argue that it is reasonable to infer more than two and a half.
The migration process for Smart Lighting has certainly begun. I don’t believe anyone has suggested it has ended.
I have been using @TAustin api browser + tool so i can easily find DTH attached devices
Im now down to 9 Greenwave sockets, all Sonos products and a few odd items i know will be killed at IDE switch off, its a task but im getting there
That’s why I go with the “better safe than sorry” approach. I have manually migrated over 70 devices as of today, and saw a few being migrated by Samsung in the background. At this point I am down to three Zigbee bulbs and one LED light strip for all of which I have a community driver installed - and yet they are not being migrated automatically, as suggested in the FAQ:
This option, for me at least, does not work at all. It would be the optimal and easiest choice for migration without losing automations. “We will attempt…” - what does that even mean? I agree with @orangebucket that “The FAQ doesn’t make the best choice of words in some places”.
All in all, the transition is nowhere as smooth as Samsung makes the users believe, and - at least in my case - has created a lot of unnecessary work.
I may be misreading this sentence “All other SmartThings and 3rd party created Groovy SmartApps will no longer be supported starting on December 31, 2022, at 00:00 (PST).”, but for many people existing integrations include WebCore and other SmartApps, and giving an exact time and time zone does not sound like a very flexible “goal date”.
Let me add that I have exactly zero inside knowledge of what they are planning, so I may be wrong with my pessimistic view - and I sure hope I am!
The announcement was originally written with firm drop dead dates.
Then as the dates would slip they went in and edited it without announcing specifically what was changing, and without publishing a change log, just making it look like it had always said the new dates/language. But they typically just changed a few words or a date so that it no longer had a consistent tone.
Both confusing and frustrating.
Absolutely. I cannot believe an international multi-billion company such as Samsung handles a (self-chosen!) transition so poorly. It leaves a very unprofessional impression.
