I’ve read some of this thread, not all.
What I have taken from it is that devices using custom th may or may not work post groovy shutdown.
Am I right in saying that to establish compatibility I need to look in the groovy ide and the device details listed against the device, then search for these in a fingerprints file for the appropriate standard edge driver.
If I can find it that means the device won’t work post groovy shutdown?
Surely there ought to be a tool to trawl through your devices and report those which will migrate, those that won’t, and those which will be less functional… eg multi switches where only the master switch is controllable from Alexa?
In the example above should I be looking in
If so I can’t find it, does this mean my multi switch won’t work on edge?
I agree, it’s much too difficult right now to find candidate edge drivers.
We’ve started a table in the community-created wiki so people can add entries there to make it easier for others. But it’s going to take a lot of community participation to build this up to where it’s really useful.
If smartthings comes up with an official tool, or online list instead, that would be great.
Sadly, you are right. Samsung TNT’ing a product is an every other day event.
FWIW The “power users” aren’t the problem, it is the user who bought a device/had-a-need, and then copy/pasted their solution into place. They haven’t given the issue a second thought, but have been relying on their solution.
Recommending SmartThings has been a no-brainer for me when people have asked home automation and wanted something flexible.
Oh well, it pretty much now comes down to, “Do you have an iPhone? Buy an AppleTV and use Homekit. Are you after lights? Buy Hue. Do you have an Android device? If you use Alexa, go with that… otherwise? Don’t bother with anything unless you are willing to throw the device away <3 years.”
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.
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.”
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.
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.
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).
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.