# Adaptive Lighting for Home Assistant: Sun-Synced Brightness, Color and Sleep Mode

> Adaptive Lighting is a HACS-installed Home Assistant custom component that intercepts light.turn_on and adjusts brightness and color temperature from the sun's position. It is mature, Apache-2.0, and opinionated about how manual control should pause it.

**basnijholt/adaptive-lighting** — Adaptive Lighting custom component for Home Assistant

- Repository: https://github.com/basnijholt/adaptive-lighting
- Website: https://adaptive-lighting.nijho.lt
- Stars: 3,486 · Forks: 227
- Language: Python
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/basnijholt-adaptive-lighting

## What Adaptive Lighting solves that a sunset automation does not

A plain Home Assistant automation can turn lights on at sunset with a fixed brightness and a fixed color temperature. That is a single step. Adaptive Lighting instead tracks the sun continuously and recomputes brightness and color every interval, so the light drifts through the evening rather than jumping once. The README frames the goal as maintaining the circadian rhythm: cooler color temperatures at noon, warmer ones toward sunset and sunrise.

The audience is Home Assistant users who already have addressable lights (Hue, Zigbee, and similar) and who want the behavior to be per-room and reversible. The component creates a switch per instance, so a room can be adapted, put into sleep mode, or left alone. It also offers a sleep mode that the README describes as minimal brightness and a very warm color, which is a different target than simply dimming.

If you only want lights to come on at dusk, this is more machinery than the problem needs.

## Intercepting light.turn_on and the interval that follows

The mechanism is interception, not polling of your bulbs. According to the README, when a light controlled by Adaptive Lighting is first turned on, the light.turn_on service call is intercepted and the brightness and color are set from the sun's position. After that first turn-on, the README states the settings are adjusted at a regular interval.

Each instance exposes four switches, using living_room as the example name: switch.adaptive_lighting_living_room for the main on/off, switch.adaptive_lighting_sleep_mode_living_room for sleep mode, switch.adaptive_lighting_adapt_brightness_living_room and switch.adaptive_lighting_adapt_color_living_room to disable brightness or color adaptation separately. That split matters: a bulb that handles brightness well but renders color temperature badly can still be adapted on one axis.

The manual-control layer is the interesting design choice. With take_over_control enabled, the component watches for changes made by you or by another automation and marks the affected light as manually controlled, after which it stops adjusting until the light is turned off and on again or reset through the adaptive_lighting.set_manual_control service. The README also documents detect_non_ha_changes, which compares a light's state to its previously used settings to catch changes made outside Home Assistant entirely. That is a heuristic, and the README warns that some lights falsely report an on state, which can turn lights on unexpectedly.

The switch exposes manual_control, manual_control_brightness and manual_control_color attributes, but the README is explicit that these lists report flags, not the final decision. Under the default pause_all mode, changing only brightness leaves manual_control_color empty while pausing both brightness and color; under pause_changed, color keeps adapting. Reading those attributes as a complete picture of what will happen is a mistake.

## Installing Adaptive Lighting through HACS

The README points to HACS (Home Assistant Community Store) as the install path, with a my.home-assistant.io redirect badge that opens the integration inside HACS on your instance. There is no pip install or manual copy step described in the README.

If you prefer to add the repository by hand in HACS, the owner and repository names are the ones in the badge link:

```bash
# In HACS: three-dot menu -> Custom repositories
# Repository: https://github.com/basnijholt/adaptive-lighting
# Category: Integration
```

After installation and a Home Assistant restart, add the integration from Settings, then Devices and Services. The component is configured as an instance with a name; the README's examples use living_room and bedroom, which is why the switches are named switch.adaptive_lighting_living_room and so on.

A first real check is to look at what the switch reports. The README gives this template pattern for the manual-control attributes, including the fallback that matters because the attributes are absent when the switch is off:

```jinja
{{ 'light.bedroom' in (state_attr('switch.adaptive_lighting_bedroom', 'manual_control_brightness') or []) }}
```

Turn a light on and watch the attributes change as the sun moves. If nothing adapts, the README's troubleshooting section has a heading for lights that only adapt after reloading, which is the first place to look.

## Manual control, groups and the settings that surprise people

The take_over_control behavior is the part most likely to generate confusion, because the component is deliberately trying to guess intent. A light is marked manually controlled when you or an automation change it, and adaptation pauses until the light is cycled or reset with adaptive_lighting.set_manual_control. The adaptive_lighting.manual_control event fires at that moment, which lets you build automations around the pause rather than fighting it.

Group handling is subtler. With expand_light_groups set to false, manual control belongs to the group, and the README states that a direct member change cannot pause adaptation for only that member; you either control the group or enable expansion for per-light tracking. Explicit member targets in Adaptive Lighting services remain individual targets and do not mark or command the whole group. Changing expansion at runtime discards tracking and pending adaptation for targets no longer used by any profile, so toggling that setting is not free.

The component also ships services beyond apply and set_manual_control: adaptive_lighting.change_switch_settings, which lets an automation rewrite the switch's options at runtime. That is convenient and also a way to end up with a configuration that no longer matches what is written in your Home Assistant config files.

## Where Adaptive Lighting is the wrong tool

The clearest failure mode is documented by the project itself. The README carries a caution that some lights might falsely indicate an on state, which could result in lights turning on unexpectedly, and it tells you to disable detect_non_ha_changes if you hit that. Unexpected lights turning on at night is a serious enough bug that a household may reject the whole component over it, and the fix is to give up the feature that detects changes made outside Home Assistant.

Mesh networks are the second constraint. The README's troubleshooting has sections for WiFi networks and for Zigbee, Z-Wave and other mesh networks, which is an acknowledgment that sending frequent brightness and color updates to many bulbs can stress the radio. A Zigbee network with weak routing and a dozen adapted lights is a different proposition from two Hue bulbs.

Color temperature is the third. A bulb that supports brightness but not color temperature gains nothing from adapt_color, and the README's troubleshooting includes a heading for light colors not matching, which points at hardware and integration differences rather than a single bug. If your lights are dimmable white only, an ordinary schedule automation does the same job with less state to reason about.

## How it compares with doing this in Home Assistant automations

The alternative is a set of native automations: a sunrise trigger, a sunset trigger, and a script that calls light.turn_on with a brightness percentage and a color temperature. That approach keeps everything in your own YAML, survives a component removal without cleanup, and has no interception layer to reason about. It also has no manual-control detection, so a light you dim by hand stays dimmed until the next trigger fires and overwrites you.

Adaptive Lighting trades that transparency for continuous adjustment and intent detection. The trade is real in both directions: you get drift instead of steps and a manual-control pause, and you give up the ability to read the whole behavior from one automation file. The component's own troubleshooting section, with its headings for lights only adapting after reloading and for lights not responding or turning on by themselves, is the cost of that interception.

A middle option is to use Adaptive Lighting for the rooms where continuous drift matters and leave the rest on plain automations. Nothing in the component requires you to adapt every light.

## Maintenance, licence and what upgrading costs

The repository is not archived and the last push was on 2026-09-22, one day before this writing, so it is being worked on. Releases are frequent enough to matter: v1.32.0 on 2026-09-06, v1.31.0 on 2026-07-07, and v1.30.1 on 2026-01-12. The v1.32.0 release title notes zero open pull requests, which is a queue state rather than a quality claim.

For upgrades, HACS handles the update and Home Assistant needs a restart for a custom component. The pyproject.toml sets requires-python to ">=3.12" and targets py312 for linting and mypy, so the component tracks a recent Python. The repository also carries a Dockerfile that clones home-assistant/core at the dev branch and runs pytest with a per-test timeout of 9 seconds; that is a test harness for contributors, not something a user installs.

Licensing is Apache-2.0 per the LICENSE file and the pyproject.toml license field. Apache-2.0 permits commercial and private use and includes a patent grant; it also requires that you keep the licence and notice files when redistributing. If you fork the component and publish your fork, those obligations follow. This is a description of the licence text, not legal advice, and the README does not document any trademark policy for the Adaptive Lighting name.

## Conclusion

Adopt it if you run Home Assistant with lights that report color temperature and brightness, and you want one switch per room rather than a pile of sunrise and sunset automations. Skip it if your bulbs only do on and off, or if you cannot tolerate a component that watches state changes and can mark lights as manually controlled. Before committing, verify two things: that your bulbs accept color temperature commands at all, and whether detect_non_ha_changes causes phantom turn-ons on your hardware, since the README flags that failure mode directly. Install through HACS, then check switch.adaptive_lighting_living_room attributes to see what the component currently believes about each light.

## FAQ

### How do I install Adaptive Lighting in Home Assistant?

The README directs you to HACS, with a badge that opens the Adaptive Lighting integration inside the Home Assistant Community Store on your instance. After adding it through HACS and restarting Home Assistant, you add the integration from Settings, then Devices and Services.

### How do I set up Adaptive Lighting for a room?

You add an instance and give it a name, which produces switches such as switch.adaptive_lighting_living_room and switch.adaptive_lighting_sleep_mode_living_room. Brightness and color adaptation can then be toggled separately with the adapt_brightness and adapt_color switches.

### How do I turn Adaptive Lighting off for a light?

Turning off switch.adaptive_lighting_living_room stops adaptation for that instance. If a light was marked manually controlled, the README states adaptation stays paused until the light is turned off and back on or reset with the adaptive_lighting.set_manual_control service.

### What is Adaptive Lighting in Home Assistant?

It is a custom component that adjusts the brightness and color of lights based on the sun's position, per the README. It intercepts light.turn_on to apply settings on the first turn-on and then adjusts at a regular interval, while still allowing manual control.

### How do I use Adaptive Lighting with HACS?

HACS is the documented install path: the README's badge opens the integration inside the Home Assistant Community Store, and the repository is listed there. HACS also handles subsequent version updates, after which Home Assistant needs a restart.

### How do I add Adaptive Lighting to Home Assistant?

Add the integration through HACS, restart Home Assistant, then add an Adaptive Lighting instance from Settings, then Devices and Services. The instance name determines the switch names, for example switch.adaptive_lighting_living_room.

## Sources

- [basnijholt/adaptive-lighting on GitHub](https://github.com/basnijholt/adaptive-lighting)
- [License: Apache-2.0](https://github.com/basnijholt/adaptive-lighting/blob/main/LICENSE)
- [Project website](https://adaptive-lighting.nijho.lt)
- [README](https://github.com/basnijholt/adaptive-lighting/blob/main/README.md)
- [Releases](https://github.com/basnijholt/adaptive-lighting/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/basnijholt-adaptive-lighting