Matter Switch: Attempt re-profiling on device software updates #2466
Conversation
|
Invitation URL: |
Test Results 71 files 457 suites 0s ⏱️ Results for commit eda1721. ♻️ This comment has been updated with latest results. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against eda1721 |
drivers/SmartThings/matter-switch/src/utils/device_configuration.lua
Outdated
Show resolved
Hide resolved
hcarter-775
force-pushed
the
switch-allow-reprofiling
branch
from
199f355 to
eda1721
Compare
| device:subscribe() | ||
| local button_eps = device:get_endpoints(clusters.Switch.ID, {feature_bitmap=clusters.Switch.types.SwitchFeature.MOMENTARY_SWITCH}) | ||
| if #button_eps > 0 and device.network_type == device_lib.NETWORK_TYPE_MATTER then | ||
| if device.network_type == device_lib.NETWORK_TYPE_MATTER then |
There was a problem hiding this comment.
is the checking for button support done inside button_cfg?
There was a problem hiding this comment.
yes, this function will be a no-op if there are no button-mappable endpoints. So I could revert it, but it removes an extra check. Maybe this adds confusion though?
There was a problem hiding this comment.
thought about this more, and I improved the api by having the caller pass in the endpoints that will be mapped, still cutting out the extra check while keeping this clarity
| end | ||
| end | ||
|
|
||
| function SwitchLifecycleHandlers.device_removed(driver, device) |
There was a problem hiding this comment.
I just moved this to the bottom of the file. We never touch this and I personally am always getting confused where device_init is when developing with this placed above it.
hcarter-775
force-pushed
the
update-metadata-switch
branch
2 times, most recently
from
fb3f845 to
73aa8dc
Compare
Description of Change
We store data related to the device software version (saved from the BasicInformation cluster's softwareVersion attribute) on the driver st_store. This leverages that version to attempt a re-profiling if this is ever updated. The same data is what is leveraged by the hub to re-interview a device on a device update as well.
This is built on top of the following PR: #2481 since that allows for more generic re-profiling of the parent devices.
Summary of Completed Tests
Tested that
try_update_metadataworks as expected for child devices.Tested profile update logic by manually editing the software version of a device in order to trigger this logic.