I’m working on some custom Edge device drivers for some Zigbee sensors but despite the device driver explicitly matching the fingerprint of the device (manufacturer and model) it is persistently being matched to a generic default one based on matching the Zigbee Clusters that it supports.
My understanding is that if a custom Edge device driver exists in the subscribed channel that explicitly matches on the manufacturer and model (and has been instaleld on the hub), then it should be selected over a generic default one based on Zigbee Cluster matching.
If that is how it should work, then it doesn’t appear to be working as intended!
This issue is causing non-optimal generic Edge device drivers to be used for devices during pairing. While the user can “switch” the device driver from the SmartThings App after the device has been paired, this creates issues, for example with configuration that should occur during pairing.
You’ve probably already done this, but just to be sure (and because I’ve done something similar before!) I would check to be absolutely sure that you have an exact match between fingerprint from the device and what you have in the edge Driver file. Same number of characters, capitalization counts, no O’s instead of zeros, no trailing spaces, all that.
Also, if the pairing failed to complete, and you have a partial pairing, the fingerprint may not have been recorded correctly.
Yep, it’s the same data that matches correctly on other platforms (Hubitat, Zigbee2MQTT, Homey) so it’s definitely correct.
It was persistently being matched to the generic device driver, as in removing the device and re-pairing resulted in the same issue.
I see there’s an option for “Dump Hub Logs” in the /advanced UI, what does that do? Are we able to view the hub logs (as opposed to driver logs from the CLI) to see what happens during pairing?
I’ve got side-tracked on something else now, but will come back to this tomorrow hopefully.
This dumps the hub logs so that they can be analyzed by smartthings. In case of investigating a problem, they may ask you for them to debug your problem.
Hi, @MartynWendon. It’s great having you back in the SmartThings Community!
Indeed, as @Mariano_Colmenarejo mentioned, that button uploads the currently saved logs in the Hub to a server that only the engineering team can access. That’s why it’s important to dump them as soon as you see/replicate an issue, because depending on your network size and how chatty your devices are, they can be replaced by the logs of new events in 12 hours or less.
In this case, we can check what happened during the joining process to see why the generic fingerprint had more priority than the specific one.
Can you share the following, 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
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.
Replicate the issue (remove and re-join the device)
Hi Mariano. I tried many times and when I uninstal zigbee thing mc and still i have your moisture sensor installed but when i recognize device I have all time zigbee thing. This device not recognize properly… A dont know what happend
Hi, @Zbigniew_Wypij
It isn’t clear the steps you followed to get to the issue. Could you help us understand your situation, please?
First, a couple of suggestions:
Install only the driver you need to pair the device (I’m guessing you have also verified the fingerprint matches the device because @Mariano_Colmenarejo added it)
If you still see the issue, please help us collect the same info I mentioned above:
Hi, @MartynWendon
Is the device you have issues with the one with the fingerprint below?
Manufacturer: Shyugj Model:TempAndHumSensor-ZB3.0
The engineering team was able to pull your Hub logs but we don’t know if they include the failed join because the joining process seems correct but the driver crashes at some point.
Another thing to consider is the case of @Zbigniew_Wypij, because it might happen that the device isn’t attempting the connection correctly due to its low battery.
Yes, that was the device. I actually tested again on a different hub and didn’t experience the same issue.
When I then returned to the original hub I cleaned up a load of old development devices, removed some unused device drivers and rebooted. After that I couldn’t reproduce the problem anymore, so I assume it was just a one-off (albeit it was repeatable at that time).
I would say that the logs didn’t inlude the failed join, because if they did then presumably they would have shown the device ending up with the “HumidityTempGeneric” built in device driver?
An update, I’ve experienced a similar issue but with another device.
The same hub as before, I dumped the logs.
This time it’s the device "manufacturer: “Shyugj” model: “WaterLeakageSensor-ZB3.0” and is being assigned “Zigbee Thing”.
The fingerprint for this device is in driver “235003e5-e41f-44e8-a9fb-c78626c6eed9”.
I should add a couple of things:
I initially made a typo in the fingerprint in the driver file, but subsequently corrected it and re-installed the driver
When trying to remove the “Zigbee Thing” in the iOS App, it starts the Z-Wave removal. I had to delete the Zigbee Thing device from the web UI /advanced area
After pairing again (as Zigbee Thing), in the iOS App, I can hit “Driver”, “Select different driver” and am offered the driver from above as an option, so it clearly knows that there’s a matching fingerprint there now.
Perhaps there’s some issue with the logic, that once a built in device driver has been downloaded to the hub, then that will be preferred during initial pairing even after the device has been removed and re-paired?
indeed … one of the reasons why I only begrudgingly develop on SmartThings when I absolutely have to!