Add Dynamic Battery Support for Base-Lock Profiled Door Lock Devices

[hcarter-775]

Check all that apply

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
• [x] New feature
• [ ] Refactor

Checklist

• [x] I have performed a self-review of my code
• [x] 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
• [x] 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

Jira ticket showing mis-profiling of a bridged door lock: https://smartthings.atlassian.net/browse/MTR-821 Further, there is a general ticket on adding dynamic profiling to this driver: https://smartthings.atlassian.net/browse/CHAD-13948

This logic will permit dynamic profiling on the base-lock profile depending on the Power Source cluster, and will ignore devices that do not auto-profile as base-lock.

Summary of Completed Tests

Unit tests Bridged Switchbot device - Passed VDA Door Lock - Passed VDA Door Lock (Lock Codes) - Passed Yale Assure Matter Lock - Passed

[github-actions[bot]]

Duplicate profile check: Passed - no duplicate profiles detected.

[github-actions[bot]]

Channel deleted.

[github-actions[bot]]

File	Coverage
All files	91%	:white_check_mark:
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/lock_utils.lua	98%	:white_check_mark:
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/init.lua	91%	:white_check_mark:
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua	90%	:white_check_mark:

Minimum allowed coverage is 90%

Generated by :monkey: cobertura-action against e0179b24d3abe851cf16a81a25de581e48ce2829

[github-actions[bot]]

Test Results

   64 files    400 suites   0s :stopwatch: 1 988 tests 1 988 :white_check_mark: 0 :zzz: 0 :x: 3 429 runs  3 429 :white_check_mark: 0 :zzz: 0 :x:

Results for commit e0179b24.

:recycle: This comment has been updated with latest results.

[nickolas-deboom]

This looks good to me, but I was just thinking that one potential drawback with this approach is that each PR for new WWST device fingerprints would also have to include an update to the list of fingerprinted devices in do_configure (the one I mentioned in my other comment for example). Maybe that is no big deal but I thought I'd mention it

[hcarter-775]

Yeah @nickolas-deboom I agree, that's definitely a downside. Unfortunately, there's not really any better method in place of solving this issue atm. I figured we would inform Alissa of this in the next Risk Analysis meeting and then you and I can help monitor this as well until we put a better solution in place.

[hcarter-775]

@nickolas-deboom I also think this example might get some more proactive desire to fix this situation in a larger way

[hcarter-775]

And I just thought of this, but another point of note here is that there is a new and improved matter Lock driver coming soon, so this issue may be extremely temporary.

[nickolas-deboom]

Those are good points, and I can't think of a better way to handle this either, so I think this is a good solution for now, especially given it might be temporary since there are improvements coming to this driver as you mentioned.

[ctowns]

Also before merging, this change should be tested with both the new bridged the device as well as regression tested against an existing lock.

[hcarter-775]

Yes, I agreee Cooper. I will add the dynamic battery profiling logic to those places as well. And I have already reached out on the affected ticket to get some testing with the new device.