I guess the question would be should one attempt to force the new edge driver to those like devices that have not yet migrated for some reason?
Only if you’re in a hurry to get them over to Edge, and willing to rebuild any automations that will be destroyed when you exclude and re-add the devices. In my mind, if one device has migrated, the rest will likely follow before too long, and as long as you aren’t suffering from DTHs that are losing functionality it’s not worth the trouble.
If you want to move them and not lose Routines where the lock(s) are the only device, create a virtual device as a placeholder and add it to the Routine. Then once you have removed and re-added the lock, you can swap the lock back into the Routine.
If you want to move them and not lose Routines where the lock(s) are the only device, create a virtual device as a placeholder and add it to the Routine. Then once you have removed and re-added the lock, you can swap the lock back into the Routine.
This is the exact method I used to be fully migrated over before. Yes it takes some time but it’s done and nothing is broken.
Most of my devices have migrated except
Schlage smart lock which I’d love to get local
Sonos
Lutron caseta light switches
Everything works well.
Hoping the lock gets local and we get some version of LUM back.
Most of my devices have migrated except
Schlage smart lock which I’d love to get local
Sonos
Lutron caseta light switchesEverything works well.
Hoping the lock gets local and we get some version of LUM back.
I’d suggest migrating your Schlage lock to the [ST EDGE] Z-Wave Lock PH - Devices & Integrations / Community Created Device Types - SmartThings Community from @philh30. It exposes many more settings than the stock Edge driver and fixes several bugs as well. Also, the beta version of the driver in the same channel adds the capability to see how/who unlocked the lock on the device panel as well as making that a trigger for Routines. Since you can trigger on different lock code names with this capability, it offers the ability to do per lock code actions similar to what LUM previously offered and will run locally.
There is also a Sonos driver in the ST beta channel that offers some basic Sonos management features.
I’m getting a bad link when I check that out
I’m getting a bad link when I check that out
Should be fixed now.
I had one of each device type migrate and the one device that had previously migrated actually revert back - with drivers showing in hub device properties in the app. The easiest way to keep things consistent was to remove the devices (taking steps to not lose any routines) and then re-add them. Devices not yet showing as Placeholder are Hue and Sonos.
Devices not yet showing as Placeholder are Hue and Sonos.
The Sonos driver for Edge isn’t quite ready for prime-time. It’s quirky and several commands don’t function as intended. SmartThings is working on it, but I’d be patient with that one.
Use EDGE driver, Does device will be executing locally?
yes, all Edge drivers run locally on the hub
so it appears Edge drivers take precedence over Groovy DTH including custom when pairing devices.
No - and never heard back from support. That said currently at least in my case things have changed, and a fingerprint in an installed Edge driver for my contact sensor is now taking precedence over the custom DTH I can’t get rid of - so it’s no longer giving me trouble even though I can’t delete it.
so it appears Edge drivers take precedence over Groovy DTH including custom when pairing devices.
Can’t Delete DTH from IDE although no devices using it - #3 by AlecM
I asked @nayelyz to check on this two weeks ago because we are seeing reports both ways in the forum now. Some people saying they had to delete a custom groovy DTH before the edge driver was accepted and others saying they didn’t.
I am starting to wonder if maybe it varies by model number now, but I just don’t know. Or maybe there’s even a flag on individual accounts for specific devices that have been automatically migrated. It still feels confusing.
@nayelyz Either things have changed again or I’ve gotten confused. If someone downloads a custom edge driver for a device which was using a custom groovy DTH and they delete the device and re-add it, but don’t delete the DTH, will the system select the custom DTH or the custom edge driver? I am seeing reports both ways in the forum in the last few days. Some people are saying they did have to delete the custom groovy DTH from their account before the device would pick up the edge driver, and some people are saying they did not have to. So, which is it? Thanks!
@JDRoberts And, the precedence actually switched for me from DTH precedence to Edge Driver precedence over the last few weeks. (for a Quirky Tripper from Sercomm (originally on Wink) )- so a pretty old/ now uncommon device).
It could be, and likely is, a complete coincidence, but I had my first ‘significant’ migration happen in the same period. (about a third of my Commercial Electric tunable downlights switched over) - just thought I’d mention it - it could be hub-specific. (I’m on V2, FWIW).
[CORRECTION - upon review I think that installing a custom driver with the exact fingerprint is what caused the ‘change in behavior’ - sorry about any confusion!]
I changed today Fibaro Smart Implant (Z-wave device) from the custom DTH to Edge driver.
I made first Z-Wave Exclusion and then I made normal “scan nearby”
and Smart Implant onboarded with Edge driver.
I still have in IDE Smart Implant’s DTH.
So Edge driver for my Smart Implant is now taking precedence over the custom DTH.
Hi, @AlecM, @JDRoberts
I have checked how fingerprints work (order of preference) and already installed drivers should be preferred against custom DTHs.
However, it is strange for this to happen, it would be worth getting the Hub logs from someone experiencing this.
@AlecM, it was solved in your case, right?
First, I thought it could be that in some cases, the fingerprints on the DTH were more specific than those on the driver
But, if it’s a custom one, it should have the exact fingerprint of the device as I’ve seen users share them with the developer…
Hello @nayelyz. Yes, my slightly customized Edge driver (I just tweaked the stock one to add the Quirky Tripper fingerprint) is picking up a new Tripper just fine, although I can still see the custom DTH which also has the full fingerprint. That changed sometime in the last few weeks. All resolved for me. Thanks!
Actually, @nayelyz - I thought back and then realized that I had trouble with the DTH overriding when I was trying to pair to stock, not to a custom driver. Of course the stock doesn’t have the fingerprint. I think it worked ok right away once I figured out how to install a custom driver that had the correct fingerprint (either MCs or my own slightly tweaked stock). Apologies for the red herring!
Only 38 days until the end of Q1 - which is when everything is supposed to be moved over to Edge!