Skip to content

Matter Switch: Add greater Energy profiling logic for Switches #2199

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

Merged
merged 1 commit into from
Jul 22, 2025

Conversation

hcarter-775
Copy link
Contributor

@hcarter-775 hcarter-775 commented Jun 16, 2025

Description of Change

Update the Matter Switch driver to support the Power Topology cluster. Specifically, include support for the Node and Set features of the cluster. Update unit tests to handle this update.

Further, update powerConsumptionReport handling to only send reports to one single capability, even when there are multiple child devices getting energy reports.

Last, update energy and power handlers from emit_event_for_endpoint() calls to emit_component_event() calls to simplify handling by avoiding the weaknesses in our current endpoint_to_component() functionality.

Summary of Completed Tests

Tests updated and continue to pass.
Tested on multi-plug energy device.
Tested on single plug energy device.
Tested for backwards compatibility with other light devices.

Copy link

Duplicate profile check: Passed - no duplicate profiles detected.

Copy link

github-actions bot commented Jun 16, 2025

Channel deleted.

Copy link

github-actions bot commented Jun 16, 2025

Test Results

   68 files    446 suites   0s ⏱️
2 324 tests 2 324 ✅ 0 💤 0 ❌
3 919 runs  3 919 ✅ 0 💤 0 ❌

Results for commit b0b7b50.

♻️ This comment has been updated with latest results.

Copy link

github-actions bot commented Jun 16, 2025

File Coverage
All files 92%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/aqara-cube/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/eve-energy/init.lua 92%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/embedded-cluster-utils.lua 38%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/third-reality-mk1/init.lua 95%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua 93%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against b0b7b50

@nickolas-deboom
Copy link
Contributor

These changes look great! I think it might be a good idea to test on some additional device types since some of the init code is being changed.

@hcarter-775 hcarter-775 force-pushed the add/power-topology-handling branch from aeafdff to ca5b1d0 Compare June 18, 2025 21:50
@nickolas-deboom
Copy link
Contributor

I'm trying to remember but can't quite recall, I think you mentioned that these changes would result in re-profiling for certain devices that would currently not be re-profiled and just rely on fingerprints, is that the case?

@hcarter-775
Copy link
Contributor Author

I'm trying to remember but can't quite recall, I think you mentioned that these changes would result in re-profiling for certain devices that would currently not be re-profiled and just rely on fingerprints, is that the case?

@nickolas-deboom yes, that's true. See the assign_switch_profile call at the bottom of match_profile, that will be called for all switch devices that didn't get an early return due to previous specific handling.

@nickolas-deboom
Copy link
Contributor

Taking another look at this, "update powerConsumptionReport handling to only send reports to one single capability, even when there are multiple child devices getting energy reports." - wondering where this change is coming from? Was there a request or something?

@@ -141,6 +141,7 @@ local function test_init()
end

test.socket.matter:__expect_send({aqara_mock_device.id, subscribe_request})
aqara_mock_device:set_field("__ELECTRICAL_TOPOLOGY", {topology = false, tags_on_ep = {}}, {persist = false}) -- since we're assuming this would have happened during device_added in this case.
Copy link
Contributor

@nickolas-deboom nickolas-deboom Jul 1, 2025

Choose a reason for hiding this comment

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

The Aqara subdriver overrides device_added so this field would not be set in the current implementation and so the subdriver may need to be updated to set it. The other subdrivers may also need to account for this

Copy link
Contributor Author

@hcarter-775 hcarter-775 Jul 1, 2025

Choose a reason for hiding this comment

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

this test doesn't handle a device that's using a subdriver.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oops, my bad, I saw Aqara and thought this was the Aqara cube test file

@@ -277,7 +280,7 @@ test.register_coroutine_test(
{
-- don't use "aqara_mock_children[aqara_child1_ep].id,"
-- because energy management is at the root endpoint.
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment can be removed now 😅

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, is this the correct behavior? If I remember right this device has it's energy management cluster on the root endpoint, so why is it now testing aqara_child1_ep?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is, this update actually makes the whole aqara child system work better now we use emit_component_event(), side stepping the original issues we faced having the energy management cluster on the root endpoint.

@hcarter-775
Copy link
Contributor Author

hcarter-775 commented Jul 1, 2025

Taking another look at this, "update powerConsumptionReport handling to only send reports to one single capability, even when there are multiple child devices getting energy reports." - wondering where this change is coming from? Was there a request or something?

ST Energy will only take one report per device at the moment, so there's no reason to be sending multiple reports. Before this PR, multiple reports just weren't supported at all, so this isn't really a "change".

Copy link
Contributor

@nickolas-deboom nickolas-deboom left a comment

Choose a reason for hiding this comment

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

I reviewed again and the changes look good to me, I would just recommend testing with some other device types associated with the switch driver just to confirm no regression was introduced 👍

@hcarter-775 hcarter-775 mentioned this pull request Jul 22, 2025
12 tasks
@hcarter-775 hcarter-775 force-pushed the add/power-topology-handling branch from f2e532c to b0b7b50 Compare July 22, 2025 21:35
@hcarter-775 hcarter-775 merged commit f3642cf into main Jul 22, 2025
12 checks passed
@hcarter-775 hcarter-775 deleted the add/power-topology-handling branch July 22, 2025 22:39
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.

2 participants