Not sure it is editable @JDRoberts - or I could not find how.
It should be editable by anyone. 
- If you don’t already have an account on the wiki, request one on the homepage. You will have to wait to get an approved email.
-
once you have an account, log in and then go to the page you want to edit.
-
choose the “edit” tab.
Well, here’s one stock Edge driver that didn’t work well for me: I had a perfectly functioning Aeotec Nano Dimmer, and I excluded and re-included it after installing the Zwave Switch Edge driver in the Beta. It was correctly included as an Edge device. Started testing, and the lights seem to flicker, a lot… Especially when dimming up or down. I don’t mean a little - this was a very noticeable flicker like the light was going to near maximum and near minimum intensity very rapidly. I then used the Edge drivers sent to me by Aeotec - whilst testing their Shutter switch, as it was in the same channel. The code, I believe, is the same except that Aeotec has added all the parameters supported by their switch. The result, however, is still the same. The flickering is very obvious and annoying. Sometimes it keeps going on even when you are not dimming up or down - and to get rid of it you might need to completely dim up to 100%. My conclusion, though I cannot prove it, is that the Edge driver, upon loading, changed one of the many parameters supported by the switch which resulted in this extreme change in behaviour.
This morning (about 36 hours later), I woke up to find the Dimmer offline. I have no idea how or why that happened, but the Dimmer is now completely unreachable from Smartthings, and turning on or off from the switch manually has zero effect on Smartthings.
So - yes, something wrong with that one I believe.
I will exclude it and re-include it once again to see what happens. If anyone has any input on this one, please let me know. Also - it is still not clear to me where to report any bugs or flaws during this beta stage.
Ok, yes, I didn’t get an account, hence not seeing the Edit. Will do…
1 Like
Would this be a good summary of the rules for migration of Z-Wave and ZigBee devices as we understand it? Listed in order of priority for evaluating how to migrate devices.
| Driver Before MIgration | After Migration | Notes |
|---|---|---|
| Edge | no change | Migration process skips any device already backed by Edge driver. |
| Built-in “local” Driver | Edge | Edge drivers are being provided 1:1 for existing built in hub drivers. |
| Custom DTH | Edge | If custom Edge driver already installed that matches fingerprint |
| Custom DTH | Edge | Fallback to “base” driver that matches fingerprint |
| Custom DTH | Edge | Fallback to “base” driver based on capabilities (ie, switch type device to use Edge based Switch driver) |
| Custom DTH | Edge “Thing” | If all else fails, switch to Edge based “Thing” driver. |
2 Likes
You can view the parameter settings for a device using a groovy DTH via the groovy Zwave Tweaker.
You can view the parameter settings for a zwave device using an Edge Driver using @Mariano_Colmenarejo ’s new zwave configuration edge driver if the original driver doesn’t expose them.
In both cases you temporarily have the device use the reporting version, then switch it back to its regular for everyday use.
———-
What you are seeing could be caused by a parameter setting change, or by too frequent polling.
Yes, except there are 5 rows, not 4.
Row 3 should be “If custom Edge driver already installed that matches fingerprint.”
Row 4 should be “Fallback to “base” driver that matches fingerprint.
Row 5 should be your Row 4.
In other words first the migration looks for a custom edge driver that matches the fingerprint, then it looks for a stock edge driver that matches the fingerprint, then it tries to guess based on capabilities.
I don’t know if you need a row 6, which is that if none of the first 5 work, it is just listed as a “thing.”
1 Like
Edited, thanks!
I like the rules based description of the migration process to keep it straight in my head. I’m formulating what I’m going to do pre migration based on what category my devices fall into. I’d much rather not go thru excluding and re-adding them back in if migration will take care of that for me, provided I prepare for each use case properly.
2 Likes
Thank you @JDRoberts
Alas, I had only one of these devices, and I did not think to take a record of its parameters before exclusion from the old DTH, and so I have no clue what they were before I re-included the device as an Edge one… Potentially changing its parameter settings in the process.
What I will do is factory reset it, re-include it with old DTH, take screenshots of all parameters, re-exclude, then re-include as Edge and check any changes that could have been done. Will leave any results here just in case others have the same problem.
I will check for both, if I can, and let you know. Hopefully, also, it will be able to stay connected to the network for more than 2 days.
1 Like
Can someone please tell me if I need to do anything about this or do I just need to wait for the rollout? I am mainly using Nue switches and Xiaomi sensors, a few smart apps and webcore
Cheers
Too late now but I wrote up my process for doing a similar task. Took lots of screenshots and notes before hand. From DTH to Edge Migration tips or tricks?
Note that devices vary on what they reset/re-initialize on an exclude vs factory reset. Some reset everything on exclude, others leave parameters alone. Some don’t do a factory reset after a firmware update either, which can lead to all sorts of odd behavior.
Most of the built in device handlers for zwave tend to leave parameters alone except for very specific cases. If its not settable via the App->Settings, its not likely to be modifying the device. Compared to Zigbee, parameter indexes and options vary widely between implementations. Even when handling specific logic of a major player (Leviton for example), it tends to be something non parameter related. Thus why we like using the manufacturer specific drivers instead (Zooz, Inovelli, etc).
2 Likes
Need more details. Are you using standard or custom DTH for the devices? which smartapps? You definitely need to move your webcore automations to other options.
3 Likes
I may be mistaken on this, but regarding row one, my understanding was that if a device is currently using a stock Groovy DTH, the automatic migration will shift it to a custom edge driver if there is one already on the hub that matches the fingerprint. But maybe I’m wrong on that, and a device using a stock Groovy DTH will be converted to a stock edge driver even if a custom driver with a matching fingerprint is present, and then you would have to manually change it to the custom edge driver if that’s what you wanted.
1 Like
One more thought…I think there are still a lot of open questions about what will happen with devices using the parent/child paradigm in the old architecture.
-
will the child devices be converted?
-
will they have the same name they had before the migration?
-
if the child devices were used in routines, will those routines still work?
-
will those child devices be controllable by Alexa and Google Home?
-
if those child devices were used in IFTTT recipes or Alexa routines, will those still work? What about SharpTools rules?
-
if those child devices were used in scenes, will the scenes still work?
I’ve seen conflicting answers on these.
I believe “zwave switch” is an example of a multicomponent stock edge driver, but I don’t know if the corresponding stock Groovy DTH uses child devices or not.
2 Likes
Agreed. I’m not taking any chances with any devices that have children. I’m converting those myself pre-migration.
My main goal was to weed out the “easy” ones that migration could/should/would work for me.
2 Likes
I have a ton of these child devices. Mostly they are MCOHome 2 or 4-gang switches, but I also have several others, ones that come to mind being Qubino Flush 2 Relay and Aeotec Nano Duo Switch. I am testing at least one of each type before migration, but even if I manage to find a driver that fits and works well, there’s no saying what the migration will do on 30 Sep, and information is way too scarce.
I will convert what I can before migration date, though certainly not all. Wish ST were clearer about this part.
1 Like
Yeah I wouldn’t mind changing things just now knowing that if I do, they don’t get screwed again come Sep 30th. Some more info would be good to be fair.
1 Like
This looks to be a custom edge driver. Will the standard edge driver feature this device too?
Also, for multi switch devices will they appear as a single device? And thus only the master device controllable from Alexa?
This is a huge concern for us “Please note that some devices may not transition automatically and will need to be re-onboarded.”
We have custom DTH for smart locks (Yale, Kwikset, Schlage Zwave) and several different contact sensors ( Zwave and Zigbee) and leak sensors (Zwave and Zigbee).
How can we find out which devices need reonboarding, and which don’t? This is such a massive effort that we if we have to reonboard we will just rather switch
2 Likes
Thanks for getting back to me 
The DTH are ones that other people have made available from GitHub and I have copied the raw code to make DTH’s. The smartapps are a combination of smartthings ones and others from GitHub. I am comfortable doing that again, however there is no real information on how to access and install the platform we need to install the new drivers on. I was hoping that Samsung would provide some kind of how to guide rather than just getting the community sort it out for them. What alternative options are there going to be for webcore? Will the new platofrm be capable of more complex automations?
1 Like