The End of Groovy Has Arrived

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.

2 Likes

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.

6 Likes

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.

5 Likes

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.

1 Like

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.

2 Likes

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.

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

2 Likes

so it appears Edge drivers take precedence over Groovy DTH including custom when pairing devices.

1 Like

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. :thinking:

2 Likes

@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!]

1 Like

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.

3 Likes

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!

2 Likes

Only 38 days until the end of Q1 - which is when everything is supposed to be moved over to Edge! :+1: