-
Notifications
You must be signed in to change notification settings - Fork 506
Updating matter rvc ux #2343
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
base: main
Are you sure you want to change the base?
Updating matter rvc ux #2343
Conversation
- Integrate components - Remove mode capability for run mode cluster Signed-off-by: HunsupJung <[email protected]>
Signed-off-by: HunsupJung <[email protected]>
Duplicate profile check: Passed - no duplicate profiles detected. |
Invitation URL: |
Test Results 69 files 449 suites 0s ⏱️ Results for commit 0716447. ♻️ This comment has been updated with latest results. |
Minimum allowed coverage is Generated by 🐒 cobertura-action against 0716447 |
Signed-off-by: HunsupJung <[email protected]>
d1c20d1
to
df9744e
Compare
@@ -5,6 +5,8 @@ components: | |||
capabilities: | |||
- id: robotCleanerOperatingState |
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.
Are these profiles currently in use by devices? If so, it might be better to create new profiles rather than removing capabilities to avoid breaking automations / rules for devices in the field.
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.
I confirmed these profiles are used by devices, and that automations are being used on the mode operation for at least a handful, though the percentage is small.
Instead of adding new profiles, I believe we should modify the system to use the benefits of modular profiles.
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
Can we use the modular profiles by 9/9? If so, could you share the way to use the modular profiles?
local function component_to_endpoint(device, component_name) | ||
-- Use the find_default_endpoint function to return the first endpoint that | ||
-- supports a given cluster. | ||
return find_default_endpoint(device, clusters.RvcOperationalState.ID) |
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.
What does the endpoint structure typically look like for a RVC? Are the clusters usually all implemented on the same endpoint?
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.
I not sure, but Roborock implements Power Source
, RVC Run Mode
, RVC Clean Mode
, RVC Operational State
, and Service Area
on the endpoint 1.
a5a6c42
to
97099e4
Compare
Signed-off-by: HunsupJung <[email protected]>
97099e4
to
6cf2dfc
Compare
if not device:get_field(SERVICE_AREA_PROFILED) and #device:get_endpoints(clusters.ServiceArea.ID) > 0 then | ||
match_profile(driver, device) | ||
device:set_field(SERVICE_AREA_PROFILED, true) | ||
end |
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 not device:get_field(SERVICE_AREA_PROFILED) and #device:get_endpoints(clusters.ServiceArea.ID) > 0 then | |
match_profile(driver, device) | |
device:set_field(SERVICE_AREA_PROFILED, true) | |
end | |
if not device:get_field(SERVICE_AREA_PROFILED) then | |
if #device:get_endpoints(clusters.ServiceArea.ID) > 0 then | |
match_profile(driver, device) | |
end | |
device:set_field(SERVICE_AREA_PROFILED, true, { persist = true }) | |
end |
we only want this logic to run once, and we want to set the device as profiled whether or not service area is part of the 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.
Okay, I got it.
|
||
local function do_configure(driver, device) | ||
match_profile(driver, device) | ||
device:set_field(SERVICE_AREA_PROFILED, true) |
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.
device:set_field(SERVICE_AREA_PROFILED, true) | |
device:set_field(SERVICE_AREA_PROFILED, true, { persist = true }) |
this field should not be reset on a driver restart
local RUN_MODE_SUPPORTED_MODES = "__run_mode_supported_modes" | ||
local CURRENT_RUN_MODE = "__current_run_mode" |
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.
why do we need to set CURRENT_RUN_MODE
instead of using the get_latest_state
api as we did before? And would you mind adding a short comment by this field to explain this?
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.
mode
capability related to run mode is going to be deleted. So CURRENT_RUN_MODE
value is needed to store the latest CurrentMode
value of RVC Run Mode
Cluster
@@ -32,10 +32,11 @@ if version.api < 13 then | |||
clusters.Global = require "Global" | |||
end | |||
|
|||
local COMPONENT_TO_ENDPOINT_MAP = "__component_to_endpoint_map" |
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 we're removing this field, can you please set it as null in the init function? we can leave this local variable deleted and just write something like:
-- comp/ep map functionality removed 9/5/25.
device:set_field("__component_to_endpoint_map", nil)
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.
Okay, I got it.
local eps = device:get_endpoints(cluster) | ||
table.sort(eps) | ||
for _, v in ipairs(eps) do | ||
if v ~= 0 then --0 is the matter RootNode endpoint |
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.
I don't understand why we're ignoring the root endpoint here?
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.
When the manufacturer create a ZAP file through the ZAP tool, number 0 will be used as Root node and the device type that is wanted to add will be 1. Of course, the manufacturer can set the endpoint arbitrarily.
This code is also included in all other Matter drivers, so if we remove it, it would be better to remove it all at once in the future.
capabilities.mode.ID, | ||
capabilities.mode.mode.NAME | ||
) | ||
local current_run_mode = device:get_field(CURRENT_RUN_MODE) |
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.
not sure where to comment about this, but line 534 of the current PR is:
endpoint_id = device:component_to_endpoint("runMode")
we need to remove this reference. I wonder also how this was tested where this was missed? Is this logic required at all anymore?
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.
Thank you for finding the part. As you mentioned, we need to change "runMode"
to cmd.component
.
The reason why it was not a problem during the test is that component_to_endpoint
finds an endpoint with RvcOperationalState
cluster regardless of what component is put in.
["cleanMode"] = clean_mode_eps[1] | ||
} | ||
device:set_field(COMPONENT_TO_ENDPOINT_MAP, component_to_endpoint_map, {persist = true}) | ||
local function component_to_endpoint(device, component_name) |
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.
I suggest we remove this function in all places in the driver and directly use find_default_endpoint
with the appropriate cluster that the command handler should be mapping to.
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.
Okay, I got it.
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.
these are some initial comments/questions I have
else | ||
return device.MATTER_DEFAULT_ENDPOINT | ||
local function find_default_endpoint(device, cluster) | ||
local res = device.MATTER_DEFAULT_ENDPOINT |
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.
let's remove the res
variable setting and just return default.MATTER_DEFAULT_ENDPOINT
explicitly at the end?
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.
Okay, I got it.
- component: cleanMode | ||
capability: mode | ||
- component: main | ||
capability: serviceArea |
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.
why was the location of this capability moved in this definition?
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.
There is no reason. I wanted to emphasize the relation between mode
and robotCleanerOperatingState
.
Signed-off-by: HunsupJung <[email protected]>
local function find_default_endpoint(device, cluster) | ||
local res = device.MATTER_DEFAULT_ENDPOINT | ||
local eps = device:get_endpoints(cluster) | ||
local function find_default_endpoint(device, component_name) |
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.
sorry, I don't think I was completely clear before. Instead of using the component_name
as an argument here, I think we should make the cluster be the argument, and call this function for whatever cluster is needed in each handler. I'm thinking something like:
local function find_default_endpoint(device, cluster_id)
local eps = device:get_endpoints(cluster_id)
... leave the rest the same ...
end
and then change what is passed in at the callsite.
if not device:get_field(SERVICE_AREA_PROFILED) and #device:get_endpoints(clusters.ServiceArea.ID) > 0 then | ||
match_profile(driver, device) | ||
device:set_field(SERVICE_AREA_PROFILED, true) | ||
device:set_component_to_endpoint_fn(find_default_endpoint) |
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.
we no longer require this line if we go the route of my previous suggestion
Type of Change
Checklist
Description of Change
The unnecessary mode capability for Run Mode cluster has been deleted.
Summary of Completed Tests
This feature is being tested with following TC in SVT.
https://smartthings.atlassian.net/wiki/spaces/STHK/pages/4088660856/REQ-22349+Matter+RVC+UX+Upgrade+TC