Automatic driver selection logic, picking incorrect driver

🚧 Developers Coding Questions
1

I think this may come down to having a zwave device as secure.
What is the proper way to do the fingerprint to allow both unsecure and S2 included devices to be picked up?

Backstory, I paired a new device and it picked up another custom driver I am working on with similar fingerprint but not matching.

Device fingerprint (per the "Device" driver):
fingerprint mfr:"027A", prod:"0004", deviceId:"0110", inClusters:"0x5E,0x55,0x9F,0x6C,0x22"

Driver that got selected:
fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"0x5E,0x55,0x9F,0x6C,0x22"

The deviceId is the only value that differs, but this indicates it is a totally different device.
The other difference between these two devices would be in the "secureInClusters", but they are still very similar.

Can/should secure clusters be included in the fingerprint?
Or how do we ensure the driver is only selected for the correct device???

New device secureInClusters:
secureInClusters: 0x86,0x85,0x8E,0x59,0x72,0x5A,0x87,0x73,0x7A,0x70,0x71

Other device secureInClusters:
secureInClusters: 0x86,0x85,0x8E,0x59,0x72,0x5A,0x87,0x73,0x7A,0x71,0x80,0x70

1 Like
2

If you add the fingerprint as generated by the Device driver (in particular the drviceId) to your your target driver you should be fine no matter the clusters included.

3

That is exactly what I do. The "new" device did not have any driver established yet, but the hub selected a driver with a different deviceID instead of just the generic "Device" driver that usually gets set on unknown devices. I was thinking maybe this was due to the mfg, prod and inClusters being a match, which the inClusters are the same on nearly all S2 included devices that I have so matching on that is useless.

So if an exact mfg/prod/deviceId match is not found, then what is the logic after that?

4

It looks at the clusters for an exact match, including the order

5

What about the secureInClusters for secure devices? Does that come into play at all?

If not, I think it would be better for Z-wave devices that support security to NOT include the inClusters in the fingerprint (in the driver code) at all, to avoid false matches. Since most devices will have the same inClusters when paired with security.

6

Thats possible in the future.
Secure inclusters are not part of the discovery process.

Are you saying that if the driver has mfr, prod and deviceId match that we arent selecting it?

7

No, I think that works. The problem is that I have been using the fingerprint with InClusters from a secure device, so it is only 4-5 typically.

I just included a device this week where the mfg, prod and inClusters match, but the deviceId does NOT match. This is the Problem. The driver it selected is for a totally different type of device. There was NO driver installed at the time with an exact mfg/prod/deviceId match.

I could see where if the full cluster list including the secureInClusters matched, then yes, although the driver is not an exact match it may be "close enough" and support the same features.

So I think best practice going forward would be to only include the full inClusters when a device is included with no security, or to leave the inClusters out totally. I will just remove the inClusters from my driver fingerprints, they should only be selected for a device with an exact mfg/prod/deviceId match. From what you have said, I believe if I removed the inClusters from the drivers in question, AND removed the "new" driver I have since added, the device would have paired up with the "Device" driver as I expected it would.

8

@mike.maxwell now what I am doing wrong?

Driver has this:
fingerprint mfr:"027A", prod:"0904", deviceId:"0218", deviceJoinName:"Zooz ZEN54 0-10V"

Pairing the device gets me this (did not match up driver)

image
image696×100 9.83 KB

I do not have the inClusters in the fingerprint on purpose, because of what was discussed above.

9

What fingerprint does device produce?

10

Its in my screenshot up above.

11

huh, which driver did get installed?

12

That quote you posted is no longer relevant to my latest question.

Start over

I added this device:

image
image696×100 9.83 KB

It selected the "Device" driver.

Meanwhile a driver with this fingerprint was already installed:
fingerprint mfr:"027A", prod:"0904", deviceId:"0218", deviceJoinName:"Zooz ZEN54 0-10V"

Why did it not select this driver? I thought it should pick it based on mfr, prod, and deviceId being an exact match?

13

yeah, its supposed to, will check out...

14

My hub was also getting a low memory warning at the time. Its a C7 on newest firmware. Was only running for a week and this is my dev hub which mostly just sits there and gets driver code pushed to it from VSCode. Free Mem was at 60Mb. Everything else was working fine so I was letting it play out. Since then I was fighting with a USB zwave stick to try and use Replace so it would update and I jammed up the zwave pretty good so I had reboot.

Long story short, I will probably exclude and include this device again on a freshly rebooted hub and see if that changes anything. I need to update the firmware on the device anyway, which I cannot use the Hubitat app since the device is on S2 security and the app is still broken :frowning: .

15

After rebooting the hub I paired it again and still same thing, set it to the "Device" driver.

16

This came up again and I had to find my old thread to see if it was the same problem. Still having same issue. mfr, prod, and deviceID are exact match. No inClusters are defined in the driver. Hub determines it is an unknown device and assigns "Device" driver.

This is not a major issue for me, I can select the driver myself. What I am trying to do is code my drivers properly so that for other users the hub will select the correct driver for them.

17

was there some reason you can't include the in clusters in the driver fingerprint?

18

When paired securly the inClusters only lists 4-5 clusters that work without security, which are very common on MANY zwave devices when also paired securely. This is what resulted in the problem from the first very post where the totally wrong diver was selected due to just an inClusters match.

If the secureInClusters list was also considered then I would include the cluster info.
I could include the full clusters list as inClusters, which would probably allow it to match if paired without security, but if paired with S2 it would not match.

Seems perfectly logical though to match on the 3 things that identify the exact device by mfg/model (mfr, prod, and deviceID). The clusters I think is irrelevant if those 3 match (at least for Z-Wave).

19

I am about to release a new driver so I am testing this a little more extensively to see if I can get it working right. At some point (possibly this thread) it was said the inClusters should match exactly, same order. I have found that if I include ANYTHING valid looking for inClusters, it will then match on the mfr,prod,deviceId set. If inClusters is omitted the driver is not matched to the device at all. So it seems if you only want to match on the mfr,prod,deviceId then a bogus hex string should be in the inClusters.

Here is the actual inClusters of the device:

* inClusters: **0x5E,0x85,0x8E,0x59,0x55,0x86,0x72,0x5A,0x87,0x73,0x9F,0x6C,0x7A,0x71,0x80,0x70,0x22**

Here is what I tested (results commented on side)

		//fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"0x5E,0x55,0x9F,0x6C,0x22,0x86,0x85,0x8E,0x59,0x72,0x5A,0x87,0x73,0x7A,0x71,0x80,0x70" //MATCHED
		//fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"0x5E,0x85,0x8E,0x59,0x55,0x86,0x72,0x5A,0x87,0x73,0x9F,0x6C,0x7A,0x71,0x80,0x70,0x22" //MATCHED
		//fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"-" //FAILED
		//fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"" //FAILED
		//fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"0x00" //MATCHED
		fingerprint mfr:"027A", prod:"0004", deviceId:"0510", inClusters:"0x00,0x00" //MATCHED

This was all tested with no security. Going to test the "0x00,0x00" using S2 and assuming it should work there as well.

Guess I will possibly include the full insecure inClusters if I have it, and if not I will just use "0x00,0x00" to prevent any false matches.

EDIT: Tested two that worked above (full clusters and 0x00,0x00) with S2 and both worked there also, assuming due to matching on the deviceId since the inClusters is not a match if included with security.

1 Like
20

In the process of rbuilding my mesh tonight, I came across this issue . Paired a Zooz XS Temp/Humidity sensor to my C8 and it included as Aeotec Door/Window Series 7 Sensor.

image
image924×67 7.82 KB

image
image1188×258 14.8 KB

Is there a time line when this might be corrected?

1 Like