While looking at this YAML file, I got an idea: would it be possible to add the “color_temp” value as a variable, which comes from AL? This should solve it (in theory)?
You could try a template value based on the AL attribute color_temp_kelvin
Which component is - id: '1606727517975' listed under?
It likely may not accept a templated value…
I previously tried templating sunrise/sunset for AL but it failed. (that was in the main component setup)
Upon re-reading the above, I gather it’s in a scene so, you might be able to template the value…
color_temp: >
{{ state_attr('switch.xxxx', 'color_temp_kelvin') }}
(that’s off the top of my head! I’m not great with templates yet, lots of trial and error…)
{{ state_attr('switch.adaptive_lighting_bathroom', 'color_temp_kelvin') }} resolved to 10000 for me
and {{ state_attr('switch.adaptive_lighting_office', 'color_temp_kelvin') }} resolved to 3200 for me in dev tools…
Regarding id: ‘1606727517975’, it is indeed a scene.
If i understand you correctly, ‘color_temp_kelvin’ is the variable from AL for color temperature? That sounds very promising
I’ve done some additional research.
-
According to this url Scene with template values , templates cannot be used in scenes, but they can be used in scripts.
-
According to this url https://www.home-assistant.io/blog/2020/11/18/release-118/#native-types-support-for-templates , templating is easier since Home Assisant version 0.118.
-
According to this url https://www.home-assistant.io/blog/2020/07/22/release-113/ , a chooser can be used in scripts. That is what I actually already have in my existing setup, see my existing script below.
alias: Woonkamer daglicht
sequence:
- choose:
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
above: 140
sequence:
- scene: scene.woonkamer_uit
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
above: 50
below: 140
sequence:
- service: script.overdag
data: {}
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
below: 50
sequence:
- service: script.overdag_fel
data: {}
default: []
mode: single
When combining all these, it should work:
- Use the script above as the starting point
- Modify the script variables by adding two templates to it: one list containing the list of lights, one containing the color temperature value from AL as advised by you:
color_temp: >
{{ state_attr('switch.xxxx', 'color_temp_kelvin') }}
- Modify the “script choose sequences” by using a service: light.turn_on (instead of service: script.xxx), and add the following stuff to it:
- The template list of lights
- The template color_temp from AL
- The exact brightness value I like for each choose-option
I think this should work.
I’ve got it working. The theory turned out to be true.
- The only thing that needed to change, is to use the kelvin service data attribute instead of color_temp (which is using mireds), because AL is providing the value in Kelvin.
See below the solution. Hopefully this will help others as well.
Thanks for your help Daniel! Your advice about the color_temp_kelvin state attribute of AL was vital to get to this solution.
alias: Woonkamer daglicht v2
variables:
entities:
- light.woonkamer_subwoofer
- light.bureau
- light.woonkamer_rechts
- light.bank
- light.eettafel
- light.keukenblad
color_temp: >
{{ state_attr('switch.adaptive_lighting_woonkamer', 'color_temp_kelvin') }}
sequence:
- choose:
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
above: 140
sequence:
- scene: scene.woonkamer_uit
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
above: 50
below: 140
sequence:
- service: light.turn_on
data:
entity_id: "{{ entities }}"
kelvin: "{{ color_temp }}"
brightness: 80
- conditions:
- type: is_illuminance
condition: device
device_id: e6502f308a92b4ec13ea3605e16f45de
entity_id: sensor.lightlevel_19
domain: sensor
below: 50
sequence:
- service: light.turn_on
data:
entity_id: "{{ entities }}"
kelvin: "{{ color_temp }}"
brightness: 200
default: []
mode: single
1 Like
Congratulations! Glad I was able to help!
BTW, all 5 color attributes are in the switch.
(Developer Tools is your friend, especially States and Templates!)
Looks like you could have used color_temp_mired…
Awesome, thanks! I’ll keep that in mind for nex time 
Noob question:
Is there any way to have the adaptive lighting only affect the color temperature, not the brightness?
I couldn’t find my answer in the documentation.
There’s no way in the configuration setup but…since it creates “switches” for the areas’ brightness and color temp, I believe you would just need to turn the brightness switch off for the area(s) that you want brightness adjustment disabled for.
1 Like
Ah wow.
That is a funky way of controlling this integration, I had no idea.
I will give it a try, thanks for the tip!
Might seem funky but this way the entities are controllable via automations…
i did the same thing you did here with adding the color_temp values to the turn_on service call. But my lights only turn on every second time i call the script and i dont know why.
i have 2 scripts. one for turning on one for turning off.
so
- script.lights_on -> lights turn on as expected
- script.lights_off -> lights turn off as expected
- script.lights_on -> nothing (i can even see that the script runs in the logbook and no error in the logs)
- script.lights_on -> lights turn on as expected
this is so weird
…and removing color_temp from the script resolves your on-off-on-off testing?
yes, it only happens if Iam using the script with the templates for color temp and brightness. and it’s reproduce able with other scripts
I’ll put together something here to test…
Seeing images published on GitHub, I can see 100% simikarity with Circadian lighting component.
I would like to know if it is based on some research or just copied from mentioned component?
On first glance it’s obvious that both brightness and color comes from sinus function shifted by 180 degree. Ok, it’s correlated with sun position (percentage).
But in reality it doesn’t work this way.
Colour of the light doesn’t change during a day this way. In fact after morning it stays blue for a most of the day.
But brightness has even bigger issue: why it reaches about 50% of intensity durring deep night? For today (Europe/winter) it’'s 3hours before end of sunrise (5am, 8am).
I know it’s exactly the same behaviour as in Circadian component. But while the latter is community one and could contain various glitches, but in case of official occomponent it can do better.
I hope I’m wrong and there is some research existing which proves that circadian light must be intense even if the Sun lits another side of Earth.
1 Like
So, it’s a copy of functionality without attempt to make it proper real circadian lighting (tbh I don’t know what ‘adaptive’ does mean in the component name. It adapts to what?)
I suppose most people doesn’t care because at 3am they are sleeping. But for example having just born child, with need to wake up several times during a night… Yeah I know I can hack it on my own. I do that. But it doesn’t change the fact that current implementation is… suboptimal.
BTW another usecase just came to my mind. So popular sunrise effect, promoted by Philips Hue product line. This is what it could be used for if providing proper light changes.
I hope that one day devs will come to the same conclusion making this component 100% aligned with what it is intended to be. Otherwise it will stay popular only in group of users who are exciting about automatically changing lights, regardless it’s realistic or not.