Open bkuhns opened 3 years ago
The whole idea with the blueprint is that you configure your start and end points with the sliders and then when the light is turned on (either manually or automatically) the brightness is set to the calculated brightness based on your settings and the sun's elevation.
It is possible to implement a checkbox that the current brightness shall be used, but if the lights are only automatic i don't really see the use of it since you set the brightness with the start and stop values.
Our goals might be a little different but it seems so close. More often than not, I find myself setting the lights just a bit brighter near sunset to keep a mostly equal level of light in the house. I thought it'd be nice if HASS would just gradually brighten the lights as the sun sets, up to some max level. I started thinking about how to write that automation but searched for existing blueprints first and found yours. At first I thought it was exactly what I had in mind (in "reverse" mode).
Seems this blueprint would do exactly that if it used min(current, maximum)
for the brightness in "regular" mode, or max(current, minimum)
for "reverse" mode.
I guess if you don't see the utility, I could use your blueprint as a (very good) starting point.
I guess if you don't see the utility, I could use your blueprint as a (very good) starting point.
I'd be happy to receive a pull request where you added two check boxes to let the user choose if mix/max should be used instead of the current behaviour
I just made an automation from this blueprint and it ran for the first time last night. I'm using it in "reverse" mode, to make the lights gradually brighter as the sun sets to keep a more constant brightness in the house up until sunset. I was hoping this blueprint would start from either the minimum brightness setting, or the current brightness of the lights (whichever is higher). However, when the automation ran last night, the lights all jumped to the minimum brightness (1%).
I haven't looked into the implementation of the blueprint, but would it be feasible to implement it such that the automation doesn't dim the lights lower than their current brightness when the automation runs in "reverse" mode? I think it would also make sense when running normally that the automation not make the lights brighter than they are currently set to at the beginning of the automation (maybe it does that already, I've only used reverse mode).
I think with this one issue out of the way, this blueprint would work perfectly for me!