My take on respecting manual changes

[haasn]

Currently, Kelvin simply disables itself when you make a manual change - as far as I can tell, indefinitely. I find this approach rather unsatisfying. Two ways I can think of that would improve the status quo:

1. When switching to a custom (non-kelvin) scene, after a configurable delay, re-enable the Kelvin scene. It's possible I could somehow solve this with other forms of home automation, although I can't find a way to have e.g. HomeKit react to a scene change like that.

2. When merely overriding the color temperature and/or brightness, the way I would imagine this working is by temporarily overriding the configured Kelvin schedule, but have the temporary override decay either over a configured period of time, or naturally based on the configured schedule.

As an illustration of the second point, consider a schedule which simply ramps up from 0% brightness at 0:00 to 100% brightness at 10:00. The curve will look something like this:

• 0:00: 0% brightness
• 1:00: 10% brightness
• 2:00: 20% brightness
• ...
• 10:00: 100% brightness

Temporary control nodes

Now say that, at 5:00, I manually change the brightness from 50% to 30%. One way to implement this would be to temporarily insert a control node reflecting the current settings at the current time. So the new ramp would be:

• 5:00: 30% brightness
• 6:00: 44% brightness
• 7:00: 58% brightness
• 8:00: 72% brightness
• 9:00: 86% brightness
• 10:00: 100% brightness

Based on the temporary control node at 5:00, and the existing control node at 10:00. The temporary control node is reset/removed when its period fully elapses, or a new temporary control node is set.

Decaying overlay

Another idea could be to have a configurable 'decay' time on manual changes, after which they would go back to the configured schedule. For example, say I set the decay time to 2 hours. With the same base schedule as before, I again change the brightness from 50% to 30% at 5:00. This will create a temporary overlay, starting with a strength of 1.0 and linearly interpolate down to 0.0 over the course of 2 hours.

• 5:00: 50% * 0.00 + 30% * 1.00 = 30% brightness
• 5:30: 55% * 0.25 + 30% * 0.75 = 36.25% brightness
• 6:00: 60% * 0.50 + 30% * 0.50 = 45% brightness
• 6:30: 65% * 0.75 + 30% * 0.25 = 56.25% brightness
• 7:00: 70% * 1.00 + 30% * 0.00 = 70% brightness

After the overlay duration has elapsed, the overlay is disabled.

Final thoughts

The pro of the temporary overlay is that your manual setting will definitely 'stick' for a predictable amount of time, no matter how crazy the underlying schedule. Conversely, the pro of the temporary control node is that the lights will react more dynamically to upcoming scheduled light transitions, even if you modified the 'current' light settings.

I'm not sure which approach I prefer. I will try implementing this functionality in any case, to see if one can be ruled out due to the complexity involved. But I would nonetheless be curious to hear some feedback on how this should be handled 'properly'.