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?
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.
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.
In the outlet strip scenario, the current children would be mapped to the existing automations, but no longer exposed to google/ Alexa, correct? Other threads indicating using a virtual device will “fix” this at the cost of a routine and a device. Correct?
I’m assuming we have no idea if the fingerprint is “close” how ST will map the device, or will most of these end up as Things?
Will it be easier to anticipate change (e.g. Zooz drivers) and download the new driver now, or wait and see and then download the right one later? I guess the biggest concern is will Things be erased from automations or will they stay but not function?
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:
if that device is the only condition or action in the routine, the routine is deleted
if there are other conditions or actions, that device is removed from the routine but the routine stays.
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.
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.
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?