Fingerprint Question - Defining / Using Custom Fields

I have two questions on fingerprints

  1. Can "custom" fields be added which can then be accessed from within the driver
  2. What is the proper way to access the fingerprint field information from within a driver

Here's one use case . . .
I'm working on a custom Switch / Dimmer driver that can be used with multiple switches / dimmers, but yet still has customized parameter inputs for each particular device.

To do this, I'd like to add a custom field to the fingerprint, let's call it "parameters" which would then be defined as a map or other data structure that gets set for a matching fingerprint and defines the device parameters of interest for each parameter (i.e., for each parameter, defines the relevant parameter #, label, size, etc). Using this field, I would then set up the "preferences" section with the "parameters" field that gets defined based on the fingerprint match.

Is this currently possible?

the fingerprint field is not accessible within the driver.

We use the data values manufacturer and model for zigbee, along with the devicetype, deviceId and manufacturer for zwave if we need to make driver code decisions.

While the prospects of a universal intelligent driver seem appealing, several parts of the schema currently aren't up to the task.
It's also much much easier to create and debug dedicated drivers vs those that attempt to support multiple devices.

Thanks. As a longer-term request, please consider making the "matched fingerprint" with field customization available in the driver. I realize what I'm proposing might not be something for all drivers, but if it isn't too hard to add this transparency to the driver, there are cases like what I'm proposing in which it may provide useful information (particularly if you could use the match to also supply some custom fields).

A couple workarounds I have done for some of my drivers:

  1. Recognize the model type ( after install. This does not help control what Commands, Capabilities, or Preferences are allowed for that device but it does at least give an option for controlling some of the functions and what settings are used in the driver itself.
  2. You can also make your driver Preferences display different sets of information based on Preferences saved. For example, in most of mine I have a "Show All Preferences" Preference (a boolean) to hide things once people have configured them. But you could easily expand on that to have it be more configurable is someone selects from a list of device types as a Preference.
1 Like

Thanks. I suppose using this information gets me pretty close to what I was looking for, so using the approach you suggested makes sense for now. Is there somewhere that the full "contents" of are defined?

Not that I know of (I tried searching the developer docs and community before answering).

@mike.maxwell: Is there anywhere that states what is available in for a driver?

Thanks. I realized after posting that I can probably just do a "Device data struture ${}" 

to figure it out.

That type of thing usually tells you what is there but may not include all the POSSIBLE data (like if things populate differently between Z-Wave and ZigBee) or such I would think. Plus sometimes things do not quite provide everything. For example, showing ${ resp } (response from an HTTP request) would not show everything included in ${ }.

1 Like

it's an adhoc non schema constrained element designed for seldom changing, non event related data.

Thanks. I guess the real question is "are there certain data fields that I can count on being there for (i) Zwave, and (ii) Zigbee" (or, similarly, if the device can provide them, they are there, and if the device can't, they are blank). I assume there are some - like a manufacturer ID, but wasn't sure.


  • endpointId: 02
  • application: 02
  • manufacturer: Philips
  • model: SML002


  • deviceId: 12338
  • deviceType: 20304
  • manufacturer: 99
  • inClusters: 0x5E,0x56,0x86,0x72,0x5A,0x85,0x59,0x73,0x25,0x27,0x2C,0x2B,0x7A


Just curious - was zwNodeInfo recently added as a "standard" always-there field - I'm seeing a lot (all?) of my devices with this recently. Would also love to see firmware version as a standard field.

zwNodeInfo: 53 DC 80 04 40 03 22 72 7A 98 86 68 23 F1 00 5D 85 5C 20 80 70 62 71 63

zwNodeInfo is set for c7 hubs only.

1 Like