core: Zwave js - Vision Security ZD2102 missing entity

First thing, If you want the software to support the configuration parameter, you need to go to node-zwave-js and submit a request to have it added (or do it yourself). The parameter will not be available in HA until the device config specifies it. If you use zwavejs2mqtt, it has the capability to set custom config parameter values, so you can change it w/o the device config file being correct, but this isn’t supported in HA.

Continuing on with the entities issue, according to your dump, you have these values:

• A Binary Sensor value. I presume this matches a binary_sensor entity which reflects the reed switch operation.
• Home Security - Sensor Status, which is also the reed switch notification.
• Home Security - Cover status, which is the tamper switch notification
• Home Security - Unknown, which is the external switch notification

The problem with all of these Home Security values is that they have the metadata type of "any", which is not something HA supports (and in my opinion it is incorrect for zwave-js to reports this type). This is also seen in issue #46982 (another Vision device…). For example:

              {
                "endpoint": 0,
                "commandClass": 113,
                "commandClassName": "Notification",
                "property": "Home Security",
                "propertyKey": "unknown",
                "propertyName": "Home Security",
                "propertyKeyName": "unknown",
                "ccVersion": 2,
                "metadata": {
                  "type": "any",
                  "readable": true,
                  "writeable": true
                },
                "value": 254
              },

So until this metadata type gets corrected to "number", HA cannot support them. That needs to be solved in node-zwave-js first.

However, I’m not sure that helps you. Let’s say those values were supported as sensors today, the next problem is that they will never idle, unless zwave-js does an auto-idle based on time. That makes them pretty useless. The device itself never idles those values, so you can never tell when the switches go from off <=> on. For this you need to use the Alarm V1 types, alarm level and alarm type. Z-Wave JS is not exposing these values because they are Alarm V1 values, but the device supports V2 notifications.

Even if you have the V1 values exposed, I think there are problems. IMO, this device incorrectly uses the notification system to report the external sensor events. Let’s look at the documentation posted from the OH thread.

Note that Alarm Type and Alarm Level are Alarm (Notification) V1 CC values. The Alarm Event value is from Notification (Alarm) V2 CC. In order to distinguish events from any of the switch types, you are required to examine both V1 values plus the V2 Alarm Event value. If you use only the V1 values, you cannot distinguish any event at all: if alarm type is 7 and alarm level is 0xFF, which switch is it? If you look at only the V2 value, you never know if the value was on or off. This does not seem like behavior that falls within the Z-Wave spec to me, but maybe I’m wrong. Z-Wave JS does not support it anyways.

Here’s some analysis of the raw messages coming from the device to illustrate more.

Here’s the external switch sending an “open” notification.

2021-06-06T13:16:14.879Z SERIAL « 0x0112000400070a710507ff00ff07fe0000b500db                          (20 bytes)
2021-06-06T13:16:14.882Z CNTRLR   [Node 007] [~] [Notification] notificationMode: "pull" [Endpoint 0] [internal]
                                   => "pull"
2021-06-06T13:16:14.884Z SERIAL » [ACK]                                                                   (0x06)
2021-06-06T13:16:14.898Z DRIVER « [Node 007] [REQ] [ApplicationCommand]
                                  +-[NotificationCCReport]
                                      notification type:   7
                                      notification status: 255
                                      notification event:  0xfe
2021-06-06T13:16:14.907Z CNTRLR   [Node 007] [~] [Notification] Home Security[unknown]: 254 => 254  [Endpoint 0]

The raw data received from the device is the first line. It can be broken down as:

0x0112000400070a710507ff00ff07fe0000b500db
  0112000400070a
    71	notification cc
    05	alarm report command
    07	alarm type - 7
    ff	alarm level - 0xff (255)
    00  zensor net source node id
    ff  z-wave alarm status - alarm enabled
    07  z-wave alarm type - home security
    fe  z-wave alarm event - unknown event/state (external sensor)
    00  number of event parameters - 0
  00b500db

The useful values here are the V1 alarm type (7) and alarm level (0xff) and z-wave alarm event (0xfe). Those values match the manual that was posted, indicating the external sensor is open. But if you look at V1 values alone, you don’t know it’s the external sensor.

Prior that that, there was also the notification for the reed sensor opening:

2021-06-06T13:16:11.656Z SERIAL « 0x0112000400070a710507ff00ff07020000b50027                          (20 bytes)
2021-06-06T13:16:11.658Z CNTRLR   [Node 007] [~] [Notification] notificationMode: "pull" [Endpoint 0] [internal]
                                   => "pull"
2021-06-06T13:16:11.659Z SERIAL » [ACK]                                                                   (0x06)
2021-06-06T13:16:11.661Z DRIVER « [Node 007] [REQ] [ApplicationCommand]
                                  +-[NotificationCCReport]
                                      notification type:   Home Security
                                      notification status: 255
                                      notification state:  Intrusion
2021-06-06T13:16:11.665Z CNTRLR   [Node 007] [~] [Notification] Home Security[Sensor status]: 2 =>  [Endpoint 0]
                                  2

Raw data:

0x0112000400070a710507ff00ff07020000b50027
  0112000400070a
    71	notification cc
    05	alarm report command
    07	alarm type - 7
    ff	alarm level - 0xff (255)
    00  zensor net source node id
    ff  z-wave alarm status - alarm enabled
    07  z-wave alarm type - home security
    02  z-wave alarm event - intrusion (reed switch)
    00
  00b50027

Again, notice the only difference here is the V2 z-wave alarm event. The alarm type (7) and alarm level (0xff) are both the same as the external switch. It’s impossible to distinguish the notification meaning based on the V1 types alone. Thus you need to examine all 3 to distinguish the event type.

The tamper switch itself never goes idle, you cannot tell if it’s open or close as it always sends the same alarm level (0xFF). At best you know something happened.

So in HA, there’s nothing that can be done to support the tamper and external sensor unless node-zwave-js presents a different metadata type than "any".

Even if the event metadata type was correct, or V1 alarm values were exposed, it’s unclear that this device would still be usable. I would advise starting a discussion topic, or submitting in issue to see if there’s any way for the driver to support this. The way I see it, you could try to argue that the Alarm V1 values (alarm level and alarm type) should be exposed, but those two values alone are not enough to know which sensor is actually activated. You need that third alarm event value, and there’s no way to tie all three together into a single event.