node-zwave-js: Touchscreen Deadbolt Z-Wave Plus no longer reports Keypad unlock notifcations

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

NO, my problem is NOT within Home Assistant or the ZWave JS integration

Is your problem within ZWaveJS2MQTT?

NO, my problem is NOT within ZWaveJS2MQTT

Checklist

I have checked the troubleshooting section and my problem is not described there.
I have read the changelog and my problem was not mentioned there.

Describe the bug

What causes the bug? Unclear

What do you observe? Unlocking the lock through the keypad does not trigger a keypad unlock notification event.

What did you expect to happen? A keypad unlock operation being logged under events.

Steps to reproduce the behavior:

Go to the Touchscreen Deadbolt Z-Wave Plus device in device list
Click on Events
Lock and unlock the device manually, lock and then unlock the device through the keypad
See that manual lock, manual unlock and keypad lock notifications are logged as events, but no keypad unlock event

Device information

Manufacturer: Allegion Model name: Touchscreen Deadbolt Z-Wave Plus BE469ZP Node ID in your network: 7

How are you using `node-zwave-js`?

zwavejs2mqtt Docker image (latest)
zwavejs2mqtt Docker image (dev)
zwavejs2mqtt Docker manually built (please specify branches)
ioBroker.zwave2 adapter (please specify version)
HomeAssistant zwave_js integration (please specify version)
pkg
node-red-contrib-zwave-js (please specify version, double click node to find out)
Manually built from GitHub (please specify branch)
Other (please describe)

Which branches or versions?

zwavejs2mqtt: 6.15.1 zwave-js: 9.6.2 home id: 4169456423 home hex: 0xf884db27

Did you change anything?

yes (please describe)

If yes, what did you change?

My lock used to emit this event. I recently updated the docker image. I am not sure if the breakage already occurred before the update or with the update. I only noticed it after the update.

Did this work before?

Yes (please describe)

If yes, where did it work?

See above.

Attach Driver Logfile

zwavejs_2022-08-04.log

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 32 (16 by maintainers)

Most upvoted comments

how come that association was missing?

Now that’s what you quoted before. The device doesn’t support Supervision for setting Associations. But the latest version should detect this and retry without supervision automatically now.

AlCalzone on Sep 6, 2022

Your current seems to be something else entirely, pretty likely https://github.com/zwave-js/node-zwave-js/issues/4918:

At some (early) point during the interview, the lock suddenly stops responding to queries. We get the list of securely supported CCs (so it understands the encrypted commands):

2022-09-06T00:40:08.844Z DRIVER » [Node 037] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      29
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 241
                                    └─[Security2CCCommandsSupportedGet]
2022-09-06T00:40:08.856Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-09-06T00:40:09.004Z DRIVER « [REQ] [SendData]
                                    callback id:            29
                                    transmit status:        OK, took 150 ms
                                    repeater node IDs:      18, 8
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -57 dBm
                                    ACK RSSI on repeaters:  N/A, N/A
                                    ACK channel no.:        1
                                    TX channel no.:         1
2022-09-06T00:40:09.105Z DRIVER « [Node 037] [REQ] [ApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 218
                                    └─[Security2CCCommandsSupportedReport]
                                        supportedCCs:
                                        · Anti-Theft
                                        · Association
                                        · Configuration
                                        · Battery
                                        · Door Lock
                                        · Notification
                                        · User Code
                                        · Schedule Entry Lock
                                        · Time
                                        · Supervision
                                        · Manufacturer Specific
                                        · Version
                                        · Firmware Update Meta Data
                                        · Application Status
                                        · Association Group Information
                                        · Device Reset Locally
                                        · Powerlevel
                                        · Indicator

but when trying to identify the lock itself next, it simply does not respond. It does ACK the command though:

2022-09-06T00:40:09.119Z DRIVER » [Node 037] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      30
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 242
                                    └─[ManufacturerSpecificCCGet]
2022-09-06T00:40:09.129Z DRIVER « [RES] [SendData]
                                    was sent: true
2022-09-06T00:40:09.276Z DRIVER « [REQ] [SendData]
                                    callback id:            30
                                    transmit status:        OK, took 150 ms
                                    repeater node IDs:      18, 8
                                    routing attempts:       1
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    ACK RSSI:               -57 dBm
                                    ACK RSSI on repeaters:  N/A, N/A
                                    ACK channel no.:        1
                                    TX channel no.:         1
2022-09-06T00:40:10.451Z CNTRLR   [Node 037] Timed out while waiting for a response from the node (ZW0201)

After that I don’t see a single response from the lock, despite it acknowledging every single command. You can try the workaround in the linked issue of upping the response timeout. Sadly this isn’t something we can work around with a device-specific compat flag, since the device isn’t even identified before the issue happens.

AlCalzone on Sep 6, 2022

Now that branch is merged on master so you can use master tag

robertsLando on Aug 31, 2022

What about tell him to try using test docker tag?

robertsLando on Aug 29, 2022

Not yet. v10 has additional logging to diagnose though.

AlCalzone on Aug 29, 2022

Just for reference, this is how it looks with my lock and the new logging:

10:17:39.471 SERIAL « 0x011c00a800011b139f035000df8f1f953ab94459cb8836255be1fb00d00b      (30 bytes)
10:17:39.473 SERIAL » [ACK]                                                                   (0x06)
10:17:39.476 CNTRLR   [Node 027] [~] [Door Lock] currentMode: 0 => 0                    [Endpoint 0]
10:17:39.478 CNTRLR   [Node 027] [~] [Door Lock] outsideHandlesCanOpenDoor: true,false, [Endpoint 0]
                      false,false => true,false,false,false
10:17:39.479 CNTRLR   [Node 027] [~] [Door Lock] insideHandlesCanOpenDoor: false,false, [Endpoint 0]
                      false,false => false,false,false,false
10:17:39.481 CNTRLR   [Node 027] [~] [Door Lock] doorStatus: "open" => "open"           [Endpoint 0]
10:17:39.482 CNTRLR   [Node 027] [~] [Door Lock] boltStatus: "unlocked" => "unlocked"   [Endpoint 0]
10:17:39.483 CNTRLR   [Node 027] [~] [Door Lock] latchStatus: "open" => "open"          [Endpoint 0]
10:17:39.484 DRIVER « [Node 027] [REQ] [BridgeApplicationCommand]
                      │ RSSI: -48 dBm
                      └─[Security2CCMessageEncapsulation]
                        │ sequence number: 80
                        └─[DoorLockCCOperationReport]
                            current mode:           Unsecured
                            active outside handles: true, false, false, false
                            active inside handles:  false, false, false, false
                            latch status:           open
                            bolt status:            unlocked
                            door status:            open
10:17:40.469 SERIAL « 0x011900a800011b109f035100354f80e44eb3a29623de8ef800d005            (27 bytes)
10:17:40.471 SERIAL » [ACK]                                                                   (0x06)
10:17:40.474 CNTRLR   [Node 027] compat mapping found, treating V1 Alarm frame as Notification Repor
                      t
10:17:40.474 CNTRLR   [Node 027] [~] [Notification] alarmType: 144 => 144               [Endpoint 0]
10:17:40.474 CNTRLR   [Node 027] [~] [Notification] alarmLevel: 1 => 1                  [Endpoint 0]
10:17:40.474 DRIVER « [Node 027] [REQ] [BridgeApplicationCommand]
                      │ RSSI: -48 dBm
                      └─[Security2CCMessageEncapsulation]
                        │ sequence number: 81
                        └─[NotificationCCReport]
                            V1 alarm type:       144
                            V1 alarm level:      1
                            notification type:   Access Control
                            notification status: undefined
                            notification event:  Keypad unlock operation
                            event parameters:
                              userId: 0x01
10:17:40.475 CNTRLR   [Node 027] [handleNotificationReport] notificationName: Access Control
10:17:40.475 CNTRLR   [Node 027] [handleNotificationReport] valueConfig:
                        label: Keypad unlock operation
                        type: event
10:17:40.476 CNTRLR   [Node 027] [~] [Door Lock] currentMode: 0 => 0                    [Endpoint 0]
10:17:40.476 CNTRLR   [Node 027] [Notification]
                        type:   Access Control
                        event:  Keypad unlock operation
                        userId: 1

AlCalzone on Aug 25, 2022

Do you mind pointing me to the code you are referring to?

Sure thing: Here’s the line that causes the door lock value change: https://github.com/zwave-js/node-zwave-js/blob/087d8b7759ae44296224c490f923c68d1dcc3ca9/packages/zwave-js/src/lib/node/Node.ts#L3028-L3029

This also means that the notification type is 0x06 and the notification event is one of 0x02, 0x04 or 0x06 (since the door lock status changes to unlocked).

This also means (unless your configuration files are completely messed up) that notificationConfig contains the parsed representation of https://github.com/zwave-js/node-zwave-js/blob/087d8b7759ae44296224c490f923c68d1dcc3ca9/packages/config/config/notifications.json#L383-L384 and that valueConfig contains the parsed representation of one of these events: https://github.com/zwave-js/node-zwave-js/blob/087d8b7759ae44296224c490f923c68d1dcc3ca9/packages/config/config/notifications.json#L555-L562 Which means the else branch must be taken here: https://github.com/zwave-js/node-zwave-js/blob/087d8b7759ae44296224c490f923c68d1dcc3ca9/packages/zwave-js/src/lib/node/Node.ts#L3036-L3045

I’m also going to add logging for notification events so this is no longer a guessing game: https://github.com/zwave-js/node-zwave-js/pull/4948

Unless we figure out whats going on, you can redo the tests as soon as HA has updated to node-zwave-js v10. Then we should know for sure if the driver emits an event or not.