The product lines which are now LEDvance were originally developed and owned by Osram, and then sold to a Chinese company, MLS.
(They actually went through a phased ownership transfer, where initially the Chinese company only bought a third of the business, but eventually acquired all of it.)
So there’s a historical connection and some of the designs are from models which were originally labeled Osram or Sylvania. (Sylvania was a brand-name used in the United States.)
I know but what I meant is that Osram (AFAIK) doesn’t sell zigbee products anymore so It’s a bit weird to keep Ledvance out of the supported devices website as it may lead to misunderstandings for customers.
So, my devices (frient energy monitor and Samsung smart plug) went offline this morning around 08:24 BST (GMT + 1.) Is this related to the driver changes? My hub is online, powering off/on didn’t fix anything …
I’ve just paired a generic zigbee plug to my SmartThings hub,
and it’s still getting paired with the stock zigbee switch DTH, not zigbee switch edge driver.
Your device is not in the fingerprints for the stock Edge driver. That device is, however, supported by the Zigbee Switch Edge Driver from @Mariano_Colmenarejo. Follow the directions in this link for how to subscribe to his channel and install the driver.
I’d venture a guess that the fingerprint for that device is an exact match in the DTH vs the generic in the Edge driver. Try installing the driver I mentioned and see if your device installs with that vs the DTH.
I think that Jaewon’s point is that nothing should be joining with a DTH anymore since we’re passed the 24th. Whether there’s a generic or specific fingerprint in an Edge driver shouldn’t matter. So it appears SmartThings missed their cutoff date…again.
There isn’t fingerprint of this device in stock zigbee switch DTH, but only generic fingerprint of OnOff cluster (0x0006).
Custom driver gets precedence over stock driver.
If I’ve installed custom edge driver to my hub, it should have been paired with the custom edge driver.
What I’m saying right now is… about precedence between stock DTH and stock Edge driver, which is different from what the announcement says.
currently, when a new device is paired, stock Zigbee DTH has more priority than an edge driver with a generic fingerprint, in this case for the driver to have a higher priority, you will need to use a specific fingerprint.
There have been a couple of reports in the last week from people saying that, even though they had a custom edge driver loaded with the exact fingerprint match, the device was still selecting the stock DTH. This was a new issue, which had not happened previously.
Here is one example of someone who is unable to get their device to pair with any edge driver because it is always selecting a stock DTH.
Again, this is a new problem, which just showed up in the last week or so.
Hi, @JDRoberts
We’ll check what’s going on with the case you mentioned.
However, generic fingerprints are a different scenario in this particular case. We’ve received previous reports about people not being able to link their devices with stock drivers even when they are already installed in the Hub but the driver has only generic fingerprints that match the device.
We reported it and during the investigation, the team discovered that the DTH was selected first because in the Groovy world, generic and specific fingerprints weren’t treated differently, so, even if the fingerprint in the DTH is a generic one, it is still considered a specific one which “wins” the selection of the device controller over the generic fingerprint in a driver.
So, just to be clear, the case of generic fingerprints is different than the one with specific ones which definitely needs more investigation.
I was under the impression that devices with Groovy drivers would be transitioned to Edge drivers in spring. I just checked a Monoprice door/window sensor, and it’s still on the old Groovy driver. Did Smartthings decide not to do the transition?
Well the answer is that the device has very recently switched to using the Zigbee Switch driver, presumably via a generic fingerprint as the manufacturer fingerprint has not been ported across from the DTH. This should hopefully be fine as long as the default Zigbee Switch driver behaviour is based on the ZigBee Switch DTH as the latter didn’t have any bespoke code. However I can imagine this would be ‘a bad thing’ for certified devices that do need special handling.
Now the interesting thing is that the hub was already using the Zigbee Switch driver for a number of devices and it was installed from the Beta channel. Now the Zigbee Switch driver has switched its allegiance and claims to have been installed from the Production Default channel. I am not sure what I expected to happen but that seems the least useful of the possibilities.
I had @philh30 Edge driver utilities [ST Edge] Z-Wave Masquerade installed under his channel and yesterday I found Smartthings was showing some working devices as offline and not working. I could not open the device in the App to see what driver it was assigned to. I tried editing the device name, and it then allowed me to open it, and I saw that ST randomly seems to be assigning devices to use Zwave Associator as their driver, migrated from their previous non-Edge drivers.
It feels like it’s dangerous to have generic drivers enabled during the automatic migration, since the hub might assume these debugging drivers are Edge drivers that support the particular product’s capabilities and it will migrate from a working driver/DTH to this non-functional driver, in the process deleting all associated routines (!!!) so I can’t just change the Driver back, I have to rebuild all my routines.
I had 5 convert last night…the first in quite some time.
2 Leviton plug-in switches were connected to “Z-Wave Associator”, which did not work. I changed the driver to Z-Wave Switch. All good now.
2 Aeotec Nano Dimmers lost their min and max values. At 5:30 this morning, I was woken by the lights flashing every 30secs or so. After rebooting my phone, thinking I somehow turned on flashing of the LED for notifications, I later discovered it was the room lights flashing. After correcting the min/max values, these are good.