-
Notifications
You must be signed in to change notification settings - Fork 466
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
Conversation
Duplicate profile check: Passed - no duplicate profiles detected. |
Channel deleted. |
5978d4c
to
01b03f1
Compare
Minimum allowed coverage is Generated by 🐒 cobertura-action against e0179b2 |
Test Results 64 files 400 suites 0s ⏱️ Results for commit e0179b2. ♻️ This comment has been updated with latest results. |
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 |
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. |
@nickolas-deboom I also think this example might get some more proactive desire to fix this situation in a larger way |
01b03f1
to
8849b80
Compare
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. |
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. |
There was a problem hiding this 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.
Also before merging, this change should be tested with both the new bridged the device as well as regression tested against an existing lock. |
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. |
There was a problem hiding this 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.
ae37c50
to
ed1dd1b
Compare
There was a problem hiding this 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}) |
There was a problem hiding this comment.
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.
Check all that apply
Type of Change
Checklist
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