Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 8 commits into from
Oct 21, 2024

Conversation

hcarter-775
Copy link
Contributor

@hcarter-775 hcarter-775 commented Oct 1, 2024

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
  • 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

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

Copy link

github-actions bot commented Oct 1, 2024

Duplicate profile check: Passed - no duplicate profiles detected.

Copy link

github-actions bot commented Oct 1, 2024

Channel deleted.

Copy link

github-actions bot commented Oct 1, 2024

File Coverage
All files 91%
/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 91%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-lock/src/new-matter-lock/init.lua 90%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against e0179b2

Copy link

github-actions bot commented Oct 1, 2024

Test Results

   64 files    400 suites   0s ⏱️
1 988 tests 1 988 ✅ 0 💤 0 ❌
3 429 runs  3 429 ✅ 0 💤 0 ❌

Results for commit e0179b2.

♻️ This comment has been updated with latest results.

@nickolas-deboom
Copy link
Contributor

nickolas-deboom commented Oct 1, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@hcarter-775
Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor

@ctowns ctowns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, however, there are multiple other places in the matter-lock driver that update the device's profile, for example:

device:try_update_metadata({profile = "lock-without-codes"})

device:try_update_metadata({profile = "base-lock", provisioning_state = "PROVISIONED"})

device:try_update_metadata({profile = "nonfunctional-lock", provisioning_state = "NONFUNCTIONAL"})

Two of the instances have to do with setting a profile for a non-functional lock, however in the device_added function, I think we'd also need to do something similar in the case that the device is going to be switched to the lock-without-codes profile. Essentially, you'd have to just add a check that the device would switch to lock-without-codes-batteryLevel/nobattery depending on what it supports like you have done above.

Also, when recovering from a non-functional state, we'd probably want to copy what you've done and make sure the device joins to base-lock plus whatever is appropriate for it's battery situation.

@ctowns
Copy link
Contributor

ctowns commented Oct 1, 2024

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
Copy link
Contributor Author

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.

@hcarter-775 hcarter-775 changed the title Add Dynamic Battery Support for Non-WWST Door Lock Devices Add Dynamic Battery Support for Base-Lock Profiled Door Lock Devices Oct 2, 2024
Copy link
Contributor

@ctowns ctowns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I would suggest waiting for the new matter lock PR to merge first and then rebasing these changes on top of it. This PR should be easier to rebase and we want the new matter lock PR to be as frictionless as possible a this point.

@hcarter-775 hcarter-775 merged commit b800c9c into main Oct 21, 2024
12 checks passed
@hcarter-775 hcarter-775 deleted the bridged-lock branch October 21, 2024 15:55
Copy link

@Huangxiangjie Huangxiangjie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If device Power Source 0x002F Features is BAT, But do not support 0x000D BatTimeRemaining


-- if not fingerprinted, dynamically configure base-lock profile based on Power Source cluster checks
local power_source_eps = device:get_endpoints(clusters.PowerSource.ID)
local battery_feature_eps = device:get_endpoints(clusters.PowerSource.ID, {feature_bitmap = clusters.PowerSource.types.PowerSourceFeature.BATTERY})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hcarter-775
I am confused that if device do not have attribute 0x000D BatTimeRemaining, then device will also matched "-batteryLevel". In this case, device will not report BatTimeRemaining, if plugin has problem with device status not updated error, for example like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants