Fix empty event parameters in notification after user code reset on Kadaas locks

[jfcloutier]

After a user code reset, the Kaadas KA210; Alloy deadbolt (KA210.ah-nck) emits an :access_control notification
with z-wave event :new_user_code_not_added_duplicate and an encoded, but ignored, user_code_report as event parameters

SRH-1835

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (1)

• lib/grizzly/zwave/notifications.ex: Language not supported

[jfcloutier]

The Kaadas is sending the wrong notification post user code reset. It contradicts their documentation. See page 10 of https://drive.google.com/file/d/1i4ukEexzVfJvySYdRCaSMG83l3yh-Qkl/view

[jjcarstens]

I don't think it contradicts the docs? I interpret this line as "All notifications in table 4-8-1 are type Access Control" and that table is page 10. It looks like some of them could be different parameters for the same event based on the Alarm Level?

[jfcloutier]

I don't think it contradicts the docs? I interpret this line as "All notifications in table 4-8-1 are type Access Control" and that table is page 10. It looks like some of them could be different parameters for the same event based on the Alarm Level?

Yes. The notification sent by the Kaadas after resetting a user code is not malformed but it is not the expected one.

On resetting a user code 5

Yale lock sends notification:

type: 0x21
level: 0x05 <---- slot_id
zwave_type: access_control (0x06)
zwave_event: single_user_code_deleted (0x0D)
event_parameters: []

Kaadas lock sends notification:

type: 0x71
level: 0x3E
zwave_type: access_control (0x06)
zwave_event: user_code_not_added_duplicate (0x0F) <---- unexpected, expecting single_user_code_deleted (0x0D)
event_parameters: UserCodeReport with params: <---- Not currently decoded - the PR fixes this
user_code:"....",
user_id: 0x05 , <---- slot_id
user_id_status :available

So the Yale locks tell us which slot_id was reset via the notification's level, whereas the Kaadas lock tells us which slot_id was reset by embedding a User Code Report in the event parameters, which is fine. Unfortunately, it gives the wrong zwave_event.

So we have two problems: The Kaadas cites the wrong zwave event, thus confusing CMW, and Grizzly ignores the User Code Report embedded in the event parameters of the notification because it does not cover the case.

[jfcloutier]

As we see here, two different locks will use different strategies for encoding notification data. Yale uses level for the slot id and has empty event parameters, whereas Kaadas uses an encoded UserCodeReport as event parameters to communicate the slot id. Both are perfectly "legal" and at the device's discretion.

How do we make Grizzly.ZWave.Notifications agnostic re. event parameter encoding/decoding?