💡 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

[sparkydave (🇦🇺 Dave)]

You can create an Adaptive Lighting integration for as many or as few lights as you want. Create multiple AL integrations and include different lights in each. If you create one for the Nanoleave you can then turn off the ‘adapt color’ switch for that light, so AL only changes the brightness

[Jonnvoll (Markus Eriksen)]

Thanks That was surprisingly easy. Why didn’t that occur to me

[jiredell]

Thanks so much for this, this is absolutely awesome!

Quick question (or feature request) is there a way to make the lights dim while they are off? I’m hoping to make them turn on at the desired brightness rather that starting bright then dimming immediately.

[Jonnvoll (Markus Eriksen)]

If you use an automation or script to turn them on, then you can use the current brightness from this to set the brightness when the light turns on. This is the service I use to set brightness and kelvin (color temeprature) when the lights are turned on.

      - service: light.turn_on
        data_template:
          entity_id: light.kjokken
          kelvin: "{{ state_attr('switch.adaptive_lighting_standard', 'color_temp_kelvin') | int }}"
          brightness_pct: "{{ state_attr('switch.adaptive_lighting_standard', 'brightness_pct') | int }}"
          transition: 3

[Brian_Mollegaard_Ped (Brian)]

I have a yeelight ceilien lamp, it does not allow very low light temperature and I would like to switch it off automatically in the late evening. I was thinking if you had a good idea to automate this? I think I’m looking for a cut off value somehow.

[krock]

I’d like to be able to disable ‘sleep mode’ if someone adjusts the brightness up when it is enabled. Is there a straightforward way to do this?

this is my configuration, however the sleep mode goes back on when enabled… any advise here?

Adjusting the brightness through the app sticks but no when manually adjusting with the wall switch.

adaptive_lighting:
- name: "House"
  lights:
    - light.basement_lights
    - light.livingroom
    - light.kitchen_table_chandelier
    - light.bedroom_lights
    - light.upstairs_bathroom_main_lights
  take_over_control: true

[Nassau]

Has anyone found a solution that allows them to modify the brightness of light(s) while still allowing those lights to receive the periodic adaptive updates? I’d like to be able to dim my lounge lights when the TV is running, but also have those lights continue to follow the temperature and brightness adjustments while maintaining the relative difference in brightness.

There are a few partial solutions that would be okay in practice, but aren’t ideal:

• Just letting the lounge lights not follow the adaptive updates while dimmed, since they would resume following them once undimmed and the change wouldn’t be particularly noticeable if it’s being applied at the same time the brightness goes back to normal.
• Creating an additional adaptive light configuration at the lowered brightness. This is fine if I want to use a small number of preset brightness but doesn’t have much flexibility for finer control
• Create an input number that represents the “brightness modifier”, and a template light that multiplies the adaptive brightness value with the brightness modifier to produce the real brightness, and otherwise functions identically to the base lights. The only flaw I can see here is that it would be a considerable headache in creating and maintaining these entries for multiple lights.

Hopefully there’s a more elegant solution I’m missing!

@krock Could you just use an automation that disables sleep mode any time light.turn_on is fired? A brightness change would be sent using the turn_on service. This would pick up manual on/off commands as well as brightness changes but that may be desirable?

[PizzaPino (Oliver)]

you can disable the brightness switch while the tv is running and have it only update the temperature.

[Nassau]

Ah, I hadn’t realised that disabling the individual temp/brightness switches would also prevent manual control from being enabled when those parameters are adjusted manually. Cool! This would definitely give me an option for the TV scenario.

Another idea I thought would be handy would be to set up the template light/input number described in my last post (regardless of headache), so that I could adjust the brightness on the fly and also have adaptive brightness changes continue to be applied relative to the adjusted brightness. Really having a hard time figuring this out without creating some kind of loop where the brightness gets into a kind of loop.

[sparkydave (🇦🇺 Dave)]

I use this component with some downlights flashed with ESPhome. In a previous version of ESPhome they worked perfectly, then the color_interlock (between color and white) got broken. With the release of ESPhome 1.20.0 the color management has been modified yet again and the lights seem to behave a bit better but as good as the original version.

Unfortunately the issue is that they get turned on with a degree of white light as well as the color LED’s at night when really all we want is the RGB’s to give the appropriate color temp. Now, the brightness is getting turned so low the lights turn off.

I think there needs to be a way of setting the rgbw_color value rather than just rgb_color so the whites are turned off, but then not shut down the rgb LED’s quite so much.

They way I have these operating at the moment to try and disable the white LED’s is below, which does work, but as I said, the color LED’s are too dim late at night that they turn off completely.

      - service: light.turn_on
        data_template:
          entity_id: light.ensuite_lights
          brightness_pct: "{{ state_attr('switch.adaptive_lighting_ensuite', 'brightness_pct') | int }}"
          rgb_color: "{{ state_attr('switch.adaptive_lighting_ensuite', 'rgb_color') }}"
          white_value: 0

From what I read on Github there is a change in HA required to properly fix the broken color_interlock feature in the ESPhome light component. It may be a case of waiting for that fix before these work again… but I’m hoping there is a work-around.

[janhub]

Hello,

quick question: has anyone found a solution to make “pre-staging” work for philips hue lights? So that the lights are set to a value without turning on. I really really love components like adaptive lighting or circadian daylight…but I can’t get used to the fact that lights only change their values after being turned on…this will always result in a transition-effect that everybody notices…

As far as I know philips hue has changed their API recently…also “pre-staging” natively has been available for hue scenes for a long time, as scenes work without transitions…but I’m too little of a programmer to really understand what has to be done…

Thanks a lot guys!!

[krock]

It seems that I can disable the adaptive lighting by toggling the brightness in HA but not from the physical Lutron wall switch. Any suggestions?

[kreene1987 (Kevin Reene)]

Check out the adaptive_lighting.apply service call with the turn_lights_on setting disabled. I believe there is an example in the GH Wiki.

[kreene1987 (Kevin Reene)]

When you turn on/off a light it will be changed to the Adaptive Lighting Level. When you THEN change the level it will be set in a manual override state if you have that option enabled. It will then require being turned off and on again to return to adaptive state (or call apply service).

[krock]

Hi @kreene1987 - yeah, i think ‘detect_non_ha_changes: true’ is the ticket…but, not working.

(when I manually adjust brightness, it automatically adjusts back…)

any thoughts?

thanks!

adaptive_lighting:
- name: "House"
  lights:
    - light.basement_lights
    - light.livingroom
    - light.kitchen_table_chandelier
    - light.bedroom_lights
    - light.upstairs_bathroom_main_lights
  take_over_control: true
  detect_non_ha_changes: true

[kreene1987 (Kevin Reene)]

A few thoughts to check. I configure directly through the UI so I’m not 100% that your indentation/setup is proper. The light has to be ON already, then change by MORE than 10% to get set as manually controlled.

Whenever a light gets marked as “manually controlled”, an adaptive_lighting.manual_control event is fired, such that one can use this information in automations.

[krock]

thanks @kreene1987 - do I need to create a separate automation to turn on manual control? I thought that this happened automatically through the ‘adaptive lighting’ integration.

[kreene1987 (Kevin Reene)]

Nope it does it automatically. I was just suggesting to look for the event to make sure it’s working properly.

[krock]

OK - gotcha.

shrug - I think resolved the issue by deleting and re-installing the integration through HACS.
I can now change settings through the UI (for some reason, it would not let me before, just yaml)

[fluffymadness]

Awesome extension. Really appreciate the work.
Atm I’m using this for my cct dimmers on zigbee2mqtt for color correction, maybe it is helpful for someone.
I have to set a custom range from 2700k to 6500k (370-153mired) for the connected strips the dimmers however report a physical color range of (500-153). So the colors would be always off.This is a workaround to get correct color mapping going:

Custom Color Temperature Ranges for Zigbee Dimmers Example Config

A few weeks ago I got myself some milight zigbee cct dimmers. http://www.futlight.com/light/xqy/fut035z.html Nice stuff since they have 8000hz pwm rate just like the old non-zigbee models. I’m using zigbee2mqtt and these dimmers have a hardware range they advertise in their zigbee clusters from 153 to 500 mired, but since you can connect any kind of strips to this dimmer, e.g 2700k (370 mired) on the warm white side, the range will then be off For example when you set 500 mired on the homeas…