Separate color brightness control pr

[nekajcasa]

Summary

This PR adds support for independent control of color temperature and brightness timing.

It allows users to configure separate sunrise and sunset behavior for color temperature, while brightness can continue to follow a different schedule (e.g. time-of-day based). This addresses the use case where color temperature should follow the sun, but brightness should not.

Related issue: #1333

---

Motivation

Several users have requested the ability to decouple color temperature changes from brightness changes.
In particular:

• color temperature following the sun (circadian rhythm)
• brightness following time-of-day or user preference

Currently, Adaptive Lighting couples these behaviors, which makes certain setups (especially in northern regions with short daylight) difficult to achieve.

---

What this PR does

• Adds configuration options to independently control color temperature timing
• Allows separate sunrise and sunset handling for color temperature
• Keeps existing behavior unchanged unless the new options are enabled

---

Notes about testing

For local Home Assistant testing, I temporarily renamed the integration domain and folder so I could run this version side-by-side with the official Adaptive Lighting integration.

This PR restores the original integration domain and folder structure so it remains fully compatible with the upstream project and does not introduce a new integration.

---

Status

• ✅ Feature implemented
• 🔄 Still testing in real-world Home Assistant setup
• 🧪 Feedback and testing from other users welcome

[protyposis]

This is a nice feature 👍 Thanks for your work, looking forward to use it!

I am a bit concerned about the UX impact of the current implementation though. I think AL already has a configuration surface that can be overwhelming for the average user, and this adds several new (kind of duplicate) options. Would it be possible to hide them in the UI while the independent_color_adapting checkbox is off?

Generally, I think the approach is right since it allows great flexibility and covers all use cases described in #1333. Code also looks fine, I only skimmed it though.

For the sake of completeness, I also considered a few alternative approaches while thinking about this:

A "Keep color synced to sun" checkbox as mentioned by #1333 (comment) would be very lightweight and only add one config flag, but it would prevent more advanced scenarios, e.g., "If it gets dark at 2 pm, I want my lights to keep daylight temperature until 5 pm (so my brain doesn’t enter sleep mode too early), and only start warming/dimming at 8 pm."

A "Custom sun config" dropdown with options "color", "brightness", "both" would be conceptually similar to the checkbox, but slightly more flexible, as it allows keeping either brightness or color synced to the sun. I’m not sure whether syncing brightness but not color to the sun is a meaningful use case.

An option I explored myself in the past is an "Adaptation mode" dropdown, also with options "color", "brightness", "both", which configures the properties that an AL instance actually handles and adapts. This would allow users to create one AL instance that only adapts brightness and another AL instance (with a different config) that only adapts color, as attempted in #1333 (comment). It's the most flexible, but also by far the most complex option. And it might violate the unique-config-entry quality scale requirement, potentially making it harder to become an official integration.

[nekajcasa]

I am a bit concerned about the UX impact of the current implementation though. I think AL already has a configuration surface that can be overwhelming for the average user, and this adds several new (kind of duplicate) options. Would it be possible to hide them in the UI while the independent_color_adapting checkbox is off?

I agree with this concern — the Adaptive Lighting options menu is already quite extensive, and adding more always has a UX impact.

Unfortunately, Home Assistant’s config / options flows don’t support dynamically hiding or showing fields within the same form based on a checkbox toggle (as far as I know).

That said, I completely agree that we should avoid overwhelming users, and I think it would be important to find a better user interface solution that keeps the default experience simple while still allowing full customization for advanced use cases.

[protyposis]

A check is failing because it can't push to forked repos. Please run these commands and push the changes manually:

adaptive-lighting/.github/workflows/update-readme.yml

Lines 25 to 36 in f84ee44

	- name: Install markdown-code-runner and README code dependencies
	run: |
	uv pip install markdown-code-runner==2.1.0 pandas tabulate
	- name: Run markdown-code-runner
	run: uv run markdown-code-runner --verbose README.md
	- name: Run update services.yaml
	run: uv run python .github/update-services.py
	- name: Run update strings.json
	run: uv run python .github/update-strings.py

[protyposis]

Looks good, thanks 👍 Handing over to @basnijholt

[nekajcasa]

@protyposis @basnijholt Is there anything needed from my side to get this merged, or should I assume it’s not something you want to take right now?

[protyposis]

Hi @nekajcasa, I'm sorry for the lack of response. That's a decision for @basnijholt to take as I don't have the authorization. I'd like to see this merged and would use it myself (even though my concern about the overwhelming number config settings remains).

[basnijholt]

Sorry it took me so long to get to this. I've been a bit overwhelmed by the number of AI-assisted PRs opened here recently, and I've also been spending nearly every spare hour on my biggest project so far, MindRoom.

I'm very supportive of using AI for coding, but many of these PRs still need careful human review because even plausible-looking changes can introduce subtle breakage. That backlog made me postpone reviewing them for a while.

I've now done a batch review with Codex / GPT-5.5 (xhigh). This comment is AI-assisted, but I've reviewed it before posting.

This is a large feature branch and is currently conflict-heavy against main. It also touches the brightness/color calculation model, config, strings, tests, and the webapp.

I do not think it is safe to review or merge in this stale form. Please rebase onto current main, split the behavior change from webapp/generated-doc updates if possible, and keep/expand the tests around independent color/brightness behavior.

[basnijholt]

Follow-up from a deeper Codex / GPT-5.5 (xhigh) pass.

The independent color/brightness idea is interesting, but the test coverage is not integrated with the way this repository normally tests the component.

tests/test_independent_color.py appends the repository root to sys.path and imports custom_components.adaptive_lighting.color_and_brightness directly. The rest of the test suite imports through homeassistant.components.adaptive_lighting..., which is the path used when the component is symlinked into HA Core for tests. Directly importing through custom_components can load a separate module instance and does not exercise the integration path used by the switch/config flow.

Please move the tests to the normal import path and add at least one integration-level test that configures the new options through the switch/config data and verifies brightness follows the original sun schedule while color follows the color-specific schedule.