Can "custom" fields be added which can then be accessed from within the driver
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.
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:
Recognize the model type (device.data.model) 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.
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.
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 device.data are defined?
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 ${ resp.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.
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.
