ISSUE: keymaster_lock_state_changed doesn’t fire for Z-Wave operation

[jclarke0000]

Describe the bug I have automations configured for to run when the keymaster_lock_state_changed event fires. Since the latest zwave_js update, this event only fires for direct operation of the lock, either keypad PIN entry or manually turning the deadbolt lever. The event does not fire if the lock is operated via a Z-Wave command.

Environment (please complete the following information):

• OS: HassOS
• Type of system that HA is running on: Odroid N2+
• Home Assistant version: 2021.11.5
• Hassio/Docker/Core? Core
• Component version: 0.0.77
• Z-Wave integration name: zwave_js
• Lock make and model: Schlage Connect BE469ZP, Yale ProSL YRD156

Logs Nothing appears in the keymaster debug log when locking / unlocking over Z-Wave

Screenshots If applicable, add screenshots to help explain your problem.

Additional context This started happening after the most recent zwave_js update. Info as follows: Driver Version: 8.8.3 Server Version: 1.12.0

Prior to this update this event would fire when the lock was operated via Z-Wave. The action_text field of the event read something like “RF unlock operation.”

[firstof9]

RF lock/unlock events should fire as well, sounds like an upstream problem.

[raman325]

can you check the logs of the addon? When you do any lock/unlock operation, you should see a value notification log entry for each operation. If you see it for manual operation (you should since you are seeing the keymaster event) and don't for HA operation (you shouldn't since you are NOT seeing the keymaster event), that points to a driver problem as @firstof9 is suggesting

[jclarke0000]

OK I think I see the difference you are describing. When I manually unlock the door, I see this in the log:

2021-12-09T00:03:59.972Z DRIVER « [Node 002] [REQ] [BridgeApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 145
                                    └─[SupervisionCCGet]
                                      │ session id:      27
                                      │ request updates: false
                                      └─[NotificationCCReport]
                                          notification type:   Access Control
                                          notification status: 255
                                          notification event:  Manual unlock operation

When I use HA to operate the lock, that same section looks like this:

2021-12-09T00:06:00.497Z DRIVER « [Node 002] [REQ] [BridgeApplicationCommand]
                                  └─[Security2CCMessageEncapsulation]
                                    │ sequence number: 148
                                    └─[SupervisionCCGet]
                                      │ session id:      30
                                      │ request updates: false
                                      └─[NotificationCCReport]
                                          V1 alarm type:  24
                                          V1 alarm level: 1

This is from the Z-Wave JS log

[firstof9]

Both locks or just one?

[raman325]

I think this may be a config issue. The alarm level and type have to be mapped in the config file for the value notification to fire (I think)

[jclarke0000]

Both locks or just one?

The logs above are from operating just the Schlage lock. But I have the problem with both locks.

I think this may be a config issue. The alarm level and type have to be mapped in the config file for the value notification to fire (I think)

I thought this wasn't necessary/possible when using Z-Wave JS. My config, as per the installation instructions uses sensor.fake for both Alarm Level and Alarm Type. I was following the troubleshooting steps here that say it's fine to use sensor.fake: https://github.com/FutureTense/keymaster/wiki/Troubleshooting

In any case, I can't choose anything other than sensor.fake in the config.

[firstof9]

zwavejs is supposed to take the alarm levels and convert them to events, that's where the problem is.