Device discovery issues system or my hub?

I have two custom device type implementations which I am trying to transition to Edge drivers. Custom Groovy DTHs for these devices had worked for years. I have found a generic SmartThings or community Edge driver for each that with minimal modifications work with generic fingerprint. The problem I have is with the device discovery process not completing to support a Manufacturer-specific fingerprints. Previously, device discovery functioned as follows with coordinator, or hub, (C) and device (D) transactions.
(D) Device Announce
(C) Active EP request, (D) Active EP response
(C) Simple Descriptor request, (D) Simple Descriptor response
(C) Cluster Basic, attribute ID App Ver request, (D) Cluster Basic, attribute ID App Ver response
(C) Cluster Basic, attribute ID Manufacturer request, (D) Cluster Basic, attribute ID Manufacturer response
(C) Cluster Basic, attribute ID Model ID request, (D) Cluster Basic, attribute ID Model ID response

Now, in the best case, the discovery process is running through the (D) Simple Descriptor response at which time it stops and the system will pull in a Generic Edge driver if available or the pesky Zigbee Thing Edge driver. It never gets to the Cluster Basic information that would support a Manufacturer-specific fingerprint.

In the worst case, the process stops after (D) Device Announce and the system pulls in the Zigbee Thing Edge driver. Powering down the hub and powering it back up will take me back to the first case.

My questions are:

Q1) Does the device discovery process still work as described above (through Cluster Basic, attribute ID Model ID response) or has there been a system change?

Q2) If the device discovery process still works as described above, then do I have a hub failure?

1 Like

Hi, @0xDC

Have you checked the process in the driver logs?
It would be helpful to know if your driver starts but doesn’t finish the process. If it starts, it means it was considered a match for the fingerprints exposed by the physical device but it fails at some point.

The driver logs can be seen using the SmartThings CLI and its command smartthings edge:drivers:logcat

About your question, I shared it with the engineering team to see if we can get more information about this.

1 Like

Powered down for 20 minutes. Removed Zigbee Thing from hub. Started smartthings edge:drivers:logcat all. Add Device - Discovery went through Device Announce then stopped. The driver logs didn’t have any relevant information, by name or assigned 16-bit network address.

Did it pair with the Zigbee Thing driver again? Can you share the device ID so we can look at the logs of the discovery process, please?

Also, please send the Hub logs just in case as follows:

  1. In the Advanced Users app, enter the “Hubs” section
  2. Enter the corresponding Hub and click on “Dump Hub logs”
  3. Confirm the process by clicking on “Dump Hub logs” again in the pop-up.
  4. You’ll get a green box at the top confirming the Hub logs were requested.

I removed Zigbee Thing from Hub-Installed Drivers prior to the above trial.
I requested the hub log anyway. Add device was started at 15:40:00.515 PST
logcat corresponding time 22:40

Mmm as Zigbee Thing is part of the SmartThings stock drivers, even if you delete it, it should be downloaded again because it is the last step in the fingerprint match priority, this means the device gets paired to that driver when no other match was found already installed or as part of the other ST drivers. I don’t know if it didn’t because you recently deleted it or what happened there.

I’ll see if the team can look at the Hub logs, but I need the Hub ID this time to find them in the server, you can get that value from the Advanced Users’ app > Hubs:
You can share it with me over DM.

Has the engineering team provided any feedback on my device discovery question and where my problem might be?

1 Like

Not yet, they currently have a heavy workload.

From issues we’ve seen in the past, is your device a Zigbee-certified one? This means it follows the standard of the protocol.
It would be helpful if you provided the brand and model.
When a device is not recognized and is connected to a “Thing” driver (Zigbee or Z-Wave) it can be due to the following:

  • There are no drivers installed in your Hub that match the fingerprints exposed by the device.
    • When you’re pairing a device, once the driver matching it is initialized, its fingerprints and supported clusters are printed there.
    • Once the device is installed (no matter if it was with a Thing driver), you can see that information in the Advanced User’s app as well (the properties name is Manufacturer Code and Model for Zigbee)
      This way, you can confirm the values you used in the fingerprints.yaml of your driver are correct.
  • We’ve seen some physical devices are not announcing their fingerprints correctly, so, in that case, it would be useful if you replaced the manufacturer-specific fingerprint for a generic fingerprint using the supported clusters. Here’s an example:


It is not a certified device, it is my own custom device.
I have made both a generic fingerprint and a manufacturer-specific fingerprint for the device.
If the discovery process gets through the Simple Descriptor response it will use my generic edge driver and the device functions.

Since the discovery process stops before the Cluster Basic transactions necessary to get the manufacturer, model, etc, for matching my manufacturer-specific fingerprint it will never get selected.

Thats why I need engineering to first confirm the basic discovery process above is still used and if it is, then do they have any ideas why my hub does not complete it and can the hub be salvaged.

Hi, @0xDC
Following up, the engineering team mentioned the following:

  1. The discovery process still works as you described (through the basic cluster model read)
  2. They looked through the logs for the join around 15:40:00.515 PST and saw that the discovery process started, but we didn’t get a response to the active endpoints request. ST attempted to send that request 3 times in total before failing discovery since we didn’t get a response.