Feature/support keypair generation

[HunsupJung]

Type of Change

• WWST Certification Request
  • If this is your first time contributing code:
    • I have reviewed the README.md file
    • I have reviewed the CODE_OF_CONDUCT.md file
    • I have signed the CLA
  • I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com
• Bug fix
• New feature
• Refactor

Checklist

• I have performed a self-review of my code
• I have commented my code in hard-to-understand areas
• I have verified my changes by testing with a device or have communicated a plan for testing
• I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change

• https://smartthings.atlassian.net/browse/REQ-23925
• https://smartthings.atlassian.net/wiki/spaces/STHK/pages/4707090966/Support+Keypair+generation

Summary of Completed Tests

[github-actions]

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/adMKXL5K4J29

[github-actions]

Test Results

   72 files    490 suites   0s ⏱️
2 686 tests 2 686 ✅ 0 💤 0 ❌
4 535 runs  4 535 ✅ 0 💤 0 ❌

Results for commit aed6caa.

♻️ This comment has been updated with latest results.

[HunsupJung]

@tpmanley
I entered the Git command incorrectly and the PR was closed, but I couldn't open it again to see if I didn't have the authority, so I made a new one. I'm sorry to bother you.

[github-actions]

File	Coverage
All files	80%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/can_handle.lua	90%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua	76%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/init.lua	92%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lock_utils.lua	98%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lazy_load_subdriver.lua	57%	❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against aed6caa

[HunsupJung]

@tpmanley

Thanks for the making the requested changes @HunsupJung . The driver code is looking pretty good to me now. In addition to what @ctowns suggested, can you also take a look at the unit tests failures reported by CI and try to add tests for the new code?

First of all, I corrected all the errors.

[HunsupJung]

@ctowns
if test code uses lock-modular, the following message appears as if lockAliro capability is not supported, making it impossible to write test code. What do you suggest I do?

INFO  || <MatterDevice: 00000000-1111-2222-3333-000000000001 [nil]> received InteractionResponse: <InteractionResponse || type: REPORT_DATA, response_blocks: [<InteractionResponseInfoBlock || status: SUCCESS, <InteractionInfoBlock || endpoint: 0x01, cluster: DoorLock, attribute: AliroReaderVerificationKey, data: OctetString1: "\x04\xA9\xCB\xE4\x18\xEB\x09\x66\x16\x43\xE2\xA4\xA8\x46\xB8\xED\xFE\x27\x86\x98\x30\x2E\x9F\xB4\x3E\x9B\xFF\xD3\xE3\x10\xCC\x2C\x2C\x7F\xF4\x02\xE0\x6E\x40\xEA\x3C\xE1\x29\x43\x52\x73\x36\x68\x3F\xC5\xB1\xCB\x0C\x6A\x7C\x3F\x0B\x5A\xFF\x78\x35\xDF\x21\xC6\x24">>]>
TRACE || Found MatterMessageDispatcher handler in matter-lock -> New Matter Lock Handler
WARN  || Attempted to generate event for 00000000-1111-2222-3333-000000000001.main but it does not support capability Lock Aliro

[hcarter-775]

@HunsupJung when you're setting up the test, you can make a mock device with the following profile
profile = t_utils.get_profile_definition("lock-modular.yml", {enabled_optional_capabilities = {{"main", {"lockAliro"}}}}),

Then run the test as normal. This will make the tested profile include the optional capability. You can add as many optional capabilities as you want in this way.

[nickolas-deboom]

It might be worth checking the response of SetAliroReaderConfig before setting ALIRO_READER_CONFIG_UPDATED to true, since if the command fails then set_reader_config would never retry.

[HunsupJung]

There is no way to whether the ReaderConfig is set well in SetAliroReaderConfig command and response. So, I will move it to aliro_reader_verification_key_handler which is one of the ReaderConfig.

[nickolas-deboom]

I might be missing something but what is the reason for the early return here? It seems to me that this would result in a no-op for any subsequent setReaderConfig commands since ALIRO_READER_CONFIG_UPDATED is never cleared

[HunsupJung]

The ReaderConfig value needs to be set only once.
Originally, it was input through the setReaderConfig command from ST Cloud (Chamber), but it was not possible to input in a specific situation, so we decided to input it from the hub.
In consideration of future failures, the handler for the command was left, and the ALIRO_READER_CONFIG_UPDATED field was placed so that duplicate input was not possible.

[tpmanley]

generate_keypair can return nil, nil when it's unable to generate a keypair so that should be handled here

[tpmanley]

As far as I know there are no devices with the DoorLock cluster on more than one endpoint, but even so it'd be better to only update the endpoint that reported the feature map attribute instead of the first endpoint with the DoorLock cluster.