-
Notifications
You must be signed in to change notification settings - Fork 141
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
Comments
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). |
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. 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: 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: 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: 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 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.
You can run an automation on sunrise/sunset events that call 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 |
My current automation is the following:
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 |
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! |
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:
|
I modified 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. |
Thanks for the automation script. |
@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 #699 🎉 That PR allows setting different with
with
It would be awesome to get some feedback! 💡 |
Please try out version 1.19.0 beta 1 🎉 🚀 |
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/ adaptive-lighting.mp4 |
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.
The text was updated successfully, but these errors were encountered: