💡 Adaptive Lighting automatically adapts the brightness and color of your lights based on the sun's temperature but stops when you manually make a change

Yeah, I’m getting these too. Seems like something has broken in some recent updates. I’ve also noticed (I swear it didn’t happen before) that when turning on the lights, they’ll cycle through various colours etc. before arriving at their correct setting. I just want them to turn on straight to the correct brightness and colour temp for the current time of day. Think this sounds similar to the second point @Elenkhos just made.

Did you ever figure this out? :grinning: I have an Inovelli Blue Series smart switch controlling five Signify Lightify under cabinet LEDs. Adaptive Lighitng only seems to work on the under cabinet LEDs if I target and control the light group from HA. But if I use the Blue Series wall switch, it doesn’t apply Adaptive Lighting settings (at least not for color temperature). Is there a way to make Adaptive Lighting work whether I use the Inovelli Blue Series smart switch on the wall, or make a call to turn on the lights in HA?

It’s continued to be a bit of a pain in the butt, but I do have a decently well working solution now. I’m only using Z2M; when testing ZHA, I wasn’t happy with ZHA + Skyconnect performance, so I scrapped it before I got very far and went back to only relying on Z2M.

For all my lights where Adaptive Lighting is configured, I’m using this blueprint that I wrote: ha_custom/blueprints/light_switch_al_controller_z2m.yaml at main · xenokira/ha_custom (github.com)

Basically, the automations created from this blueprint enable adaptive lighting when up_single (bound lights come on) is in a switch payload and disable adaptive lighting when down_single (off), up_double (dim up to full), up_held (dim up), down_double (dim down to lowest), and down_held (dim down) are in the switch payload. The blueprint does more too: conditionally enables AL sleep, color mode, allows for control of a “secondary” light via the config button, etc. There’s also support for “Direct Control” of the primary lights; this is for cases where the switch is not bound to the bulbs and just has HA call the light.turn_on and light.turn_off services. My use case was pretty narrow for the direct control option, so I haven’t tested it much (and I know dimming behavior is funky when trying to dim from the switch). I just refactored it and have found a couple small issues that I worked through, but there could be more tweaks in the shorter-term.

Note, take_over_control should be disabled. When enabled, I see issues where sometimes AL goes to manual_control while the lights are still turning on. I think this is because the bound switch is controlling the ramping of the lights (which I have set to 500ms on the switch).

As far as the experience goes:
Tapping ‘up’ on the switch immediately turns on the Zigbee bound lights, which I have come on at the previous brightness / temperature settings. The automation is simultaneously triggered by the up_single event, which immediately activates Adaptive Lighting and the adjusts the lights accordingly. It’s not perfect as lights the lights immediately adjusting can feel a bit…awkward, but it’s been pretty reliable. What’s nice is that when it does hiccup, tapping ‘up’ on the switch again should re-apply AL.

I’m happy to share my VZM31-SN switch params, AL settings, etc. if they’d be helpful :slight_smile:

An I missing something, or is everybody apparently fine with running their lights 24/7? Why can’t I set a sleep brightness of 0?

I could be wrong but I’ve never thought of sleep mode being for while you’re sleeping as much as for a nightlight, or when you’re tucking in. Although perhaps some people prefer to leave some lights in the house turned on and want a specific brightness

I just turn mine off when I’m sleeping.

No, my lights only come on if the lux level in that particular room is low enough and there is motion. None of my lights stay on all night and they only come on during the day if it’s dark.


I’ve been on AL forever but I’m in the process of transitioning to SK6812’s. For daytime they seem to work fine and coming in and out of sleep mode they perform beautifully. But in sleep mode, they turn red regardless of the color temp set in AL. Looking in the dev tools, when AL sends the Color temp to 3000 command, something gets lost in translation and only the red arrives (255). In looking at the integration, it seems like white channel is not supported in sleep mode. It’s either RGB or color temp. But when I send CT, sleep mode isn’t handling it as gracefully as day mode and just turns the lights red.

Does anybody else have SK6812s with a white channel and have overcome this in sleep mode? Really wanting to understand if its something I’m doing wrong or if there’s a feature gap that I’ve never noticed till now. My current LEDs have a white channel and they allow for sleep mode CT to work properly.