Skip to content

Allow configurable Kelvin limits for Adaptive Lighting #52

Description

@nashw83

Is your feature request related to a problem? Please describe:

Adaptive Lighting drives colour temperature across each bulb's full reported hardware range. For most LIFX products that range is far wider than Adaptive Lighting seems to anticipate — 90 products in lifx-lan-client's product data report 1500-9000K and another 23 report 2500-9000K, against only a handful at a conventional 2700-6500K.

The result is visible at both ends of the curve. Down near 1500K the light is distinctly orange, which is unpleasant in living areas in the evening. Up near 9000K it is a cold blue-white. Issue #18 reports the cool end of this from another user, with strips reaching 9000K under Adaptive Lighting.

My assumption is that this follows from Apple designing Adaptive Lighting around the more typical bulb gamut, combined with there being no official LIFX HomeKit implementation to calibrate against. The plugin is faithfully reporting what the hardware supports; it is the ends of that range that are unusable in practice.

HomeKit itself offers no way to bound the curve — Adaptive Lighting is on or off per bulb.

Describe the solution you'd like:

Two optional platform settings bounding the range Adaptive Lighting may request:

  • adaptiveMinKelvin (default 3000) — the warmest the curve may go
  • adaptiveMaxKelvin (default 6500) — the coolest the curve may go

Clamping applied only while Adaptive Lighting is actively driving the characteristic, so manual colour temperature changes from the Home app or the LIFX app are entirely unaffected and still reach the bulb's full range. The advertised ColorTemperature range would be left unchanged, so HomeKit continues to offer the full manual range.

With no configuration the defaults reproduce current behaviour for typical bulbs, and the clamp is skipped whenever Adaptive Lighting is inactive. It degrades to stock behaviour if the controller is unavailable or the configured range is missing or inverted.

Describe alternatives you've considered:

Turning Adaptive Lighting off and using time-based automations instead — loses the smooth curve. Narrowing the advertised range via setProps — would also restrict manual control, which I don't want. Per-bulb overrides — more configuration than the problem warrants, since the usable range is a property of taste and room rather than of the individual bulb.

Additional context:

I already have this implemented via my fork and running against current code, with unit tests covering Adaptive Lighting on and off, values above and below the limits, boundary values, inverted limits, absent settings and a missing controller. It touches three files: src/platformAccessory.ts, src/platform.ts and config.schema.json, and passes lint under the project's --max-warnings=0 setting.

I'd like to raise it as a PR. I'll base it on the 0.3.7 source once that's pushed (#49) so the diff is against current code — happy to submit sooner against master if you'd prefer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions