Skip to content

Conversation

@nickolas-deboom
Copy link
Contributor

This change utilizes the new lazy_load_sub_driver_v2 api to lazy load subdrivers in the matter switch driver.

This change utilizes the new `lazy_load_sub_driver_v2` api to lazy load
subdrivers.
@github-actions
Copy link

github-actions bot commented Nov 4, 2025

@github-actions
Copy link

github-actions bot commented Nov 4, 2025

Test Results

   71 files    464 suites   0s ⏱️
2 411 tests 2 411 ✅ 0 💤 0 ❌
4 094 runs  4 094 ✅ 0 💤 0 ❌

Results for commit cec569c.

♻️ This comment has been updated with latest results.

@github-actions
Copy link

github-actions bot commented Nov 4, 2025

File Coverage
All files 91%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/utils/device_configuration.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/utils/switch_fields.lua 98%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/utils/embedded_cluster_utils.lua 38%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/utils/switch_utils.lua 90%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/eve_energy/init.lua 91%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/third_reality_mk1/init.lua 95%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/sub_drivers/aqara_cube/init.lua 96%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/generic_handlers/attribute_handlers.lua 83%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/generic_handlers/capability_handlers.lua 88%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/generic_handlers/event_handlers.lua 97%
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua 96%

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against cec569c


return function(opts, driver, device )
local EVE_MANUFACTURER_ID = 0x130A
if device.network_type == require("st.device").NETWORK_TYPE_MATTER and
Copy link
Contributor

Choose a reason for hiding this comment

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

similar to my other comment, I generally believe the require's should be outside the functions in the case it is a static require like this, where we know what we're requiring ahead of time. same goes for the other can_handle functions

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe that limiting the scope of require's like this was brought up as part of edge drivers api 2.0, to avoid holding onto references unless needed as well as avoiding pulling in files at the top level when possible.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm, that makes sense I think. The thing is though, this st.device is already being pulled in at the top level in init.lua, so this is kinda just an extra operation, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

We probably need to better structure some stuff to make it more clear what is actually loaded at a given time, but in this case, st.device will always already be loaded in, so it's fine if you do a static require. Alternatively, maybe you can access it through the device argument of the function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is just comparing the network type retrieved from the device argument against a string value from the lua libs - so I could replace require("st.device").NETWORK_TYPE_MATTER with the string, but not sure if that's worth it considering this module is already loaded at this point as Harrison pointed out.

Copy link
Contributor

Choose a reason for hiding this comment

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

IMO the require("module").some_field is not the easiest to read and would prefer a local variable for the require; whether that is local to the module or function isnt a huge deal, but it seems like we are favoring making it local to the function at this point.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am of the opinion we should do the requires at the module level for now, if only for general consistency across the Matter drivers. To me, making things "the same" creates a more cohesive environment with more clearly set expectations.


return function(opts, driver, device)
local THIRD_REALITY_MK1_FINGERPRINT = { vendor_id = 0x1407, product_id = 0x1388 }
if device.network_type == require("st.device").NETWORK_TYPE_MATTER and
Copy link
Contributor

Choose a reason for hiding this comment

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

Separately but related, I was thinking we could pull this device-specific sub-driver stuff into the SwitchFields.vendor_overrides table? Then here we could call something like if switch_utils.get_product_override_field(device, "is_third_reality_mk1") then ... end or something like that?

We could do that for all these can_handle functions, since this may be good for moving all this "same" data into one central place

Copy link
Contributor

Choose a reason for hiding this comment

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

It's technically a separate idea, but it's related enough where I may suggest implementing it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That would definitely be nice, but I might favor doing that in a separate PR because currently, only the 3rd reality can_handle uses an exact vid and pid while the other two have slightly different checks, and I'm not sure if I want to change those here.

Copy link
Contributor

@cjswedes cjswedes left a comment

Choose a reason for hiding this comment

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

Can you update the copywrite on all the files? Its nice to get that done when there are actual code changes for a driver in a release cycle. You can do in a follow up PR too, if you get it in this release cycle.

@hcarter-775
Copy link
Contributor

Also, with the PR I just merged, the switch_utils file now has a different name and is in a different directory (thus a conflict). Should be a simple fix, but I'm not sure how nicely git rebase will understand this change. Maybe well

@cjswedes
Copy link
Contributor

cjswedes commented Nov 5, 2025

Please make sure tests are run against 59 lua libs locally before merging to exercise these changes with lazy_load_sub_driver_v2.

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.

5 participants