Thanks, I have already installed TAustins weather driver.
SmartThings migrated my DTH weather device in the last day or two. It was listed as a new device still named weather. I think the type was LAN but I deleted it before I could check it out. The new weather device was reporting to the tiles in action tiles and sharptools just like the old DTH did.
That’s surprising. I thought it might end up migrated to a ‘LAN Thing’ driver in the absence of anything else to migrate it to, but not to anything that continued working.
I can’t help thinking that the fingerprinting of Edge drivers is a weak link. To me it would make more sense to define all the drivers to handle generic and branded device identifiers (unique across drivers) and have a completely separate mapping from fingerprints to those identifiers. It shouldn’t be a case of changing drivers, it should be a case of changing the device identifier mapped to.
I accept that handling that mapping might be non-trivial or indeed not practical, but the current arrangement doesn’t seem to work very well for devices that aren’t explicitly fingerprinted, and seems a bit unnecessary for those that are.
I was thinking the same thing- the fingerprint approach doesn’t seem like a very scalable solution as every manufacture’sr new model triggers a new driver update, which means over time the drivers will get long and take up more memory that is not of value for most users.
Absolutely!
This is yet another case of smartthings adding its own architecture layer over an existing third-party specification, and creating unexpected integration issues because of that proprietary layer.
Both Zigbee and Z wave devices already tell the hub what their standard capabilities are in a standard way at the time that they join the network. That’s what being certified by those independent third-party organizations means.
Incorrectly mapping something that tells you it’s a button controller to a driver for a switch, for example, and thereby breaking a bunch of existing automations that have run successfully for years, just shouldn’t happen for a certified hub. But that’s what the smartthings edge transition is doing. 
Sure, some of these models have manufacturer-proprietary code and capabilities. But the independent third-party standards require that those models tell you that they are using proprietary code at the time that they join the network. So then the platform can decide whether to map them based on their standard capabilities, or put them in a separate group that requires custom handling. Either is a reasonable approach.
But to take something which is certified, and is using standard capabilities, and then map it to an entirely different device class because of the hub’s own proprietary architecture just feels like a violation of the standard to me. I’m not saying for sure that it is, I don’t know all the details of the certification process, but as a former field tech, it bugs me. 
JMHO, of course.
Yeah. It certainly looks like a kludge! <Sigh…>
I would imagine the hub only needs the ‘src’ directory of the drivers, so extra fingerprints are only going to be a problem if there is extra code to handle those devices.
I can see why it happens. For example, the Tradfri On/Off Switch (‘dimmer’) and Shortcut Button use On/Off for pushed and Level for held, so they do look like switches. In the Z-Wave world the Basic, Binary Sensor and Notification classes are used for a number of different types of sensor.
Maybe the the generic fingerprinting needs to go a bit deeper but it needs to be able to do it reliably and is the extra information always there? Even if it is you will learn nothing from it about any bespoke handling the device might need, and there are plenty of devices that need it. That’s why I am suggesting that we need to be able to say for every device ‘treat it like one of those’ where ‘one of those’ might be “SmartThings’ Generic Zigbee Switch” or “Cholmondley’s Foobar Switch with extra knobs and whistles”.
Sure, but that’s talking about command classes, not device types. It’s true the different manufacturers will use different command sets a little bit differently. But zwave devices identify themselves by their device type, and that doesn’t vary.
Several community members have posted that automations that worked for years with a gocontrol Wa00z-1 button controller stopped working after the device was automatically transitioned to a Z wave switch edge Driver. Its zwave device type is 0x5343. Completely different device class. (A switch is 0x5753.) The only command set it uses is basic, which every zwave device uses.
https://products.z-wavealliance.org/products/1529/embedpics
The whole point of the Z wave “basic” commandset is that it is handled differently by different device classes. So if you’re mapping based on that, you’re going to make a lot of errors.
So I noticed. As the button driver doesn’t include the device explicitly in its fingerprints and doesn’t have generic fingerprints it couldn’t use that so it found the best match which happened to be the switch driver. If the driver didn’t mention ‘switch’ in its name it wouldn’t have even been worthy of comment.
You could perhaps argue that the generic fingerprints in the switch driver should be more fussy about the product types but there might be a reason there aren’t and it would just have meant the device paired with something else and still didn’t work.
The stock device handlers I have seen for ZWave buttons don’t have generic fingerprints which might be why the driver doesn’t have any either. It is the handlers that have been ported, not the devices.
Yes, there is more that could be done with generic fingerprinting and product types and the like, but that’s got to be low down the priority list at the moment. It’s all about getting migration over the line.
The timing of this issue is suggestive of the use of custom handlers. That’s the real problem.
Where do I pick one up? Prefer a sale price
This discussion, seems to me, is very timely now that all devices are off DTHs and transitioned (good or bad) to some Edge driver. This is a good time to pull that transition logic and do a better job of mapping new devices.
Maybe create a new thread on this?
(posted without any real hope of a reply)
@SmartThings @nayelyz @Kianoosh_Karami
Is there an end date for automatic migration of devices from Groovy DTHs to Edge drivers? I’m looking for a date after which I should give up and do my remaining devices the hard way.
I have eight remaining devices not migrated. No changes for months. All the devices are @TheSmartestHouse Zooz ZEN26 and ZEN27 in-wall Z-wave switches or dimmers. All are using the stock DTHs and have been for years.
I have 18 other Zooz ZEN26 and ZEN27 devices which have been successfully automatically migrated.
Yeah. It would be nice if, at some point, they finally just said “It’s done.”
Same thing happened to me. I just happened to be on vacation when all this went through. My petsitter was telling me the lights were on during the day, doors weren’t locking as they were supposed to be and other oddities. I checked ST app and almost all my routines were off. Oddly enough, there were many that were off that were not referencing ‘missing’ devices too. I have no idea what they did here. I turned them all back on and everything is working as expected.
What a s*it-show.
Hi, @HalD, @art_333 and any other user
Can you provide info about the devices that haven’t been migrated, please?
I would like to ask the engineering team about them to get more information.
- Go to the SmartThings Web (my.smartthings.com)
- Log in to your Samsung Account
- Select Menu (⋮) and choose Settings
- Toggle on Account Data Access
- Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
Thanks!
@nayelyz Thanks, but all of my devices seem to have migrated successfully.
Thanks for trying to get all of this resolved!
Thank you for helping move this along.
Email here and Samsung account are the same
Data access granted
All my devices are working without issue including both those on Edge and the remaining ones on DTHs
Here are the ones on DTHs. What additional information do you need?
Edit to add:
All are Zooz Z-wave Plus
Following are ZEN26 switches:
Following are ZEN27 dimmers
As mentioned in my previous post I have 18 additional Zooz ZEN26 and ZEN27 which were automatically migrated some months ago. Those were all migrated from stock DTHs to stock Edge drivers. In the last couple of weeks I installed the Zooz Edge driver and changed them all to use it.
Are they all the same mfg and device type?
I have a handful of virtual switches still showing DTH in the advanced SmartThings Web portal. Is that unexpected? I had most of mine migrate a few weeks ago, and then a few more between then and now, but there are 5 left that show DTH. They seem to be working fine so happy enough to wait for them to migrate.
