Matter Switch: Move Sensor handlers into Lazily Loaded Subdriver #2770
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Change
This is a prerequisite for upcoming changes porting all of the device type logic from the main Matter Sensor driver into this new subdriver in the effort to consolidate and better modularize Matter device support.
I've broken the current Sensor device type support already present in Matter Switch into a subdriver first, before adding in the extra complexity inherent in porting over all the Matter Sensor logic, to clarify and converse about what a "good" generic device type subdriver should look like, and to support review of this new type of structure before adding in even more extra complexity.
As part of this groundwork, some semi-significant changes to the
device:subscribe()extension can be found to account for a known issue in what is now just the camera and sensor subdrivers, the fact that there is currently no way for subdriver-specificsubscribed_attributesandsubscribed_eventstables to be accounted for during subscription. These changes aim to create a flexible way to add subdriver-specific capability-cluster subscription tables, and to aggregate them safely as needed during subscription.At present, this change will mostly account for some nominal memory savings for camera devices and devices not supporting any sensor handling.
Summary of Completed Tests
Very few unique devices actually use these subdriver handlers now, limiting the blast radius to a couple specific motion-button devices, the aqara climate sensor, and a couple occupancy-light devices, and these devices are all well expressed in the current driver test suite.