Matter Appliance minor refactor

[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

This change moves some common functionality into common-utils.lua, implements do_configure in the subdrivers rather than the main driver, and also contains some minor fixes involving embedded clusters.

Summary of Completed Tests

[github-actions]

Invitation URL:
https://bestow-regional.api.smartthings.com/invite/NxlwY7YJgWMA

[github-actions]

Test Results

   67 files    442 suites   0s ⏱️
2 263 tests 2 263 ✅ 0 💤 0 ❌
3 861 runs  3 861 ✅ 0 💤 0 ❌

Results for commit f30f7a9.

♻️ This comment has been updated with latest results.

[github-actions]

File	Coverage
All files	80%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-microwave-oven/init.lua	82%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-extractor-hood/init.lua	97%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/init.lua	82%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/embedded-cluster-utils.lua	49%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-dishwasher/init.lua	66%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-cook-top/init.lua	95%	✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-refrigerator/init.lua	85%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-laundry/init.lua	67%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/common-utils.lua	87%	❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-appliance/src/matter-oven/init.lua	86%	❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against f30f7a9

[hcarter-775]

nice job. seems very necessary 👍

[nickolas-deboom]

I made an update to move some of the temperature attribute and capability handlers into the main driver and remove them from the subdrivers because these have the same behavior in all cases. I left temperature_setpoint_attr_handler and setpoint_limit_handler defined in the subdrivers because difference min and max values are used in these handlers depending on the device type.

[nickolas-deboom]

I moved these test cases into their own file in order to properly test the doConfigure logic in test_init

[hcarter-775]

I made an update to move some of the temperature attribute and capability handlers into the main driver and remove them from the subdrivers because these have the same behavior in all cases. I left temperature_setpoint_attr_handler and setpoint_limit_handler defined in the subdrivers because difference min and max values are used in these handlers depending on the device type.

do you think it would be too much to put them in the main driver but make the min/max be parameters that can be passed in by the actual implementation in the subdriver? Or is that too much you think

[nickolas-deboom]

I made an update to move some of the temperature attribute and capability handlers into the main driver and remove them from the subdrivers because these have the same behavior in all cases. I left temperature_setpoint_attr_handler and setpoint_limit_handler defined in the subdrivers because difference min and max values are used in these handlers depending on the device type.

do you think it would be too much to put them in the main driver but make the min/max be parameters that can be passed in by the actual implementation in the subdriver? Or is that too much you think

In the last commit I attempted this, but ended up leaving the handlers in the subdriver, determine which set of min/max values should be used, and calling a helper function in the common module to do the handling. I don't think there is a way to avoid having the handlers in the subdrivers because the endpoint / component are needed to make the determination on which range to use. Let me know what you think!

[hcarter-775]

works for me, I like it 👍