GH-23: Feature door lock get all pin codes

[nkljajic]

Number of possible PIN codes can be up to 255 and probing all of them can last for up to 5 minutes.

Change

• Defer probing all possible PIN codes from join/interview phase for CC user code v1, and create dedicated GetAllPINCodes command for DoorLock Cluster, similar how configuration parameters V1 can be discovered at a later time on demand.
• Add missing UAM rules for Door Lock generated Notification events.

Checklist

• A Contribution License Agreement has been established between @SiliconLabs and author's company (matching email domain)

[nkljajic]

@rzr I had not implemented unit test for this new command. Another issue is that this also affects ZigPC.

[nkljajic]

Implementing Z-Wave specific commands, not available in Zigbee Cluster Library can be done by extending existing ZCL xml definitions or creating new ones. In DoorLock case I opted for the former, which was easier path.

[Thomasdjb]

Is there a reason behind this change ? I think CC UserCode V1 support multiple user ids.

[nkljajic]

As described above, we do not want to create all 255 User IDs during Interview phase and wait 5 minutes for it to complete.

[Thomasdjb]

This means we never create user ids for User Code v1 unless using GetAllPin command. This is not good for certification as this should be done automatically. To workaround we could update the user ids (triggering a User Number Get) when using User Code Set on a user id which is not registered. Either way, it has to be done somewhere.

[Thomasdjb]

Comma at the end typo ?

[nkljajic]

This file was generated by zap.

[nkljajic]

UnifySDK/components/uic_dotdot/zap/readme_ucl_mqtt_reference.md.zapt

Line 200 in 5ad3615

ucl/by-unid/<UNID>{{#unless (clusterWithoutEndpoints label)}}/<EP>{{/unless}}/{{asPublicationName label}}/SupportedGeneratedCommands { "value": [{{#zcl_commands}}{{#if (isEqual source "client")}}"{{label}}"{{listComma this}}{{/if}}{{/zcl_commands}}] }

[rzr]

it's acceptable to me, I would keep the generated file this has to be fixed in zap :)

not a big deal anyway

[rzr]

@rzr I had not implemented unit test for this new command. Another issue is that this also affects ZigPC.

Thanks for sharing this info, maybe I should enable zigbee support in CI , if you think it's not read to be merged you can set this PR as draft, as suggested at:

#18

your feedback is valuable

[rzr]

Please rebase branch to enable tests :

a3fa1c8

[Thomasdjb]

Hi Nenad,
Regarding your issue with the inclusion of 255 UserIDs device.
Unfortunately, the interview process for command class User Code is specified by the AWG specification (CL:0063.01.21.01.2).
For nodes supporting the v1 of UserCode command class, the controller must ask for the PIN code with an User Code Get for each User Identifier.
Bypassing this process will cause certification to fail.
On my setup interviewing a node with ~150 UserID takes less than 30 seconds. Maybe there is another problem with your setup ?

[nkljajic]

@Thomasdjb you are right, as per
Z-Wave Command Class Control Specification
CL:0063.01.21.02.1
We must ask for all pin codes during Interview stage.

However, per CL:0000.00.13.04.1 and CL:0000.00.21.02.1 we can do it later (before sending first command), and not automatically right after joining stage?
CL:0000.00.13.04.1

If a Command Class is partially controlled, the controlling node MAY skip steps or perform them in a
different order for the mandatory node interview detailed in this document.

CL:0000.00.21.02.1

This interview MUST be performed prior to issuing any control command to the supporting node.
Preferably, it should be done during the commissioning phase of the supporting node or shortly after
the inclusion of the controlling node

My emphasis is on "shortly after the inclusion"
My proposal is to delay, not skip, get all pin codes step. Perhaps device should step into "Online non-functional" after joining?

Legacy Z-Wave S0 Door Locks are slow, S2 do not have that issue.
Problem is elevated when we want to add several locks at once, and all of them start sending all possible pin codes at the same time.

[rzr]

Please rebase on

https://github.com/SiliconLabs/UnifySDK/releases/tag/ver_1.5.0

feedback welcome

[Thomasdjb]

@Thomasdjb you are right, as per Z-Wave Command Class Control Specification CL:0063.01.21.02.1 We must ask for all pin codes during Interview stage.

However, per CL:0000.00.13.04.1 and CL:0000.00.21.02.1 we can do it later (before sending first command), and not automatically right after joining stage? CL:0000.00.13.04.1

If a Command Class is partially controlled, the controlling node MAY skip steps or perform them in a
different order for the mandatory node interview detailed in this document.

CL:0000.00.21.02.1

This interview MUST be performed prior to issuing any control command to the supporting node.
Preferably, it should be done during the commissioning phase of the supporting node or shortly after
the inclusion of the controlling node

My emphasis is on "shortly after the inclusion" My proposal is to delay, not skip, get all pin codes step. Perhaps device should step into "Online non-functional" after joining?

Legacy Z-Wave S0 Door Locks are slow, S2 do not have that issue. Problem is elevated when we want to add several locks at once, and all of them start sending all possible pin codes at the same time.

I can provide a patch to delay the probing of user code with timer but it is too device specific to be added into the UnifySDK.
My advice would be to propose a change in the specification to clear up the inclusion delay. Then we can work on integrating a solution into the Unify SDK.

[rzr]

Please rebase this PR if you want to move this change forward or close