Move lockAlarm configuration to do_configure

[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

Summary of Completed Tests

[github-actions]

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

[github-actions]

Test Results

   72 files    489 suites   0s ⏱️
2 675 tests 2 675 ✅ 0 💤 0 ❌
4 523 runs  4 523 ✅ 0 💤 0 ❌

Results for commit 3706fb2.

♻️ This comment has been updated with latest results.

[github-actions]

File	Coverage
All files	72%	❌
/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	64%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lazy_load_subdriver.lua	57%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lock_utils.lua	98%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/init.lua	92%	✅

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against 3706fb2

[hcarter-775]

I don't think the call_with_delay should be required here. We could put an if device:supports_capability(capabilities.lockAlarm) then gate if we are trying to ensure the device has this before emitting an event.

[HunsupJung]

When I tested it without call_with_delay, I could see the following log.

2026-03-06_05:36:55.892 | W | broker     | <Matter Lock (c32ca1d6)> Attempted to generate event for d079b3f0-a761-4e01-886a-24fc0fd34154.main but it does not support capability lockAlarm

it seems to take time to change the profile after device:try_update_metadata({profile = profile_name})

[hcarter-775]

Yes, it does take a little while to update (and when it does, this will trigger infoChanged). I would suggest we create the if conditional:

if device:supports_capability(capabilities.lockAlarm) then
    device:emit_event(capabilities.lockAlarm.alarm.clear({state_change = true}))
    device:emit_event(capabilities.lockAlarm.supportedAlarmValues({"unableToLockTheDoor"}, {visibility = {displayed = false}})) -- lockJammed is mandatory
end

This accounts for the case where a device supports lockAlarm already, before a profile update, and then it never updates for whatever reason. To me it is safer. What do you think?

[nickolas-deboom]

If that occurs, then the capability should still be emitted in the info_changed handler following the profile update right? Or, does that not always work properly due to the bug from #2812 @hcarter-775 ?

Edit: sent this before refreshing so I didn't see your comment

[HunsupJung]

@hcarter-775
DoorLockAlarm is mendatory event, so all profile should include lockAlarm capability.
There is no profile except lockAlarm capability.

[hcarter-775]

I agree, but like you stated, this can happen:

2026-03-06_05:36:55.892 | W | broker     | <Matter Lock (c32ca1d6)> Attempted to generate event for d079b3f0-a761-4e01-886a-24fc0fd34154.main but it does not support capability lockAlarm

meaning at this point the profile may not support it. And if it does later, the infoChanged event will trigger this. Therefore, we do not need to wait 5 seconds. Depending on the situation, in 5 seconds it is possible that a profile update still hasn't occurred.