Here is a thing nobody tells you when you install smart bulbs: the moment someone flips the physical wall switch off, your entire carefully-configured Adaptive Lighting setup quietly falls apart.
Not loudly. Not with an error. It just stops adapting. Silently. And you won’t notice until you walk into the lounge the following morning and wonder why it looks like a dentist’s waiting room at full blast when it should be a warm, gentle sunrise scene.
This is the story of how I fixed it — and the unexpected gotchas along the way.
The Problem
In our house, the lounge lights are on the new IKEA Kajplats smart bulbs controlled through Home Assistant. Adaptive Lighting handles the colour temperature and brightness throughout the day — warm and dim in the evening, cooler and brighter for the afternoon, that sort of thing.
The issue is that the bulbs are physically powered off at the socket overnight. When they come back on in the morning, Adaptive Lighting sees them briefly go from `unavailable` to `on` — and immediately marks them as **manually controlled**. From that point on, it backs off completely and leaves them wherever they land.
This is, technically, correct behaviour. Adaptive Lighting is designed to respect manual changes. It just doesn’t know the difference between “someone deliberately changed the bulb” and “the bulb just came back from the dead after being switched off at the wall.”
The result: lights stuck at whatever state they woke up in. On a cold winter morning, that meant blazing 6500K white light before I had even had a coffee.
The Fix: Trigger, Wait, Reset, Apply
The solution is an automation that fires the moment either lounge bulb transitions away from `unavailable`. It then:
1. Waits a few seconds for the bulb to finish initialising on the network
2. Turns off sleep mode (more on that in a moment)
3. Clears the manual control flag
4. Re-applies the current Adaptive Lighting settings
Here is the automation:
alias: Lounge Bulbs - Restore Adaptive Lighting on Power On
description: >
When lounge bulbs return from unavailable, clear manual
control flags and reapply adaptive lighting settings.
trigger:
- platform: state
entity_id:
- light.lounge_1
- light.lounge_2
from: unavailable
mode: parallel
max: 2
action:
- delay:
seconds: 5
- action: switch.turn_off
target:
entity_id: switch.adaptive_lighting_sleep_mode_lounge
- action: adaptive_lighting.set_manual_control
data:
entity_id: switch.adaptive_lighting_lounge
lights:
- light.lounge_1
- light.lounge_2
manual_control: false
- action: adaptive_lighting.apply
data:
entity_id: switch.adaptive_lighting_lounge
lights:
- light.lounge_1
- light.lounge_2
turn_on_lights: true
That 5-second delay matters. Without it, the bulb hasn’t finished announcing itself on the network and the service call either fails silently or applies settings to a device that isn’t quite ready yet. Five seconds is enough buffer in practice — your mileage may vary depending on your hardware. The question would be whether you find shortening it works… sometimes for me it does, sometimes for me it doesn’t.
The Sleep Mode Trap
One morning I came downstairs to find the lounge at 1% brightness and 1000K — essentially a single candle in a dark room. Adaptive Lighting was running. The automation had fired. Everything looked correct in the logs.
The culprit was the sleep mode switch.
Sleep mode overrides the normal Adaptive Lighting curve entirely. It doesn’t matter what time of day it is — if sleep mode is on, you get minimum brightness and a very warm colour temperature. Designed for middle-of-the-night use, it is genuinely useful. But it had been accidentally left on from the weekend, and the power-restore automation was dutifully reapplying settings within that overridden state.
Adding `switch.turn_off` for the sleep mode entity — *before* the manual control reset — sorted it immediately. The ordering matters: clear sleep mode first, then tell Adaptive Lighting to take over again.
The Parallel Mode Problem
The original version of this automation used `mode: restart`. The thinking was that if both bulbs came on at almost the same time, they would be handled sequentially and nothing would overlap.
In practice, it made things worse.
If `light.lounge_1` triggered at T=0 and `light.lounge_2` came up at T=3 seconds, the `restart` mode reset the entire 5-second delay timer from scratch. So the settings would not apply until T=8 seconds after the first bulb, sometimes up to 10 seconds in total before both lights looked right.
Switching to `mode: parallel` with `max: 2` lets each trigger run its own independent 5-second wait. Both bulbs get handled almost simultaneously, and the whole process completes in under 6 seconds from power-on. A small change with a noticeable difference first thing in the morning.
The End Result
The lounge now wakes up properly every morning. Warm, appropriate lighting from the moment the Kajplats switch goes on — no intervention required, no ghost dentist office energy.
It took an embarrassingly long time to nail down, mostly because the failures were silent and the logs showed everything as successful. The lesson, as ever with Home Assistant: always check whether Adaptive Lighting sleep mode is involved before spending an hour questioning your YAML indentation.
If your smart bulbs are on physical switches and Adaptive Lighting keeps abandoning them, this is the fix. Swap out the entity names for your own setup and you should be good to go.