I imagine it will be quite seamless with Samsung or Smartsense devices. But what about all the various Chinese, semi official or unsupported devices? Will obscure fingerprints that have now been added to Edge drivers due to the great work of members of the community also switch to Edge drivers automatically, or will they need to be removed and re-added?
(Sorry if this has been covered)
Itās been covered a couple of times, but usually buried deep in a topic with a thread title that wouldnāt necessarily tell you the information was there. Here it is again:
During automatic transition:
If the device is currently connected with a stock groovy DTH and it is eligible for transition, then if its fingerprint matches a custom edge driver already on your hub, that will be used. Otherwise, if its fingerprint matches a stock edge driver that will be used. If its fingerprint doesnāt match any edge driver, then The system will try to use its ācapabilitiesā to match it to a generic edge driver. If that doesnāt work, it will be assigned to a āthingā edge driver.
If the device is already connected with a custom edge driver, it will be ignored during the automatic transition.
If the device is currently connected with a custom Groovy DTH, it will go through exactly the same process as the device connected with a stock Groovy DTH. First the system will look for a custom edge driver already on your hub, then it will look for a stock edge driver, then it will try to match based on capabilities, and if all else fails, it would be converted to a generic āthingā edge driver.
And hereās the official transition FAQ:
Perfect, so in essence, if a fingerprint exists, the transition should be smooth.
Mostly.
If you are going from a custom groovy DTH to a stock edge driver, you could lose some functionality.
For example, the stock driver might not expose the same parameters, so you might not be able to change the behavior of the indicator LED on a light switch.
It tends to come down to the reason why a custom DTH was created to begin with. If there were advanced features that werenāt included in the stock DTH, they probably wonāt be included in the stock edge driver either.
Alsoā¦if itās a device using the parent/child structure, even a stock device, it could be changed to a stock āmulticomponentā Edge Driver, and ALL of those have a serious issue with regard to third-party integrations, including voice assistance. Only the main device is exposed to the third-party. So for example, if you have a power strip, you would lose voice control of the individual sockets. 
This issue was first reported last year and it still isnāt fixed, so I wouldnāt hold my breath waiting for an official solution. 
The workaround is to create virtual devices using an edge Driver and sync them up with the sub components using routines. That way you can use voice to turn the subcomponents on and off
Alternatively, there are some custom drivers for some models that have solved this, although I donāt know the details of the architecture.
So thatās the case where the fingerprints would match, the transition would happen, but you would still lose some functionality. 
Several questions that this prompted:
Any thoughts you might have would be helpful as we approach or have already reached this deadline.
āCloseā fingerprints will not be treated any differently than completely different fingerprints. only exact matches will count.
As I mentioned above, if there isnāt a finger pprint match they will look at the ācapabilitiesā of the device and try to map it based on those if they donāt have an exact fingerprint match. āCapabilityā is a specific technical term in the smartthings platform with a very precise definition. For Zigbee devices, it depends on the clusters that the device supports. For z wave, itās the command sets. These are mapped to ācapabilitiesā in the smartthings architecture.
Itās not a fix, itās a workaround, The subcomponents still are not themselves made visible to the voice assistant. But the voice assistant can see the virtual device. And a smartthings routine can see both. So you can have the voice assistant turn the virtual device on and off and use a smartthings routine to have the actual subcomponent follow the state of that virtual device.
And yes, The virtual device and that follow routine will count against your totals for the maximum.
This is just a matter of personal preference. Some people will choose one method for all their devices. Other people will look at each device individually to make this determination.
As far as what will happen to your smartthings routines if your device transitions to a āthingā Edge driver, I will leave that to others to go into the details. I believe @Automated_House has looked into this.
If youāre using a custom DTH now and there is a custom Edge driver available, Iād go ahead and install it and wait for SmartThings to migrate for you. That way if you have routines based on a capability unique to the custom code it isnāt affected when the device is migrated.
I believe if your device is migrated to an Edge driver that is missing a capability used in a routine, itās treated the same as if the device was deleted. IIRC the way thatās handled today:
There are three phases and things will happen differently in each phase:
1a) if you add a new device, the current priority will be
Custom groovy DTH
Custom Edge Driver
Stock Edge Driver
Stock groovy DTH
groovy (not Edge Driver) āthingā
So if you have an existing custom groovy DTH on your account with a fingerprint that matches the new device and you want to use an edge Driver instead, you either have to delete that custom groovy DTH or at least comment out the matching fingerprint.
1b) if you want to change an existing device on your account from a custom Groovy DTH to an edge driver, you have to delete the device from your account, then delete the custom groovy DTH (or comment out the fingerprint), download the edge Driver to your hub, and then re-add the device. This is called āmanually changing from a DTH to an edge driver.ā
This is required because of the fact that right now devices could use either custom groovy drivers or an edge driver.
So this is where we are right now.
Phase 2: automatic transition. At some point, and we donāt have a specific timeline other than āstarts October 15ā, smartthings will begin the automatic transition and then the rules apply that I described in my previous post. You donāt have to delete the device and re-add It. You donāt have to delete or modify the existing groovy DTH. The process will occur, one device at a time, as I described in my previous post. Itās not clear how long this will take or which devices will be selected first.
Phase 3: new architecture. Then at some point in the future (again, we donāt know exactly when), all groovy DTHās will stop working. Presumably all your devices will have been automatically transitioned by then. Any new device that you add will use an edge driver because there wonāt be any more groovy DTHs. When you go to add a new device, the priority will be:
Custom Edge Driver with a matching fingerprint
Stock edge driver with a matching fingerprint
Stock edge driver with matching capabilities
āThingā edge driver
āā-
So, in my first post I detailed what will happen during the transition, phase 2.
But right now, we are still in phase 1, when you can use either a Groovy DTH or an edge Driver. In phase 1, custom Groovy DTHs still take priority over edge drivers for new adds. And you canāt change an existing device on your account from a Groovy DTH to an edge Driver except by deleting the device and re-adding it. So it sounds like you may be thinking that the phase 2 rules apply when we are still in phase 1 and phase 1 is different.
I think I get it, but my issue is with things that donāt have custom handlers but still stay within groovy, even though their fingerprints have been added to edge drivers.
Do I need to have the edge drivers on my hub first and if so how do I download them? I can only find the beta invite link.
Yes, any edge drivers, custom or stock, must be on your hub before the devices added.
Presumably all of the stock drivers will be added to customers hubs before the phase 2 transition begins, but they arenāt there yet.
The stock drivers that you can get now are in the beta channel. So you have to subscribe to that channel and then select the edge Drivers that you want.
Note that some of the fingerprints in some of the smart things written edge drivers are commented out right now. So itās not enough to see the fingerprint, you have to make sure thereās not a /* before it as well.
To get a custom edge Driver, download it to your hub, you follow a link that the author gives you, subscribe to the channel, select the drivers that you want, and then wait. It can take as much as 12 hours before they are download it to your hub
For the details on how to see which drivers are already on your hub, see the community FAQ. That will also tell you how to find community-written custom edge Drivers.
FAQ: I have no idea what Edge is. Is that a new developer tool? (2022)
Remember that during phase 1, which is where we are now, you can only get an edge Driver for a device already on your account by deleting and re-adding the device.
Thanks itās starting to make more sense. I am subscribed to the beta channel but still canāt find many of the drivers referenced here just a short list Post Requests for Edge Drivers Here (community-created) - #903 by Mariano_Colmenarejo
The beta channel is only for Edge Drivers written by SmartThings staff.
The thread you just linked to is for requests for edge drivers written by fellow community members. Not staff.
To Find community-written edge Drivers, like the ones by Mariano, check the quick browse lists in the community-created wiki. Each author will have their own channel. Or even more than one. 
The quick browse list will take you to their author thread in this forum. Then the developer will tell you how to subscribe to their channel.
https://thingsthataresmart.wiki/index.php?title=Quick_Browse_Lists_for_Edge_Drivers
I hope that helps make it a little clearer.
My work around for this was a series of routines and a virtual switch. You ask the voice assistant to turn on/off the VR switch, then the routines(in my case a rule using the API) mirrorās the state between the two things.
I asked this a while ago and I didnāt get a firm answer. My suspicion is that the existing child devices will be deleted, rather than transitioned to subcomponents of the new main device. On the off chance thatās wrong, Iām waiting for ST to migrate them, but Iām going to add a āplaceholderā virtual switch to all my routines so they donāt get deleted.
Scary though, but you are probably right. I have roughly 30 āchildrenā in this scenario and some of them have several automations attached. Not sure Iāll make that many virtual switches, but maybe I should make at least the ones I use via google and one extra dummy one/ outlet strip muti child device for the rest?
That probably makes sense since youāll most likely need the individual ones for voice control in the long run. I plan to screenshot all the automations that are impacted (two Zooz power strips and a double outlet, plus a light/fan, so around 12 devices with 1-2 automations on nearly all of them) so I can rebuild them later. I created a couple of dummy virtual devices and Iāll just add one of those next to the originals in each automation. If the child devices do transition smoothly, I can just delete the virtual devices and theyāll disappear from the routines; if not, Iāll go through and replace with the appropriate subcomponent.
I went through and screen shot most of the IDE last week, but yes, it looks like doing the same for each child automation will be needed as a backup. Thatās about 1/3 of the ones I have if I include relays, smart strips, scene controllers, etc. Glad ST has such a great backup feature, lol.
Thinking about it now, Iām not sure I can use one dummy for the ārestā of the automations as there will likely be conflicts, but for now, Iāll screen shot all and add dummys for the important ones that Iāll need later for sure.
Do we know all of the devices (or types) that fall into this category? Of particular interest is the Zooz ZEN31 RGB controller. It isnāt explicitly a master/child device, but it does use multiple devices to control the white light vs the colored lights. There will already be a challenge if the color coordinator goes away for the colored lights, do I also need to worry about the separate entities being controllable?