Support combination switch/button devices

[nickolas-deboom]

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

CHAD-13993

This change adds support for devices that contain both switch and button endpoints. The button driver was initially merged into the driver in PR 1547, but until now only pure-button and pure-switch devices were supported.

The first switch endpoint and all button endpoints will join as a multi-component device, and additional switch endpoints will join as child devices.

The GE/Cync dimmer/keypad is an example of a device that is supported by this change.

Summary of Completed Tests

See new unit tests and also here for an overview of testing. Additional regression testing is documented here.

[ctowns]

Just a reminder to rebase as well so that the latest changes are present and so that unit tests can run :)

[github-actions]

Channel deleted.

[github-actions]

Test Results

   64 files    401 suites   0s ⏱️
1 999 tests 1 999 ✅ 0 💤 0 ❌
3 439 runs  3 439 ✅ 0 💤 0 ❌

Results for commit d14d457.

♻️ This comment has been updated with latest results.

[github-actions]

File	Coverage
All files	94%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua	96%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/eve-energy/init.lua	91%	✅
/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/embedded-cluster-utils.lua	38%	❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against d14d457

[nickolas-deboom]

Just a reminder to rebase as well so that the latest changes are present and so that unit tests can run :)

Done!

[ctowns]

One thing we will want to do before merging these changes is complete a set of regression tests for the various device types that share this driver since we are touching a critical code path. I think you could potentially add the test cases to the great confluence page you already put together, listing which cases are covered by unit tests and real devices, or both: https://smartthings.atlassian.net/wiki/spaces/~7120201ec2fa4a1b0548dd86df78b89d08422e/pages/3449815291/Supporting+Combination+Button+Switch+Devices#Testing.

Let's think of some device compositions that are commonly used and also add in some that might be corner cases. For example:

1. Single switch device (bulb, plug, etc.)
2. Single button device
3. Multi-switch only device
4. Multi-button only device
5. Switch/Button combo device with a single switch and multiple buttons
6. Switch/Button combo with a multiple switches and a single button
7. Switch/Button combo with multiple switches and multiple buttons
8. Switch/Button combo with multiple switches and multiple buttons where the switch has lower endpoints than the buttons

A good chunk of these are already covered by existing unit tests and the ones you have added, I just wanted to list all the ones I could think of to be complete. Where we can, we should do smoke testing with real devices in addition to the unit tests. Some of these will be impossible to test with real devices (test 8 for example, I'm not sure we have a real device like that), so they can be covered by a unit test case (which it looks like you've already done for test 8). If you can think of any more edge cases, please add them!

[nickolas-deboom]

One thing we will want to do before merging these changes is complete a set of regression tests for the various device types that share this driver since we are touching a critical code path. I think you could potentially add the test cases to the great confluence page you already put together, listing which cases are covered by unit tests and real devices, or both: https://smartthings.atlassian.net/wiki/spaces/~7120201ec2fa4a1b0548dd86df78b89d08422e/pages/3449815291/Supporting+Combination+Button+Switch+Devices#Testing.

Let's think of some device compositions that are commonly used and also add in some that might be corner cases. For example:

1. Single switch device (bulb, plug, etc.)

2. Single button device

3. Multi-switch only device

4. Multi-button only device

5. Switch/Button combo device with a single switch and multiple buttons

6. Switch/Button combo with a multiple switches and a single button

7. Switch/Button combo with multiple switches and multiple buttons

8. Switch/Button combo with multiple switches and multiple buttons where the switch has lower endpoints than the buttons

A good chunk of these are already covered by existing unit tests and the ones you have added, I just wanted to list all the ones I could think of to be complete. Where we can, we should do smoke testing with real devices in addition to the unit tests. Some of these will be impossible to test with real devices (test 8 for example, I'm not sure we have a real device like that), so they can be covered by a unit test case (which it looks like you've already done for test 8). If you can think of any more edge cases, please add them!

Good point! I added section Test coverage for other device compositions to the confluence page. I created a table with the endpoint configurations you listed and linked to the test case files that cover each configuration. I tested out a few cases with physical devices I have, and I also expanded test_matter_multi_button_child_switch.lua to include test cases to cover cases 5, 7, and 8. Please let me know if you think there is anything else I should add!

[ctowns]

I think this confluence page needs to be updated with the latest screenshots with the new component layout: Test coverage for other device compositions

I would also note on that page what switch/button combos are supported, and what expected behavior is for an unsupported combination device.

Also, I think another round of device regression testing might be good to verify the latest changes with the new layout. Fortunately, a lot of this is covered with unit tests, so good job on that test coverage!

[nickolas-deboom]

I think this confluence page needs to be updated with the latest screenshots with the new component layout: Test coverage for other device compositions

I would also note on that page what switch/button combos are supported, and what expected behavior is for an unsupported combination device.

Also, I think another round of device regression testing might be good to verify the latest changes with the new layout. Fortunately, a lot of this is covered with unit tests, so good job on that test coverage!

I updated the confluence page with new details about testing, for both the Inovelli and the GE/Cync device. I added some notes on what the behavior would be for unsupported device types as well in the Testing section.

[tpmanley]

Few minor comments but otherwise looks good to me. Need to make sure to do a thorough regression test with devices that would use the affected code paths.

[nickolas-deboom]

Few minor comments but otherwise looks good to me. Need to make sure to do a thorough regression test with devices that would use the affected code paths.

I did regression testing on all of the devices listed on this page, which includes lights, plugs, and buttons as well as the GE/Cync and Inovelli switch/button combo devices. I also created unit tests to verify the functionality for a device that would join a MCD profile containing switch and button components as well as a device that has button endpoints and a switch endpoint that would not be supported by a MCD profile and uses parent-child for the switch endpoint instead.