feat: add nightlight control support for Haiku H/I uplight fans#189
Open
jhesketh wants to merge 2 commits into
Open
feat: add nightlight control support for Haiku H/I uplight fans#189jhesketh wants to merge 2 commits into
jhesketh wants to merge 2 commits into
Conversation
|
|
Add NightlightProperties support discovered on Haiku H/I Series fans with an uplight module, where firmware reports a nightlight sub-message at Properties field 83. The library now models color (83.1), enabled (83.2), and brightness_percent (83.3) in proto and generated Python bindings. Expose device APIs has_nightlight, nightlight_color, nightlight_enabled, and nightlight_brightness_percent as read/write properties. Writes use a pre-populated sub-message copy helper so partial updates do not reset sibling nightlight fields, and devices that do not expose field 83 continue returning None gracefully. Disclaimer: This commit was developed with assistance from Claude and Codex and is based on reverse-engineering/experimentation on limited hardware. Please review carefully and validate behavior on your own target devices before relying on it.
Add canonical library constants for the experimentally verified nightlight palette used by Haiku H/I uplight-capable devices: NIGHTLIGHT_COLOR_MAP plus NIGHTLIGHT_COLOR_MIN/MAX. This maps values 1-9 to user-facing color names and makes the valid range explicit for integrations. Also update proto comments to record device behavior for out-of-range values (>=10 turns light off, 0 ignored) and re-export the constants from aiobafi6.__init__ so downstream consumers can build stable UI and validation without hardcoding magic numbers. Disclaimer: This commit was developed with assistance from Claude and Codex and is based on reverse-engineering/experimentation on limited hardware. Please review carefully and validate behavior on your own target devices before relying on it.
jfroy
force-pushed
the
feature/nightlight-control
branch
from
February 24, 2026 04:13
dbeefc7 to
bd22516
Compare
jfroy
approved these changes
Feb 24, 2026
Owner
|
Please rebase with your other PR which is now in main. Also, does this need the subfield merge fix as well? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Add NightlightProperties support discovered on Haiku H/I Series fans with an uplight module, where firmware reports a nightlight sub-message at Properties field 83. The library now models color (83.1), enabled (83.2), and brightness_percent (83.3) in proto and generated Python bindings.
Expose device APIs has_nightlight, nightlight_color, nightlight_enabled, and nightlight_brightness_percent as read/write properties. Writes use a pre-populated sub-message copy helper so partial updates do not reset sibling nightlight fields, and devices that do not expose field 83 continue returning None gracefully.
Disclaimer: This commit was developed with assistance from Claude and Codex and is based on reverse-engineering/experimentation on limited hardware. Please review carefully and validate behavior on your own target devices before relying on it.