Hi, @MartynWendon, sorry for the delay.
Thank you for sharing your results.
I wasn’t able to replicate the issue but I shared your comments with the engineering team to see if they find something in the logs you submitted.
I’ll let you know when they provide their feedback.
2 Likes
Hi, @MartynWendon
Reading your comment again, I see you mentioned your device is connected to a Zigbee driver but when you try to delete it, a Z-Wave removal starts. It shouldn’t happen if your device has type: “Zigbee”…
This was when the device wasn’t getting matched to my device driver, it was getting matched as a “Zigbee Thing”.
When trying to remove that device from the iOS App it starts the Z-Wave removal.
It seems to be reproduceable for me:
- Start from a fresh hub, no custom device drivers
- Pair a Zigbee device that loosely fingerprint matches (via Clusters) a built-in device driver (in my case this was the HumidityTempGeneric - SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-humidity-sensor/fingerprints.yml at main · SmartThingsCommunity/SmartThingsEdgeDrivers · GitHub
- The built-in device driver is now downloaded onto the hub and the device is assigned to it
- Remove the device
- Add a custom device driver that now explicitly matches the device fingerprint
- Pair the device
- The built-in loosely matched device driver is stlll prefered even though a custom device driver that explicitly matches is now available
The only way that seems to remedy this is to either -
- Manually switch the device driver in the App (which then has issues since any initial configuration during pairing in the custom device driver doesn’t run).
- Remove the device, delete the downloaded built in device driver, reboot the hub and then pair the device again.
3 Likes
Hi, @MartynWendon
The engineering team deployed a fix for this issue, please let us know if you see it again.
3 Likes
Hi @nayelyz this still doesn’t seem to be working correctly.
I’ve just been working on another device driver which is pushed onto my development hub and has a fingerprint that explicitly matches the device.
But during pairing the hub is again downloading the SmartThings Zigbee Switch device driver and using that in preference to mine, matching it against the Zigbee Clusters:
You can even see that the hub “knows” that my device driver matches the device fingerprint, because it is offering it as an option to switch to immediately after pairing. If the fingerprint in my device driver wasn’t correct, it would not offer it here.
I dumped the hub logs, can your engineering team see why this is still happening please?
Hi, @MartynWendon
Can you open support access to your account, please?
- Confirm the email account registered in the forum is the same one you use for SmartThings. If not, please share it with me over DM
- Enable support access to your account:
- 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.
1 Like
Hi, @MartynWendon
The engineering team let us know that a fix for the issue went out today, it seems there was something wrong only in the EU region, so that’s why the first solution wasn’t effective for you.
Please, let us know your results.
2 Likes
Hi @nayelyz that seems to be working fine now, I retested with a couple of the devices that gave the issue previously and now the correct device driver is selected even if a loosely matching existing generic device driver exists.
I’ll mark this as solved, thanks very much for your help!
3 Likes