-
Notifications
You must be signed in to change notification settings - Fork 519
Matter Switch: Lazy load subdrivers if possible #2525
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?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| -- Copyright 2025 SmartThings, Inc. | ||
| -- Licensed under the Apache License, Version 2.0 | ||
|
|
||
| return function(opts, driver, device) | ||
| if device.network_type == require("st.device").NETWORK_TYPE_MATTER then | ||
| local name = string.format("%s", device.manufacturer_info.product_name) | ||
| if string.find(name, "Aqara Cube T1 Pro") then | ||
| return true, require("sub_drivers.aqara_cube") | ||
| end | ||
| end | ||
| return false | ||
| end |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| -- Copyright 2025 SmartThings, Inc. | ||
| -- Licensed under the Apache License, Version 2.0 | ||
|
|
||
| return function(opts, driver, device) | ||
| local EVE_MANUFACTURER_ID = 0x130A | ||
| if device.network_type == require("st.device").NETWORK_TYPE_MATTER and | ||
| device.manufacturer_info.vendor_id == EVE_MANUFACTURER_ID then | ||
| return true, require("sub_drivers.eve_energy") | ||
| end | ||
| return false | ||
| end | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| -- Copyright 2025 SmartThings, Inc. | ||
| -- Licensed under the Apache License, Version 2.0 | ||
|
|
||
| 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 We could do that for all these
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
| device.manufacturer_info.vendor_id == THIRD_REALITY_MK1_FINGERPRINT.vendor_id and | ||
| device.manufacturer_info.product_id == THIRD_REALITY_MK1_FINGERPRINT.product_id then | ||
| return true, require("sub_drivers.third_reality_mk1") | ||
| end | ||
| return false | ||
| 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.
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_handlefunctionsThere 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 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.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.
Hmmm, that makes sense I think. The thing is though, this
st.deviceis already being pulled in at the top level ininit.lua, so this is kinda just an extra operation, right?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 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.devicewill always already be loaded in, so it's fine if you do a static require. Alternatively, maybe you can access it through thedeviceargument of the function?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.
This is just comparing the network type retrieved from the
deviceargument against a string value from the lua libs - so I could replacerequire("st.device").NETWORK_TYPE_MATTERwith the string, but not sure if that's worth it considering this module is already loaded at this point as Harrison pointed out.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.
IMO the
require("module").some_fieldis 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.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 am of the opinion we should do the
requiresat 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.