This is how I turn my lights on so they go straight to the correct values:
- service: light.turn_on
data_template:
entity_id: light.passage_lights
brightness_pct: >-
{{ state_attr('switch.adaptive_lighting_passage', 'brightness_pct') |
int(100) }}
rgb_color: "{{ state_attr('switch.adaptive_lighting_passage', 'rgb_color') }}"
Thanks, Iāll give it a go!
Version 1.15.0 released yesterday adapts service calls directly, so lights should now turn on with the correct brightness and the adaptive_lighting.apply workaround should no longer be necessary. Itās currently restricted to service calls that target a single entity though, like in the previous example by @sparkydave.
Hi Guys,
first of all - Im using your component quite a while and im more than happy with it! But there is one thing that is really annoyingā¦ So we are using momentary switches to turn our lights on. I press once - the light turns on and adaptive lightning does the job as expected. After pressing the switch again (to turn the light off) the light stays on. I need to press again to then finally turn the light off. I have this issue with every switch that is connected to adaptive lightning. Any ideas?
BR
AndrƩ
Excellent, thanks!
I started to observe this as well in my set up. I believe this is now fixed in version 1.16.
There are still rare edge cases where you turn the light off at the exact moment when adaptive lighting does an update at the regular interval.
Iāve been happily using Adaptive Lighting with many wifi and a few zigbee bulbs. All working reliably and effectively of late.
But my first matter/thread bulb - Nanoleaf Essentials A60 - behaves oddly (only when included in Adaptive Lighting config) when using the on/off control in the HA dashboard. Note that automations and a zigbee switch turn it on and off as expected.
The first on command works as expected. Light switches on at expected intensity. Light then switches off as expected. But the next on command causes the bulb to come on only at what I estimate is 1% - even though, in the HA dashboard, itās shown as being on at whatever the expected intensity is.
Further commands cause it to cycle through correct and very dim intensity.
Disconnecting from Adaptive Lightint config immediately fixes the problem.
I understand that Matter is still in beta in HAā¦ maybe updates will solve the problemā¦ and Iām happy to be advised that I should have posted this in a matter related thread.
I wonder if thereās something Iām missing here. My lights still come on with the previous brightness and colour initially before transitioning to the current Adaptive Brightness settings. Now running 1.17.0.
Iām using Hue lights via the Hue bridge added to HA, and usually using Hue dimmers to turn the lights on but I see the same behaviour turning the lights on via the HA app.
Is there something I might be missing, or anything which might be interfering?
It only works when the light.turn_on service call addresses a single physical light that is managed by a single AL instance. In all other cases, the previous handling is applied (e.g. if a group of lights is addressed).
Ah I see. I know you mentioned a single entity, but in HA terms my light group is an entity, so I misunderstood.
Is there a reason for it being restricted to a single physical light? Otherwise, is there either of the two previously mentioned workarounds which youād suggest as being preferable?
Basically, I want to press a button on a physical switch managed by HA and have several physical lamps turn on and go immediately to AL settings rather than starting from the previous setting, so Iām searching for the best way to accomplish that. Iām starting to wonder if itād be easier just to tell them to come on to minimum brightness, that way at least I avoid the nastiness of turning them on late at night and having them blind me with daytime settings
before dimming themselves down to evening ones.
Complexity 
Supporting multiple/group entities is much more complicated, so this first iteration of this feature just supports a single one.
They should both result in the exact same experience, i.e., lights turning on directly with the correct settings. So this is just a matter of personal taste.
If you donāt mind the adaptation delay, thatās certainly a reasonable and generic approach!
Replying to myself and wondering if anyone else is having more success using a matter bulb with adaptive lighting. There have been updates to the Matter integration and Adaptive Lighting since I first posted, but no change in the described behaviour.
Ah great, thanks. Appreciate your work on this feature regardless 
Iāve settled for now on calling āAdaptive Lighting: applyā, and then configuring the initial transition in the settings to 0, which seems to work well.
As you said, setting them to turn on to minimum brightness means an adaptation delay, and also means if the switch is pressed again, they will go to manual control and minimum brightness, which wasnāt playing nicely with my switch being set up to turn on some lights with a short press and the remaining lights with a long press.
I have made an initial implementation that performs the intercepts for multiple lights (and light groups) here Implement call intercept for multiple lights by basnijholt Ā· Pull Request #679 Ā· basnijholt/adaptive-lighting Ā· GitHub 
It works for me but I still need to properly test it with integration tests.
Can someone explain transition_until_sleep? Does it only appy to color as alluded to in the documentation or is it supposed to also affect brightness. Iām also trying to fathom why I would even use it?
@dbrunt, instead of transitioning only until min_color_temp at sunset, it will continue adapting until sleep_color_temp or sleep_rgb_color until midnight.
Okay, so color only, not brightness, and if transition_until_sleep is true, transition to sleep_color_temp/sleep_rgb_color until midnight. Is that 00:00:00 or solar_midnight??
Another question: AL transitions from max_color_temp during the day reaching min_color_temp at the time of sunset - Is that sunsetStart, sunsetEnd, or a midpoint? I know itās only a matter of a few minutes but Iām curious!
Thanks!
edit: Please try out version 1.19.0 beta 1 
I have just merged a new feature in feat: add different brightness ramping mechanisms by basnijholt Ā· Pull Request #699 Ā· basnijholt/adaptive-lighting Ā· GitHub
This PR allows setting different brightness_modes which determine how the brightness changes around sunrise and sunset. Here brightness_mode can be either "default" (current behavior), "linear", or "tanh". Additionally, when not using "default", you can set brightness_mode_time_dark and brightness_mode_time_light.
with brightness_mode: "linear":
max_brightness at time=sunset_time - brightness_mode_time_light to min_brightness at time=sunset_time + brightness_mode_time_dark.min_brightness at time=sunrise_time - brightness_mode_time_dark to max_brightness at time=sunrise_time + brightness_mode_time_light.with brightness_mode: "tanh" it uses the smooth shape of a hyperbolic tangent function:
max_brightness at time=sunset_time - brightness_mode_time_light to 5% of the min_brightness at time=sunset_time + brightness_mode_time_dark.min_brightness at time=sunrise_time - brightness_mode_time_dark to 95% of the max_brightness at time=sunrise_time + brightness_mode_time_light.Some more examples:
Notice the values of brightness_mode_time_light and brightness_mode_time_dark in the text box.
Awesome new options!
One thing I donāt quite understand from reading the PR/readme, is whats the difference between default, linear, and tanh. I see both examples for linear and tanh, but itās not clear what the third/current/default option does in comparison?
That option is directly calculated from the sun position instead of being able to manually set options.
But I understand the confusion, I will make some plots for that too.
