[feat] Alarms mapping compat flag for locks (and more?)

[lolouk44]

Is your feature request related to a problem? Please describe. Home Assistant User. I used to get extra information about the door lock (Yale Conexis L1) such as Locked by RF, Jammed, etc. I can't see this info present in the logs, but I see the "id": "5-113-0-alarmType" block holds a value that would represent the lock state (found for Yale Conexis L1 so far): 9: Lock is jammed 21: Locked manually 22: Unlocked manually 24: Locked by zwave 25: Unlocked by zwave 27: Auto relock 144: Unlocked by RFID tag

Describe the solution you'd like I haven't found an exhaustive list anywhere yet, ideally have that list exposed to HA, if not at least expose the values so a custom sensor can be created

Describe alternatives you've considered none yet

Additional context Some info here: https://community.smartthings.com/t/yale-real-living-keyless-deadbolt-displays-incorrect-status/2300/4

[TheFuzz4]

I can also confirm with my Yale YRD256 that the alarm type and alarm level are not reporting any values as of yet.

[robertsLando]

@AlCalzone something on your side?

[AlCalzone]

Alarm (notification CC V1) Type and Level are not standardized, so every manufacturer does his own interpretation. I'm not going to bother with that since V2+ notifications are standardized.

[AlCalzone]

If anyone feels like implementing configurable alarm labels as a compat flag, feel free to provide a PR.

[lolouk44]

Thanks @AlCalzone You mention V1 Vs V2 notifications. Should I understand from this that there will soon be a new notification displayed in zwave JS? Will this standardised info be passed on to Home Assistant? Can you provide more info on this? I'm not good enough to provide a PR but I'm more than happy to help with testing if that's of interest

[AlCalzone]

The Notification CC (former Alarm CC) defines which values mean what. This information is passed on to applications.

Unfortunately, that was only added in version 2 of the CC and extended upon later. The first version (which your device uses) was not standardized in that regard, so 21 could mean "Locked manually" for your device, but "Flood Alarm" for another one. So a definition of these values would have to be done on a per-device basis and I frankly don't have the motivation nor the capacity to go through thousands of device configs and compare the manuals. Especially since it only affects legacy devices.

[lolouk44]

Thanks for this info. Is there a way to at least expose these values to Home Assistant? I'm happy creating my own template sensors, but I at least need the values coming into home assistant, ideallly as an attribute. Thanks

[AlCalzone]

They should... originally reported in https://github.com/zwave-js/node-zwave-js/issues/1546, fixed in https://github.com/zwave-js/node-zwave-js/pull/1562

[lolouk44]

Just realised I had 2 entitites that were set to unavailable by default and therefore did not show a state. I have enabled them and I have created my template sensor. Thanks a lot 👍 For other Yale Connexis L1 users this is my template sensor: https://github.com/lolouk44/homeassistant/blob/master/sensors/Yale.yaml I'm sure there are plenty other statuses, but these are the ones I've so far discovered / the ones in use in my environment

@AlCalzone Thanks for your helpFeel free to close this thread if you wish.

[blhoward2]

We’re going to hijack and use this issue to collect information for a potential compat flag mapping certain alarm values to notification values, primarily to trigger lock state changes on older locks when manually locked.

[Rocketman69]

Posting this Table per blhoward2's request. Hopefully it will be of help. I've tested this on all of my current Kwikset 914 locks, an older 912 and my old 910. I've been told that there was a change made to the 914 at some point during its production life cycle, so there's apparently a cutoff point for this model that switched to the newer command classes. I'm not sure if the model 916 or 918 were produced from the start with the newer configuration, or if they also used these alarm_type values prior to some point in time. Kwikset Alarm Event Classification.xlsx

[lolouk44]

@Rocketman69 If you want you can add these rows (at least for the Yale Conexis L1)

Alarm Type	Alarm Level	Notification Event
16	001	Lock Un-Secured by User via Mobile App
144	User-ID#	Lock Un-Secured by User (RFID Fob Number)

[Rocketman69]

@Rocketman69 If you want you can add these rows (at least for the Yale Conexis L1)

Alarm Type Alarm Level Notification Event 16 001 Lock Un-Secured by User via Mobile App 144 User-ID# Lock Un-Secured by User (RFID Fob Number)

Pretty sure yale is different across the board..... Standby for another attachment.

[Rocketman69]

Here's a little something I found from Yale: YaleRealLivingAssureSL_Z-WavePlus_SystemIntegratorsGuide.pdf

[blhoward2]

@lolouk44 Can you confirm that your Yale suffers from the same alarm-only deficiency, and that it matches up to this manual? This manual is from a newer device that supports the notifications class so it would update the state after the latest update.

I want to be sure it hasn't changed in newer locks, so if you or someone else can confirm that has a lock to test it on.

Edit: Actually, this may be wrong. It’s confusing because they renamed the command class but I believe this may be an old device given all are 0x006.

[lolouk44]

Here's a little something I found from Yale: YaleRealLivingAssureSL_Z-WavePlus_SystemIntegratorsGuide.pdf

Thanks. This applies to a different Yale lock, so it looks like even though it they're both Yale / Assa Abloy, they have different alarms 😞

[lolouk44]

@blhoward2 my Yale (Conexis L1) does not matcht he pdf send, as per above comment. What do you mean by "alarm-only deficiency"? If you're referring to the fact that you're only getting an AlarmType and and AlarmLevel and not the full detailed lock status, then yes. Check above for how I recreated the detailed status. It's not fully encompassing, but covers my use. Feel free to use and amend to your needs

[blhoward2]

That's not what this is about. Some locks do not update their state when manually unlocked or locked because they use alarm messages and not notifications. That's what we're focusing on at the moment. We hijacked your issue because it's related.

[lolouk44]

ah sorry, then no this does not apply to my lock.

[raz0rf0x]

Kwikset 900 series info. Can be used to automatically identify legacy locks that need extra configuration

http://z-wave-assets.s3-us-west-2.amazonaws.com/docs/175/B00Q3N4NT2_Kwikset_SmartCode_916_Z-Wave_Configuration.pdf?1490361692

Serial interfacing guide with additional information regarding commands.

http://s7d5.scene7.com/is/content/BDHHI/ApplicationNote-UsingASCII-Z-Wave-Locks

Similar to above but expanded and includes Yale info.

https://homecontrolassistant.com/download/Doc/TechNotes/TechNote_304_ZWaveLocks.pdf

[blhoward2]

No worries. We hijacked your issue after all. If we can narrow this to a small number of different sets of lists then it makes implementing what you wanted easier. So it is related.

[blhoward2]

Kwikset 900 series info. Can be used to automatically identify legacy locks that need extra configuration

http://z-wave-assets.s3-us-west-2.amazonaws.com/docs/175/B00Q3N4NT2_Kwikset_SmartCode_916_Z-Wave_Configuration.pdf?1490361692

Not really. Those parameters exist across all of them. If you mean 35 we can already identify the model but knowing which model uses which list is a different question.

[TheFuzz4]

@blhoward2 and @Rocketman69 I have the YRD256 so I can assist you with validating this. I can confirm that right now I do see the 2 sensors report in HA but they show up with unknown for the value. We can use these 2 sensors in combo to determine different states of the lock as well. If you need me to help test let me know how I can

[blhoward2]

@blhoward2 and @Rocketman69 I have the YRD256 so I can assist you with validating this. I can confirm that right now I do see the 2 sensors report in HA but they show up with unknown for the value. We can use these 2 sensors in combo to determine different states of the lock as well. If you need me to help test let me know how I can

Are you on the most recent version of the addon or zwave2jsmqtt? There was a bug fix applied to the sensors.

[TheFuzz4]

So I'm using zwavejs2mqtt in docker with the tag of latest. As of right now its running version 1.1.1 If there is a more appropriate tag you want me to apply I will gladly do so .

[blhoward2]

So I'm using zwavejs2mqtt in docker with the tag of latest. As of right now its running version 1.1.1 If there is a more appropriate tag you want me to apply I will gladly do so .

Yes, try the dev tag image. I'm not sure if the change is in latest yet. I just don't want to confuse a fixed issue with something else.

[TheFuzz4]

If I do the dev tag it actually takes me back a version.

[blhoward2]

If I do the dev tag it actually takes me back a version.

That shouldn't be possible. Dev is built every night. Latest is from 24 hours ago. Dev is from 15 hours ago. Latest is fairly up to date in this case due to a recent release but it isn't always.

What version are you seeing in both? If it something is wrong.

[TheFuzz4]

Ok so the latest shows me this

App Version
1.1.1
Zwavejs Version
6.2.0

Now switching over to the dev tag for zwavejs2mqtt

and I can confirm that I see the same version there now as well. Waiting for it to go through and discover all of my devices. Had a bunch show up as missing all of their details so doing interviews and things.

[TheFuzz4]

Ok so had my kid test this to see if anything would show up in here while I had him manipulate the lock and nothing showed up. The main thing I'm wanting to catch is when someone punches in the wrong code multiple times so I can be notified about it. Not sure if its because the network hasn't full settled down from the restart yet but I'll try it again in a few.

[AlCalzone]

@TheFuzz4 can you make a zwave-js log when you manipulate the lock?

[TheFuzz4]

Ok so this is me doing a manual unlock of the door, manually locking it and then using a code to unlock it, closing the door and my automation kicks in and locks the door. I did this twice

2021-02-12 18:20:56.125 INFO ZWAVE: Node 137: interview completed, all values are updated
2021-02-12 18:21:47.742 INFO ZWAVE: Node 137: value updated: 98-0-currentMode 255 => 0
2021-02-12 18:21:47.743 INFO ZWAVE: Node 137: notification: Keypad unlock operation with [object Object]
2021-02-12 18:21:52.310 INFO ZWAVE: Node 137: notification: RF lock operation
2021-02-12 18:21:54.973 INFO ZWAVE: Node 137: value updated: 98-0-currentMode 0 => 255
2021-02-12 18:21:54.975 INFO ZWAVE: Node 137: value updated: 98-0-outsideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-02-12 18:21:54.976 INFO ZWAVE: Node 137: value updated: 98-0-insideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-02-12 18:21:54.977 INFO ZWAVE: Node 137: value updated: 98-0-latchStatus open => open
2021-02-12 18:21:54.979 INFO ZWAVE: Node 137: value updated: 98-0-boltStatus unlocked => locked
2021-02-12 18:21:54.980 INFO ZWAVE: Node 137: value updated: 98-0-doorStatus open => open
2021-02-12 18:23:07.805 INFO ZWAVE: Node 137: value updated: 98-0-currentMode 255 => 0
2021-02-12 18:23:07.806 INFO ZWAVE: Node 137: notification: Manual unlock operation
2021-02-12 18:23:18.059 INFO ZWAVE: Node 137: value updated: 98-0-currentMode 0 => 0
2021-02-12 18:23:18.059 INFO ZWAVE: Node 137: notification: Keypad unlock operation with [object Object]
2021-02-12 18:23:21.693 INFO ZWAVE: Node 137: notification: RF lock operation
2021-02-12 18:23:24.336 INFO ZWAVE: Node 137: value updated: 98-0-currentMode 0 => 255
2021-02-12 18:23:24.337 INFO ZWAVE: Node 137: value updated: 98-0-outsideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-02-12 18:23:24.337 INFO ZWAVE: Node 137: value updated: 98-0-insideHandlesCanOpenDoor false,false,false,false => false,false,false,false
2021-02-12 18:23:24.338 INFO ZWAVE: Node 137: value updated: 98-0-latchStatus open => open
2021-02-12 18:23:24.338 INFO ZWAVE: Node 137: value updated: 98-0-boltStatus locked => locked
2021-02-12 18:23:24.339 INFO ZWAVE: Node 137: value updated: 98-0-doorStatus open => open

Let me know what steps you'd like me to take next. Thank you for your help with this and I hope that this helps others as well.

[AlCalzone]

I meant the zwave-js log, not zwavejs2mqtt :( The one that starts with

███████╗ ██╗    ██╗  █████╗  ██╗   ██╗ ███████╗             ██╗ ███████╗
╚══███╔╝ ██║    ██║ ██╔══██╗ ██║   ██║ ██╔════╝             ██║ ██╔════╝
  ███╔╝  ██║ █╗ ██║ ███████║ ██║   ██║ █████╗   █████╗      ██║ ███████╗
 ███╔╝   ██║███╗██║ ██╔══██║ ╚██╗ ██╔╝ ██╔══╝   ╚════╝ ██   ██║ ╚════██║
███████╗ ╚███╔███╔╝ ██║  ██║  ╚████╔╝  ███████╗        ╚█████╔╝ ███████║
╚══════╝  ╚══╝╚══╝  ╚═╝  ╚═╝   ╚═══╝   ╚══════╝         ╚════╝  ╚══════╝

[AlCalzone]

Regarding the other comments and the proposed feature: It looks like we need to be able to map alarmType & alarmLevel to notificationType, notificationEvent and eventParameters.

[w0hey]

Here is a chunk of zwavejs logfile taken from manually locking/unlocking a SmartCode 910 deadbolt:

16:58:42.153 SERIAL » [ACK]                                                                   (0x06)
16:58:42.156 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
16:58:42.175 SERIAL » 0x011100131d0a988021bb63af6492c0690555ab                            (19 bytes)
16:58:42.176 DRIVER » [Node 029] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      85
                      └─[SecurityCCNonceReport]
                          nonce: 0x21bb63af6492c069
16:58:42.180 SERIAL « [ACK]                                                                   (0x06)
16:58:42.186 SERIAL « 0x0104011301e8                                                       (6 bytes)
16:58:42.188 SERIAL » [ACK]                                                                   (0x06)
16:58:42.190 DRIVER « [RES] [SendData]
                        was sent: true
16:58:42.202 SERIAL « 0x010500135500bc                                                     (7 bytes)
16:58:42.203 SERIAL » [ACK]                                                                   (0x06)
16:58:42.205 DRIVER « [REQ] [SendData]
                        callback id:     85
                        transmit status: OK
16:58:42.226 SERIAL « 0x011e0004001d189881f53a1e87b351583b87d24964e7212808fb686c42f4fa03  (32 bytes)
16:58:42.228 SERIAL » [ACK]                                                                   (0x06)
16:58:42.231 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[NotificationCCReport]
                            V1 alarm type:  22
                            V1 alarm level: 1
16:58:42.236 CNTRLR   [Node 029] [~] [Notification] notificationMode: "unkno [Endpoint 0] [internal]
                      wn" => "unknown"
16:58:42.238 CNTRLR   [Node 029] [~] [Notification] alarmType: 22 => 22                 [Endpoint 0]
16:58:42.246 CNTRLR   [Node 029] [~] [Notification] alarmLevel: 1 => 1                  [Endpoint 0]
16:58:42.255 SERIAL « 0x01080004001d02984034                                              (10 bytes)
16:58:42.257 SERIAL » [ACK]                                                                   (0x06)
16:58:42.264 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
16:58:42.287 SERIAL » 0x011100131d0a98809fb73408ed0d62a2055695                            (19 bytes)
16:58:42.289 DRIVER » [Node 029] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      86
                      └─[SecurityCCNonceReport]
                          nonce: 0x9fb73408ed0d62a2
16:58:42.295 SERIAL « [ACK]                                                                   (0x06)
16:58:42.302 SERIAL « 0x0104011301e8                                                       (6 bytes)
16:58:42.303 SERIAL » [ACK]                                                                   (0x06)
16:58:42.305 DRIVER « [RES] [SendData]
                        was sent: true
16:58:42.321 SERIAL « 0x010500135600bf                                                     (7 bytes)
16:58:42.323 SERIAL » [ACK]                                                                   (0x06)
16:58:42.326 DRIVER « [REQ] [SendData]
                        callback id:     86
                        transmit status: OK
16:58:42.340 SERIAL « 0x011e0004001d189881c1f058171e74ee162b7d3710d49fb21317d5c53336b03c  (32 bytes)
16:58:42.343 SERIAL » [ACK]                                                                   (0x06)
16:58:42.347 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[NotificationCCReport]
                            V1 alarm type:  21
                            V1 alarm level: 1
16:58:42.357 CNTRLR   [Node 029] [~] [Notification] notificationMode: "unkno [Endpoint 0] [internal]
                      wn" => "unknown"
16:58:42.359 CNTRLR   [Node 029] [~] [Notification] alarmType: 22 => 21                 [Endpoint 0]
16:58:42.363 CNTRLR   [Node 029] [~] [Notification] alarmLevel: 1 => 1                  [Endpoint 0]
16:58:47.062 SERIAL « 0x01080004001d02984034                                              (10 bytes)
16:58:47.065 SERIAL » [ACK]                                                                   (0x06)
16:58:47.068 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCNonceGet]
16:58:47.091 SERIAL » 0x011100131d0a9880c89614be57dbcb8c05579f                            (19 bytes)
16:58:47.093 DRIVER » [Node 029] [REQ] [SendData]
                      │ transmit options: 0x05
                      │ callback id:      87
                      └─[SecurityCCNonceReport]
                          nonce: 0xc89614be57dbcb8c
16:58:47.098 SERIAL « [ACK]                                                                   (0x06)
16:58:47.103 SERIAL « 0x0104011301e8                                                       (6 bytes)
16:58:47.105 SERIAL » [ACK]                                                                   (0x06)
16:58:47.107 DRIVER « [RES] [SendData]
                        was sent: true
16:58:47.119 SERIAL « 0x010500135700be                                                     (7 bytes)
16:58:47.120 SERIAL » [ACK]                                                                   (0x06)
16:58:47.122 DRIVER « [REQ] [SendData]
                        callback id:     87
                        transmit status: OK
16:58:47.144 SERIAL « 0x011e0004001d189881b39df312bffe932541177002d5c81b39b697da121e4d60  (32 bytes)
16:58:47.149 SERIAL » [ACK]                                                                   (0x06)
16:58:47.151 DRIVER « [Node 029] [REQ] [ApplicationCommand]
                      └─[SecurityCCCommandEncapsulation]
                        │ sequenced: false
                        └─[NotificationCCReport]
                            V1 alarm type:  22
                            V1 alarm level: 1
16:58:47.155 CNTRLR   [Node 029] [~] [Notification] notificationMode: "unkno [Endpoint 0] [internal]
                      wn" => "unknown"
16:58:47.156 CNTRLR   [Node 029] [~] [Notification] alarmType: 21 => 22                 [Endpoint 0]
16:58:47.161 CNTRLR   [Node 029] [~] [Notification] alarmLevel: 1 => 1                  [Endpoint 0]

[firstof9]

Here is a list of the alarm_type and their human readable meanings we've collected for the KeyMaster project.

        0: "No Status Reported",
        9: "Lock Jammed",
        17: "Keypad Lock Jammed",
        21: "Manual Lock",
        22: "Manual Unlock",
        23: "RF Lock Jammed",
        24: "RF Lock",
        25: "RF Unlock",
        26: "Auto Lock Jammed",
        27: "Auto Lock",
        32: "All Codes Deleted",
        161: "Bad Code Entered",
        167: "Battery Low",
        168: "Battery Critical",
        169: "Battery Too Low To Operate Lock",
        16: "Keypad Unlock",
        18: "Keypad Lock",
        19: "Keypad Unlock",
        162: "Lock Code Attempt Outside of Schedule",
        33: "Code Deleted",
        112: "Code Changed",
        113: "Duplicate Code",

The alarm_level has always been the user code slot that's activated the alarm_type, for my 910 it's always slot 1 unless unlocked via keypad externally, all other events trigger alarm_level 1

I hope this is useful in some way.

[scyto]

for a Kwikset 910 Device ID: 144-1-1 (0x0090-0x0001-0x0001)

i observe the following alarm type (matches the list firstof9 had above)

18 when locked using the keypad on outside of the door
19 when unlocked using the keypad on outside of door
21 when locked using the deadbolt on the inside of the door
22 when unlocked using the deadbolt on the inside of the door

3-134-0-libraryType] Library type 6 [3-134-0-protocolVersion] Z-Wave protocol version 3.52 [3-134-0-firmwareVersions] Z-Wave chip firmware versions 3.33

[AlCalzone]

@scyto Is that alarm level or alarm type? what does the other value contain?

[firstof9]

For these non-zwave plus locks the 'alarm level' is the code slot # that was used.

In the case of the 910 anything manually done on the lock, example: physically unlocking from the inside, will give you alarm level 1.

[scyto]

@scyto Is that alarm level or alarm type? what does the other value contain? alarm type

[AlCalzone]

I've compiled the following table how the alarms could be translated. ✓ means the alarm can be translated ✘ means there is no direct equivalent in Notification CC ? means we need additional input.

KeyMaster We need to know which mapping applies to which device - I'm not going to apply a blanket mapping which might be wrong for some devices.

	V1 Alarm (type / level)	Description	V2+ Notification (type / event)	Event parameters
✓	0 / any	No Status Reported	Access Control (0x06) / idle (0x00)	-
✓	9 / any	Lock Jammed	Access Control (0x06) / Lock state: Lock Jammed (0x0b)	-
✓	16 / any	Keypad Unlock	Access Control (0x06) / Keypad unlock operation (0x06)	userId = alarmLevel
✘	17 / any	Keypad Lock Jammed	Same as Lock jammed???
✓	18 / any	Keypad Lock	Access Control (0x06) / Keypad lock operation (0x05)	userId = alarmLevel
✓	19 / any	Keypad Unlock	Access Control (0x06) / Keypad unlock operation (0x06)	userId = alarmLevel
✓	21 / any	Manual Lock	Access Control (0x06) / Manual lock operation (0x01)	-
✓	22 / any	Manual Unlock	Access Control (0x06) / Manual unlock operation (0x02)	-
✓	23 / any	RF Lock Jammed	Access Control (0x06) / RF not fully locked (0x08)	-
✓	24 / any	RF Lock	Access Control (0x06) / RF lock operation (0x03)	-
✓	25 / any	RF Unlock	Access Control (0x06) / RF unlock operation (0x04)	-
✓	26 / any	Auto Lock Jammed	Access Control (0x06) / Auto lock not fully locked (0x0A)	-
✓	27 / any	Auto Lock	Access Control (0x06) / Auto lock locked (0x09)	-
✓	32 / any	All Codes Deleted	Access Control (0x06) / All user codes deleted (0x0c)	-
✓	33 / any	Code Deleted	Access Control (0x06) / Single user code deleted (0x0d)	alarmLevel = userId
✘	112 / ??	Code Changed	?	??
✘	113 / any	Duplicate Code	Access Control (0x06) / New user code not added due to duplicate code (0x0f)	alarmLevel = existing userId?
?	161 / any	Bad Code Entered	Access Control (0x06) / Unlock by RF with invalid user code (0x14) OR Locked by RF with invalid user code (0x15)	??
?	167 / any	Battery Low	Access Control (0x06) / Barrier sensor low battery warning (0x4a)	-
✘	168 / any	Battery Critical	??
✘	169 / any	Battery Too Low To Operate Lock	??
✘	162 / any	Lock Code Attempt Outside of Schedule	??

Yale Conexis L1

	V1 Alarm (type / level)	Description	V2+ Notification (type / event)	Event parameters
✓	0 / any	No Status Reported	Access Control (0x06) / idle (0x00)	-
✘	16 / 1	Unlock through mobile App	RF Unlock??	-
?	144 / 1	Unlock through RFID	Access Control (0x06) / Keypad unlock operation (0x06)	userId = alarmLevel

[lolouk44]

	V1 Alarm (type / level)	Description	V2+ Notification (type / event)	Event parameters	Comments
✓	0 / any	No Status Reported	Access Control (0x06) / idle (0x00)	-	-
✘	16 / any	Unlock through mobile App	RF Unlock??	-	no zwave required to unlock, this uses built in Bluetooth to unlock. Only one phone/app can be registered to unlock, so I suspect alarmLevel is always 1
?	144 / any	Unlock through RFID	Access Control (0x06) / Keypad unlock operation (0x06)	userId = alarmLevel	no zwave required to unlock, this uses an RFID keyfob or RFID card to unlock

[AlCalzone]

@lolouk44 I understand these are the alarms the lock sends us when the App/RFID unlock happens. We don't have any standardized notification to translate these alarms to though, so they likely need to stay exposed as alarmType/Level or misuse a different notification.

[firstof9]

@AlCalzone

112 / any

the alarmLevel returns the slot # that was changed.

I don't think there's a v2+ equivalent.

[AlCalzone]

I don't think there's a v2+ equivalent.

Then we cannot translate that

[scyto]

For

✘	17 / any	Keypad Lock Jammed	Same as Lock jammed???

As you say, could be functionally equivalent to value of 'unknown' on 'currentMode` (aka x-98-0) as per SDS1378

It could also be translated to:

12	0x0B	Event	0B=Lock Jammed

(from https://www.silabs.com/community/wireless/z-wave/knowledge-base.entry.html/2020/10/30/best_practices_forz-wavedoorlocks-O6YR) that doc also states The lock should also send a Door Lock Operation Report with a value of 0xFE (Door Mode Unknown) if the bolt is not in either the Locked or Unlocked mode.

I have a BE469ZP arriving to day i can bench test (which causes unknown - will see if it raises a 0B event too)

IMO mapping to unknown for lock mode for anything where the lock is implying it doesn't know if it is locked or not is a viable approach.

[AlCalzone]

To clarify - what I'm going to do is to translate these V1 alarms to V2+ notifications if possible. These standardized notifications can then be used to update the lock status etc.

BE469ZP is using Notification CC V8 according to http://manuals-backend.z-wave.info/make.php?lang=en&sku=BE469ZP&cert=ZC10-18106281 so it shouldn't be relevant to this particular issue.

---

--	--	--	--	--
✘	168 / any	Battery Critical	??
✘	169 / any	Battery Too Low To Operate Lock	??

could be mapped to a Battery report with "low level" - but I fear I'm going down a rabbit hole with this. I think we should focus on supporting the necessary minimum here, i.e. lock status.

[scyto]

BE469ZP is using Notification CC V8 according to http://manuals-backend.z-wave.info/make.php?lang=en&sku=BE469ZP&cert=ZC10-18106281 so it shouldn't be relevant to this particular issue.

I should have been clearer, i was only using it validate that when that v2 notification occurs; aka is it the same a 'unknown' on the old lock status value (secure / insecure / unknown / etc) as i can compare what it reports for v2. but maybe that isn't useful.

[cppsse]

I don't remember where I found this but hopefully it helps answer some questions.

[firstof9]

My Kwikset 910 follows the table above.