New Z-Wave Fingerprint Format

Announcements
,
1

Hey, device type devs. Yesterday’s deploy introduced a new format for fingerprinting Z-Wave devices based on the new device description that was added in 0.14.39. You can finally fingerprint devices based on manufacturer info instead of just type and command classes. We still need to get this working on hub v1 before you can rely on it, but we decided to make it available now so you can try it out and help us test.

Here are some ways you can fingerprint Z-Wave devices now, assuming you’re adding them to a v2 hub:

fingerprint mfr: "0086", prod: "0102", model: "004A"

fingerprint type: "0701", cc: "71,85"

fingerprint cc: "5E,86,72,98", sec: "25,70,27,32,81,85,59,7A,73", secOut:"5A,82"

The available fields are:

  • type: the device type code
  • cc: the supported command classes
  • ccOut: the controlled command classes
  • sec: the command classes supported only via secure encapsulation
  • secOut: the command classes controlled via secure encapsulation
  • mfr: the manufacturer ID
  • prod: the product type ID
  • model: the product ID
  • ver: the device firmware version
  • deviceJoinName: if the device joins with this fingerprint, the name will be set to this value (like ZigBee has had for a while)

Some things to note:

  • The mfr, prod, and model fields are the 3 ID codes that almost every Z-Wave device provides via the ManufacturerSpecific command class. These can generally be counted on to be the same for all devices of a single model.
  • You can usually find the prod and model values on products.z-wavealliance.org where they are called (their real names) Product Type ID and Product ID respectively.
  • All values except versions are hexidecimal strings – we dropped the “0x” prefix for convenience.
  • The type field is an alias for deviceId, so you can put the same thing in there as before, or you can use the ff or ui values from the raw description, which correspond to Z-Wave Plus GUI recommendations, and are sometimes more useful.
  • The new fields, including deviceJoinName, won’t work for older firmware versions until we finish an auto-conversion adapter that’s in progress.
17 Likes
3

Thanks for the info Duncan. Will check it out, I have a LOT of fingerprints with me for locks, thermostats etc. However do note I’m still on the V1 hub (I don’t see any migration utility for v2 so not really keen on doing it manually). Do let me know once it’s ready to test on V1 and I’l update the DH’s.

Also are we guaranteed that the above information will be available as soon as the DH installed is called?

1 Like
4

How soon before the promised migration tool is available? If ST would just deliver on that promise, they could have most v1 users upgrading, saving money on having to continue to support v1 at all. Any date when we can expect it?

4 Likes
5

I honestly don’t see this happening. Take the time to manually move your devices over to the new hub. As an added bonus, you’ll get to clean up your setup and rebuild the mesh for ultimate performance

2 Likes
6

Not from what I hear with v2 hub users their mesh appears to have more issues. Honestly with a few repeaters around the lab and house across 3 floors I’ve never had an issue with my v1 hub. So really I’ll only put in the effort if they make it easy otherwise I’m okay with v1. There’s really no advantage to v2 (except for the firmware bugs). I’ve already added a UPS backup for all my stuff so the battery is really useless to me right now. V2 is a ZWave plus, not sure how much more benefit I can get. My house motion sensors have been on a battery for a year and a half now and it’s still reporting 90%!!! So apart from my locks which drain battery like a killer (every 4-6 months) I’m good.

2 Likes
7

What motions do you use @RBoy?

8

Ecolink and Monoprice. The monoprice are new but the Ecolink ones have been installed for over a year and a half now with the same batteries.

2 Likes
9

Now here’s a KEY thing to note, most of my sensors are in pet mode. When I put ecolink in regular mode it used about 5-7% battery per month. In pet mode I just checked after 1.5 years it still > 95% (same room 2 sensors). When in regular mode ecolink battery drops faster (5-7% per month) than monoprice (<1% per month) but when in pet mode they both appear to be draining at the same level, about 1% every 3-4 months.

10

@duncan 3 questions:

  1. Can a DH have a combination of new and old style fingerprints?
  2. Do you have a ready example of mapping the old inClusters to the new format?
  3. What will happen if the new fingerprints are used on the v1 hub?

Thanks

2 Likes
11

@duncan reminder on the above please

12

I had an issue with the new raw descriptions not showing the security command class in the fingerprint when secure inclusion failed causing them to not get identified. (The ST Aeon Siren DTH also has this problem)

I ended up using the 3 fingerprints below in my DTH and it now gets identified on hub v1 and hub v2 regardless of whether secure inclusion was successful.

        fingerprint mfr: "0086", prod: "0104", model: "0038"        

        fingerprint deviceId: "0x1005", inClusters: "0x5E,0x25,0x70,0x72,0x59,0x85,0x73,0x7A,0x5A", outClusters: "0x82"

        fingerprint deviceId: "0x1005", inClusters: "0x5E,0x98,0x25,0x70,0x72,0x59,0x85,0x73,0x7A,0x5A", outClusters: "0x82"
1 Like
13

@duncan what will happen if this included in the DH and is deployed on a v1 hub or a hub with older firmware?

1 Like
14

If the ver is defined in the fingerprint does that mean the DH won’t be automatically identified for new locks of the same model if the version is different?

15

Atleast 1 product Id is wrong on this page (FYI) http://products.z-wavealliance.org/products/1025
The product ID written here is 0544 where as the lock reports 5044

Also a question, if there are 2 manufacturer Id’s (e.g. Yale) is there a way to combine them? Or can we display the product type ID and product ID without the manufacturer type?

16

@duncan Where can we find more detailed information on this new fingerprint format? What you provide above seems incomplete or it expects the reader to be very familiar with it already. I studied both what you wrote above and also what can be found in the developer documentation but still have issues getting it to work properly.

My research on the supported classes:

Aeon Smart Switch 6 (ZW096-A02)

Supported Command Classes

0x27 All Switch
0x85 Association
0x59 Association Group Information
0x20 Basic
0x81 Clock
0x33 Color Switch (could it be Color Control??)
0x70 Configuration
0x5A Device Reset Local
0x7A Firmware Update Meta Data
0x72 Manufacturer Specific
0x32 Meter
0x73 Powerlevel
0x98 Security
0x25 Switch Binary
0x26 Switch Multilevel
0x86 Version
0x5E ZWavePlus Info

Controlled Command Classes
0x20 Basic
0x82 Hail
0x25 Switch Binary

Raw descriptions I copied after including the device a few times:

zw:Ls type:1001 mfr:0086 prod:0103 model:0060 ver:1.03 zwv:4.05 lib:03 cc:5E,86,72,98 ccOut:5A,82 sec:25,26,33,70,27,32,81,85,59,7A,73 role:05 ff:8700 ui:8700

zw:L type:1001 mfr:0086 prod:0103 model:0060 ver:1.03 zwv:4.05 lib:03 cc:5E,25,26,33,70,27,32,81,85,59,72,86,7A,73,98 ccOut:5A,82 role:05 ff:8700 ui:8700

I am guessing one was with non secure join, the other was secure.

My attempt at following your instructions for the new format:

fingerprint mfr: “0086”, prod: “0103”, model: “0060”
fingerprint type: “8700”, cc: “5E,25,70,27,81,32,26,33,59,85,72,86,7A,73,98,5A,82” //Leaving out EF in cc as it doesn’t appear in Raw Description
fingerprint cc: “5E,86,72,98”, sec: “25,26,33,70,27,32,81,85,59,7A,73”, secOut:“5A,82” //Leaving out EF in cc as it doesn’t appear in Raw Description

This is my attempt at the old format:

fingerprint deviceId: “0x1001”, inClusters: “0x27,0x85,0x59,0x33,0x70,0x5A,0x72,0x32,0x98,0x25,0x5E”, outClusters: “0x82,0x25”

This other fingerprint seems to work but I am not sure it is correct. It is for the Aeon HEM v2:

As for the prior device, this is the info I researched:

Aeon Home Energy Meter G2 (DSB28-ZWUS)

Supported Command Classes
0x85 Association
0x20 Basic
0x70 Configuration
0x56 CRC16 Encapsulation
0x72 Manufacturer Specific
0x32 Meter
0x60 Multi Channel
0x86 Version

Raw description from IDE:

zw:L type:3101 mfr:0086 prod:0002 model:001C ver:1.17 zwv:3.67 lib:03 cc:70,32,60,85,56,72,86 epc:2 ep:[‘3101 32’]

The fingerprint I came up with is:

fingerprint mfr: “0086”, prod: “0002”, model: “001C”
fingerprint type: “3101”, cc: “70,32,60,85,56,72,86”

Am I on the right track? Additional details in the documentation would be of very much help!

17

Hey guys,

is there any way to get the different fingerprint attributes from within the device handler directly ? For example, I would like to know if the device handler does have specific code in ccOut, any possibility ?

18

anyone…?

19

Do you mean - when you include the device, check out the raw line in the My devices tab then click the device you want to check

Raw Description zw:Ss type:0701 mfr:0108 prod:0002 model:000E ver:1.18 zwv:3.95 lib:03 cc:5E,72,86,59,73,5A,8F,98,7A ccOut:20 sec:80,71,85,70,30,31,84 role:06 ff:8C06 ui:8C06

You can see the ccOut of 20

20

Is anyone interested in a comprehensive list of all 100+ command classes? If so I can share it here.

21

Yes, I am interested.