adaptive-lighting
adaptive-lighting copied to clipboard
Ability to set adaptive 'ramp' up and down times
I'm new to AL but my understanding is that essentially my lighting color/brightness would go from Max to Min back to Max between sunset and sunrise. For example, if sunset is 5:30pm and sunrise is 7:30am, lighting color/brightness will begin lowering from 'max' at ~5:30pm, hit the 'min' value ~12:30am and immediately begin climbing again to reach 'max' again at 7:30am.
I would suggest an option in the configuration to set a 'ramp' time, so that while the ramp down still starts at sunset and ramp up ends at sunrise, the time it takes to get from max-min or min-max is no longer half the night but instead whatever hh:mm:ss that the user configures.
For example, if I set to 03:00:00 and use my sunset/sunrise times above, instead of slowly going from max to min from 5:30pm to 12:30am, it would go from max to min from 5:30pm to 8:30pm, hold at min until 4:30am, then ramp from min to max from 4:30am to 7:30am when the sun rises. This essentially just means we hit that 'min' value much earlier in the night and hold there for a while rather than just barely hit min values for a minute each evening while we're asleep.
The only problem would be what to do when the user sets an impossible ramp, e.g. sunset to sunrise is 8 hours today because it's summer but user has ramp set to 05:00:00 still from winter. do we A) respect the ramp down then jump up immediately to ramp up on time? B) respect the ramp 'rate' but after 4 hours start ramping up (i.e. AL never reaches 'min' values because before the full ramp down can complete the ramp up begins)? C) ignore the ramp config entirely for that evening and do the 'normal' behavior of max to min to max over the 8 hour 'night' period?.... Personally I would vote (B) but the point is that while this scenario complicates things it is a solvable problem.
I totally agree with this. Itβs mandatory to have any option to customize the curves for color temperature and brightness (e.g. to a full sinus curve). Ideally this component would also take the different twilight phases into consideration.
Iβm hoping this gets implemented into v2
I would love this too. Are there plans to do this?
I've seen this project get a lot of dev love recently so I wanted to chime in on this again. I don't believe anything like this has been implemented, but it was tagged with related-to-v1. Is this something being considered for v2, or is it possible to consider for v1 or v2?
This was already implemented in #87, as to why it's never made it into the main code your guess is as good as mine.
Forgive me if I'm misunderstanding OP
yes, sorry I believe misunderstanding. The OP would be requesting a config parameter to set how quickly the light/temp goes from max to min.
essentially by default, it goes from max to min back to max from sunset to sunrise. e.g. if sunset is 7pm and sunrise is 7am, and max/min is 100%/1%, then what will happen is: 6:59pm - light is 100% 7:01pm - light is ~99% ~ 12:59am - light is ~2% 1:00am - light is 1% 1:01am - light is ~2% ~ 6:59am - light is ~99% 7:00am - light is 100%
if the user wants 'night' to be 1%, it's only like that for 1 minute in the middle of the night. If they set the sleep brightness to 1% and use automations to trigger that at say 10pm, then that means: 6:59pm - light is 100% 7:01pm - light is ~99% ~ 9:59pm - light is ~51% 10:00pm - light is 1%
because the light is still 'ramping down' as over the course of the full night, but basically just overriden at 10pm via automation to jump to 1%. This request would be to set the 'ramp rate' via parameter. So, for example, if the user set that ramp to 03:00:00 then we'd see: 6:59pm - light is 100% 7:01pm - light is ~99% ~ 8:30pm - light is ~50% ~ 9:59pm - light is ~2% 10:00pm - light is 1%
so this time we saw a linear drop from 7pm at sunset for 3 hours until it got down to the minimum value. It would then hold at that minimum value until 03:00:00 pre sunrise, where it would start to ramp up: 4:00am - light is 1% 4:01am - light is ~2% ~ 5:30am - light is ~50% ~ 6:59am - light is ~99% 7:00am - light is 100%
the reason for the request is that we requestors enjoy the dimming function and getting our minds ready for bed, but recognize that we get ready for bed much earlier than the bulbs would actually hit their 'night' values. and implementing sleep mode just makes an immediate jump from whatever % the light is currently to that sleep %, which can be a significant drop.
Please let me know if I misunderstand the functionality though. It's been a year or so since I last used this daily. I've kept it installed and check release notes every time there is an update but haven't turned it back on since I hadn't seen anything like this in the notes. But I have noticed a lot of development lately so I thought I'd check in on my old request.
This is exactly what #87 does
With the newest update installed I don't get quite where #87 is the same as this request.
The one would be the ability to set a timespan, in which the adaptation is active, else is minimum/maximum. The other continues to adapt the colour continuously, even though sleep mode is activated.
Is this in very short terms correct?
Or is the ramp time talked about in this request just not implemented yet?
I love the integration nonetheless and use it since I got HA running in my home.
@Kaot93 I see how pr #87 is a bit different than this request but I believe all the necessary configuration options are already implemented for the user to do this themselves. Utilizing the sunset_time
and sunrise_time
parameters, and adaptive-lighting.change_switch_settings
you can even automate this.
I'm not 100% sure though so I'd love to hear back from anyone attempting this.
This paragraph from OP makes me think it's exactly what #87 allows.
For example, if I set to 03:00:00 and use my sunset/sunrise times above, instead of slowly going from max to min from 5:30pm to 12:30am, it would go from max to min from 5:30pm to 8:30pm, hold at min until 4:30am, then ramp from min to max from 4:30am to 7:30am when the sun rises. This essentially just means we hit that 'min' value much earlier in the night and hold there for a while rather than just barely hit min values for a minute each evening while we're asleep.
You can run an automation on sunrise/sunset events that call change_switch_settings
with the new sunrise/sunset times to use to keep it going.
Most of what we've been doing in the project lately is allowing for the user to code their own customized experience through Home Assistant rather than specifically adding the exact requested features. If we did so, the number of config options would just become overwhelming.
Well okay that makes sense to me.
I will try to take a look in an automation that fits me when I find the time..
I think I Will get back here when I got to try it.
Thanks for the explanation
@Kaot93 No problem! Please let me know if this works.
I've reopened this issue as I think there's more here than the ramping. It may well be the case that this is impossible with automations (see #105) and I'd like to be able to confirm this.
@Kaot93 if for some reason your automations have an error about the calculation of noon/midnight, I've fixed that in #535.
If someone could test that'd be great.
My current automation is the following:
alias: "Adaptive lighting: brightness control"
description: ""
trigger:
- platform: sun
event: sunrise
offset: "-04:00:00"
id: Sunrise
- platform: sun
event: sunset
offset: "-05:00:00"
id: Sunset
condition: []
action:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))+9000) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))-9000) |
timestamp_custom('%H:%M:%S') }}
- choose:
- conditions:
- condition: trigger
id: Sunrise
sequence:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))+10800) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))-10800) |
timestamp_custom('%H:%M:%S') }}
- conditions:
- condition: trigger
id: Sunset
sequence:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))+10800) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))-3600) |
timestamp_custom('%H:%M:%S') }}
mode: single
But this works only with lights, which colour isn't adapted in my opinion.
It would still be cool to be able to control two offsets. First colour adaptation, second brightness adaptation.
@Kaot93 That automation looks beautiful!
If you'd like the color and brightness to not be synced, you need to define your light in two separate configs. One config for brightness with the adapt_color
switch off, and one config for color with the adapt_brightness
switch off. Then you call change_switch_settings
on the switch controlling brightness (or color if that's what your going for).
Thanks for the flowers!
Also, I didn't have this idea of making two instances of AL for one light. This is brilliant!
Well I didn't see all the abilities this integration gives! Thank you again :)
Even with the automated updates to sunrise_time and sunset_time, does this ever cause the lights to remain at their minimum brightness for more than a brief moment in the night? In the brightness graph from the readme, the lights stay at 100% throughout the day, but only hit their minimum for a few minutes in the middle of the night. I think the ask here is to end up with a way to get the lights to dim down to their minimum sooner and stay there for most of the night.
Try it with an automation like this:
alias: "Adaptive lighting: brightness control"
description: ""
trigger:
- platform: sun
event: sunrise
offset: "-04:00:00"
id: Sunrise
- platform: sun
event: sunset
offset: "-05:00:00"
id: Sunset
- platform: sun
event: sunset
offset: "01:30:00"
id: Sleep_on
- platform: sun
event: sunrise
id: Sleep_off
condition: []
action:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))+9000) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))-9000) |
timestamp_custom('%H:%M:%S') }}
enabled: false
- choose:
- conditions:
- condition: trigger
id: Sunrise
sequence:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))+3*3600) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))-3*3600) |
timestamp_custom('%H:%M:%S') }}
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_flur
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))+10800) |
timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_rising'))-10800) |
timestamp_custom('%H:%M:%S') }}
- conditions:
- condition: trigger
id: Sunset
sequence:
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_kuche
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))+5*3600)
| timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))-2*3600)
| timestamp_custom('%H:%M:%S') }}
- service: adaptive_lighting.change_switch_settings
data:
use_defaults: current
entity_id: switch.adaptive_lighting_flur
sunrise_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))+5*3600)
| timestamp_custom('%H:%M:%S') }}
sunset_time: >-
{{ (as_timestamp(state_attr('sun.sun', 'next_setting'))-2*3600)
| timestamp_custom('%H:%M:%S') }}
- conditions:
- condition: trigger
id: Sleep_on
sequence:
- service: switch.turn_on
data: {}
target:
entity_id:
- switch.adaptive_lighting_sleep_mode_kuche
- switch.adaptive_lighting_sleep_mode_flur
- conditions:
- condition: trigger
id: Sleep_off
sequence:
- service: switch.turn_off
data: {}
target:
entity_id:
- switch.adaptive_lighting_sleep_mode_kuche
- switch.adaptive_lighting_sleep_mode_flur
mode: single
It gives me following brightness values:
I modified switch.py
to use a wake_time
and a sleep_time
I recognize not wanting to make an inordinate amount of changes to the AL component and allow people to make their own automations to modify the components' behavior, but I think this change is worth considering.
Also, why does AL start increasing brightness at midnight? Isn't it more in keeping with the circadian cycle to keep lights dim from the end of evening twilight to the beginning of morning twilight? It just seems that if there is no sunlight at all, then the brightness of the lights should be at their lowest.
@Kaot93
Thanks for the automation script. How would you change that automation script above to include temperature to follow the same as the brightness? That is, after waking from sleep for sunrise it ramps up temperature to max_color_temp. Then staying at max_color_temp until the start of ramp down like the kitchen brightness graph above.
@TheWanderer1983 I think I may have made a solution to your issue with my fork referenced in #437, comment.
Hi folks, I have implemented this feature request to change brightness adaption shapes in https://github.com/basnijholt/adaptive-lighting/pull/699 π
That PR allows setting different brightness_mode
s 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"
:
- During sunset the brightness will start adapting constantly from
max_brightness
attime=sunset_time - brightness_mode_time_light
tomin_brightness
attime=sunset_time + brightness_mode_time_dark
. - During sunrise the brightness will start adapting constantly from
min_brightness
attime=sunrise_time - brightness_mode_time_dark
tomax_brightness
attime=sunrise_time + brightness_mode_time_light
.
with brightness_mode: "tanh"
it uses the smooth shape of a hyperbolic tangent function:
- During sunset the brightness will start adapting from 95% of the
max_brightness
attime=sunset_time - brightness_mode_time_light
to 5% of themin_brightness
attime=sunset_time + brightness_mode_time_dark
. - During sunrise the brightness will start adapting from 5% of the
min_brightness
attime=sunrise_time - brightness_mode_time_dark
to 95% of themax_brightness
attime=sunrise_time + brightness_mode_time_light
.
It would be awesome to get some feedback! π‘
Some more examples:
Notice the values of brightness_mode_time_light
and brightness_mode_time_dark
in the text box.
Please try out version 1.19.0 beta 1 :tada: π
I didn't test it yet because since you pointed out that I could do that with a pretty simple automation I'm pretty satisfied. But looking at the graphs it's exactly what was needed in this request I think.
You're doing great work, thank you very much for this!
Check out this new webapp to visualize the parameters https://basnijholt.github.io/adaptive-lighting/
https://github.com/basnijholt/adaptive-lighting/assets/6897215/68908f7d-fbf1-4991-98ce-3f2af6df996f