Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to set adaptive 'ramp' up and down times #218

Closed
lazyboy0172 opened this issue Nov 9, 2021 · 27 comments · Fixed by #87 · May be fixed by #535
Closed

Ability to set adaptive 'ramp' up and down times #218

lazyboy0172 opened this issue Nov 9, 2021 · 27 comments · Fixed by #87 · May be fixed by #535

Comments

@lazyboy0172
Copy link

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.

@Pe-MaKer
Copy link

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.

@broyuken
Copy link

I’m hoping this gets implemented into v2

@Kaot93
Copy link

Kaot93 commented Nov 20, 2022

I would love this too. Are there plans to do this?

@lazyboy0172
Copy link
Author

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?

@th3w1zard1
Copy link
Collaborator

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.

@th3w1zard1
Copy link
Collaborator

Forgive me if I'm misunderstanding OP

@lazyboy0172
Copy link
Author

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.

@th3w1zard1
Copy link
Collaborator

This is exactly what #87 does

Issues/Features TODO List automation moved this from In Queue to Done Apr 3, 2023
@Kaot93
Copy link

Kaot93 commented Apr 3, 2023

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.

@th3w1zard1
Copy link
Collaborator

th3w1zard1 commented Apr 3, 2023

@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.

@th3w1zard1
Copy link
Collaborator

th3w1zard1 commented Apr 3, 2023

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.

@Kaot93
Copy link

Kaot93 commented Apr 3, 2023

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

@th3w1zard1
Copy link
Collaborator

th3w1zard1 commented Apr 4, 2023

@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.

@th3w1zard1 th3w1zard1 reopened this Apr 4, 2023
Issues/Features TODO List automation moved this from Done to In progress Apr 4, 2023
@th3w1zard1 th3w1zard1 linked a pull request Apr 4, 2023 that will close this issue
@th3w1zard1
Copy link
Collaborator

@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.

@Kaot93
Copy link

Kaot93 commented Apr 7, 2023

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.

@th3w1zard1
Copy link
Collaborator

th3w1zard1 commented Apr 8, 2023

@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).

@Kaot93
Copy link

Kaot93 commented Apr 8, 2023

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 :)

@keshavdv
Copy link

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.

@Kaot93
Copy link

Kaot93 commented Jun 23, 2023

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:
Screenshot_20230623-084552

@backcountrymountains
Copy link

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.

@TheWanderer1983
Copy link

@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.

@backcountrymountains
Copy link

@TheWanderer1983 I think I may have made a solution to your issue with my fork referenced in #437, comment.

@basnijholt
Copy link
Owner

Hi folks, I have implemented this feature request to change brightness adaption shapes in #699 🎉

That 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":

  • During sunset the brightness will start adapting constantly from max_brightness at time=sunset_time - brightness_mode_time_light to min_brightness at time=sunset_time + brightness_mode_time_dark.
  • During sunrise the brightness will start adapting constantly from 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:

  • During sunset the brightness will start adapting from 95% of the max_brightness at time=sunset_time - brightness_mode_time_light to 5% of the min_brightness at time=sunset_time + brightness_mode_time_dark.
  • During sunrise the brightness will start adapting from 5% of the min_brightness at time=sunrise_time - brightness_mode_time_dark to 95% of the max_brightness at time=sunrise_time + brightness_mode_time_light.

It would be awesome to get some feedback! 💡

@basnijholt
Copy link
Owner

basnijholt commented Aug 4, 2023

Some more examples:
Notice the values of brightness_mode_time_light and brightness_mode_time_dark in the text box.
image
image
image

@basnijholt
Copy link
Owner

Please try out version 1.19.0 beta 1 🎉 🚀

Issues/Features TODO List automation moved this from In progress to Done Aug 5, 2023
@Kaot93
Copy link

Kaot93 commented Aug 5, 2023

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!

@basnijholt
Copy link
Owner

Check out this new webapp to visualize the parameters https://basnijholt.github.io/adaptive-lighting/

adaptive-lighting

adaptive-lighting.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment