Skip to content
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

Add BBSolar Smart Plant Light support, improve device handling for more complex mixins. #414

Open
wants to merge 19 commits into
base: 0.4.X.X
Choose a base branch
from

Conversation

jeremypm
Copy link

@jeremypm jeremypm commented Jan 6, 2025

This PR adds support for the BBSolar Smart Plant Light (https://bbsolar.cc/products/smart-grow-light). This is a complex series of changes.
In order to support this, two new mixins were created:

luminanceMixIn: Provides support for the Application.Control.Luminance capability
plantLightMixin: Inherits from togglex, luminanceMixIn, and lightMixin to support the plant lights.

These mixins (especially the plantLightMixin) wouldn't have worked with the existing backend. Implementing this (extremely weird) product required a significant amount of work on the backend. This PR also folds a range of changes in the device class. The BBSolar Smart Plant Lights use multiple channels to represent a single "physical" light, which should be represented as a device. However, it doesn't expose any "unique" abilities to indicate that this is the case.

The present approach to identifying mixin components (e.g. via abilities) doesn't facilitate this sort of identification. This PR migrates from using the ABILITY_MATRIX (within the device_factory) to a dynamic loading/dispatch facility. First, all mixins are loaded from the given package. Mixins are annotated with a special class: DynamicFilteringMixin, which exposes the "filter" function. When a new cached type is build, the filter function is run for each device ability/type. If it returns true, that mixin is assumed to be part of the device.

Separation of the "extended" abilities is handled by class inheritance. For example, the ToggleMixin class represents the TOGGLE ability, and extends from DynamicFilteringMixin. The ToggleXMixin class extends from Toggle, and contains a unique filter function for TOGGLEX abilities. Some logic within the class loader prevents Toggle from being loaded if a subclass already is (e.g.toggleX).

Other changes were required, such as the addition of the channelRemappingMixin class, which allows the detected channel info to be remapped. This is required since the light presents 10 channels: main, light A, light B (which only support on/off operations) and each individual channel (which support luminance).

Finally, call chaining (e.g. use of super()) was removed for push notifications and device updates performed in the mixin. This is required to allow the multiple inheritance required for the plantLight to work correctly.

The plantLightMixin presents the light as 3 channels: first is a main channel, which allows control of both light strips. The next two represent each light.

Test cases have been added for the mixins and the backend modifications.

Jeremy Pierce mayer and others added 19 commits December 22, 2024 18:22
…, allowing significantly more robust filtering and selection of devices.
…mixins

Feature/add dynamic dispatch for mixins
…luminanceMixin. Some cleanup is still required.
…l all relevant functions. This allows things like diamond inheritance to work correctly. Also renamed luminance test case.
…hanges to a given light, causing the luminance to "jump"
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.

1 participant