Rethinking the core functionalities of Kelvin

[stefanwichmann]

In the light of the recent discussions in #23, #24 and #25 I would like to start a conversation about the core functionalities of Kelvin.

My goal for Kelvin is to enhance your life at home by seamlessly controlling your lights based on natural and artificial schedules. It should be able to combine dynamic sunrise and sunset times with a fixed daily schedule of early hour work or "Netflix and chill" at night.

While working on Kelvin for close to a year now I realized that this combination doesn't always work as expected and confuses users. So I think it's time to rethink the core mechanics of Kelvin to make them more precise, easier to understand and yet simpler to configure.

Examples:

Following are examples of things people expect Kelvin to do well without big hassles:

1. I use early mornings to get personal things done and to start the day productive. For this I want to have an artificial daylight at 07:00. In the summertime this might be after sunrise (04:55), during the winter before sunrise (08:36).
2. In the evening around 22:00 I want to have warmer light at lower brightness to prepare for bedtime. I summer this may lay before sunset, during the winter it lays definitely after sunset times.
3. My kids take a nap every day between 12:30 and 14:00 and I want to turn down the brightness in their bedroom during their sleep.

Current state:

Let's have a look at the current mechanics in Kelvin to see how it tries to match these example demands.

Kelvin separates the 24h of a day into three intervals: before sunrise, daytime and after sunset. "Before sunrise" begins at 00:00 and "after sunset" ends on 23:59. The other interval borders are dependent on the current and local sunrise and sunset times.

Custom settings are configured as timestamps and Kelvin will slowly transition to these settings in time. For an explicit time range (with start and end) you have to create two configuration entries.

Custom settings during daytime (between sunrise and sunset) are completely ignored. The assumption being that the daylight does not interfere with your schedule anyway. So example 3 isn't supported at all.

Furthermore if a custom setting falls into the daytime interval (see example 1 and 2) it will be ignored as well. If in doubt, the sunrise and sunset configuration wins.

This leaves us with the intervals before sunrise and after sunset for which a custom settings is fully supported right now.

Problems:

There are several problems with the current implementation that make Kelvin difficult to understand:

• Not all valid use cases are supported.
• Kelvin might ignore a custom settings based on sunrise/sunset times.
• Kelvin is in constant transition which makes the current state less predictable.

Proposal:

• We allow the user to express his custom settings as intervals with a start and end times for the whole day (00:00 - 23:59).
• The user can specify any number of intervals as long as they don't overlap per schedule.
• These custom intervals will always be respected and prioritized over any other setting (like sunrise and sunset). If the user wants to have a bright working light during the morning hours it should not matter if the sun is up or not. Same goes for the nap example.
• We introduce three default intervals:
  • 00:00 - dawn
  • sunrise - sunset
  • sunset - 23:59
• During intervals the light state remains stable (as in the current daylight interval).
• The custom intervals punch holes into the default intervals (or replace them if they are long).
• Kelvin will insert transitions between all intervals.

With these mechanism we could combine sane defaults with the flexibility of fixed schedules:

• If the user doesn't change the configuration at all the lights will follow the natural light outside with local sunrise and sunset times.
• If the user needs a custom schedule Kelvin will respect these times and transition around it.
• We keep the required configuration to a minimum.

For additional clarification and explanation I made some graphs how Kelvin would react in the example scenarios. They show the kelvin value for every hour of the day.

Natural schedule

Early Work (Example 1)

Nap (Example 3)

Thoughts? Any feedback is appreciated!

[FezVrasta]

Since we are here, any plan to move this to Home Assistant? It would be dope. Currently HASS has only one "Flux" component but it's not complete as Kelvin.

[stefanwichmann]

Nope, not planned any time soon. Sorry.
Let's try to keep this on topic please.

[lignumaqua]

I fully support this proposal. I'd like to have CCT changes between sunrise and sunset.

[Abushawish]

I really like the proposal, especially because now it seems like Kelvin begins dimming the light starting at sunset until a scheduled evening time, correct? But for me, I'd prefer it to be dimmed BY sunset time (or even earlier).

[stefanwichmann]

Hi Moe,

thanks for the feedback. The current behaviour of Kelvin works as you described. The idea is to adapt this to the natural sunrise/sunset which is not a fixed point in time but a timespan. So once the sunset begins, Kelvin will begin to dim as well. By the time the sun gone under Kelvin will have reached the configured target state.

Long story short: I belive Kelvin will behave as you expect it to work

[LiSongMWO]

After reading the proposal I think that it seems a bit confusing to have overlaid schedules and I feel it doesn't allow the degree of customisation that users will expect.

How about having the schedule just be a list of {time, colourTemperature, brightness} tuples where time is either a daytime or a specific keyword such as: dawn, sunrise, sunset, dusk. Kelvin interpolates between these and the crossover from 23:59 to 00:00 is interpolated from schedule[n-1] to schedule[0] to get a continuous night schedule too.

The sane default could be something like this:

"schedules": {
    ... schedule settings...
    "schedule": [
        { "time":"dawn", "colourTemperature": 2500, "brightness": 50 }
        { "time":"sunrise", "colourTemperature": 6500, "brightness": 100 }
        { "time":"sunset", "colourTemperature": 6500, "brightness": 100 }
        { "time":"dusk", "colourTemperature": 2000, "brightness": 30 }
    ]
}

in the case of a manually specified time and a twilight time overlapping they are treated as a step in the order they are listed. For example:

    "schedule": [
        { "time":"09:00", "colourTemperature": 2500, "brightness": 50 }
        { "time":"sunrise", "colourTemperature": 6500, "brightness": 100 }
    ]

if sunrise is after 9 everything is normal, if sunrise is before 9 then colour temperature is 2500 until 9 and then after 9 it is 6500 (i.e. sunrise is clamped to previous time + ulp in order to preserve monotonically increasing time time in the schedule).

[probus]

I like the above proposal the best, seems simple and expressive.

I'd sometimes like to control the bulb brightness while Kelvin adjusts the colour temperature automatically. But if I setup Kelvin to control only the colour temperature, I can't have the automatic brightness adjustment that works great most of the time.

How about if we:

1. Separate the colour and brightness adjustments. Kelvin would continue to control colour temperature when the user manually changes bulb brightness. If the user changes only the colour, keep updating the brightness.

and/or

2. Make it possible to have a multiple scenes (e.g. bright, normal, dim) with independent colour and brightness settings. Kelvin could detect the scene much the same way as it currently does as long as they aren't too similar.

[JayPour]

Bumping this as I too think EmilyBjoerk's and probus' proposals would make the most sense, I often want to adjust brightness but have Kelvin still control colour temperature. And as I live high up north I would rather have a set custom schedule (with very increment changes throughout the day) than a local variant. I always want to have bright blue with Apex around high noon and then a slow fade off till the evening for instance.
Best regards

[clemenules]

Thumbs up for EmilyBjoerk's proposal (named time variables and manually entered time).

Manual color setting (not just temperature, personally i'd like a little more 'orange' than 2000K at night) would also be great but this might make fading from one color sertting to the next a lot more complicated? I also imagine that right now Kelvin works with White Ambiance bulbs as well and adding color into the mix might 'break' that functionality?

The best thing about Kelvin is actually that upon power on it sets a hue light to whatever the Kelvin routine is dictating for that moment in time, including wherever it is in the fade transition from one temperature to the next. I'm more interested in that than the automatic sunlight/sunset timing as this varies so much from winter to summer I'd rather have a 'fixed' rythm for the house lights. Philips Hue formulas and routines don't provide a way to have the lights switch to a routine/formula dictated color upon power on of a hue light.

[willgf]

Hi there,

new here so pls excuse me if I'm getting things wrong. While I don't yet have Kelvin installed, I am very interested in it for our flat we're renovating. Maybe you're not aware of the US firm Ketra, which is also into circadian lighting. I would however prefer a solution on Philips Hue :)

I just wanted to direct your attention to their way of implementing circadian lighting - they're "natural" or circadian "show" uses both astronomical offsets etc (I believe similar to the current implementation) but also a sort of fixed schedule.

Perhaps this can give you some inspiration or ideas of how best to implement this:

https://www.ketra.com/hubfs/DS-3.0_Manual_V14.pdf
Pages 79 to 86 in particular

Keep up the good work!

[sirwolfgang]

Echo that it would be really nice to be able to peg to the sun. I am finding that DST creates a fair amount of dsync.

[RaphaelMarinier]

Hello,

For my own needs of configuring kelvin more finely, I implemented a new way to configure the light schedule very similarly to (and inspired) by @EmilyBjoerk's proposal. See here.

It allows writing such configs:

      "schedule": [
        { "time": "4:00", "colorTemperature": 2000, "brightness": 60 },
        { "time": "7:00", "colorTemperature": 2700, "brightness": 60 },
        { "time": "sunrise", "colorTemperature": 2700, "brightness": 60 },
        { "time": "sunrise + 30m", "colorTemperature": 5000, "brightness": 100 },
        { "time": "sunset - 30m", "colorTemperature": 5000, "brightness": 100 },
        { "time": "sunset", "colorTemperature": 2700, "brightness": 80 },
        { "time": "22:00", "colorTemperature": 2000, "brightness": 70 }
      ]

It handles conflicts by "clamping" the sunrise and sunset times in order to remove the conflict. E.g. in the above example, if the sunrise happens to be before 7:00, it will be set to 7:01, and "sunrise + 30m" will correspond to 7:31, preserving the transition. In the same way, if the sunset happens to be after 22:00, it will be clamped at 21:59, and "sunset - 30m" will correspond to 21:29.

The drawback of such flexibility is that weird configs with corner cases can be created, e.g.:

      "schedule": [
        { "time": "4:00", "colorTemperature": 2000, "brightness": 60 },
        { "time": "10:00", "colorTemperature": 2700, "brightness": 60 },
        { "time": "sunrise - 180m", "colorTemperature": 2700, "brightness": 60 },
        { "time": "sunrise + 180m", "colorTemperature": 5000, "brightness": 100 },
        { "time": "sunset - 180m", "colorTemperature": 5000, "brightness": 100 },
        { "time": "sunset + 180m", "colorTemperature": 2700, "brightness": 80 },
        { "time": "20:00", "colorTemperature": 2000, "brightness": 70 }
      ]

which cannot be satisfied just by moving the sunset and sunrise times, and that we therefore refuse (but it can become hard to explain why a config is invalid).

The code is in relatively good shape, but still needs more cleanups and documentation. It's compatible with both old- and new-style configs.

Any high-level comment and interest in getting this merged? (in which case I can do the final cleanups).

[RaphaelMarinier]

@stefanwichmann, any interest in getting this kind of changes merged (once cleaned up)?

[RaphaelMarinier]

Hi again.
I've been running my fork with the change described above for more than a year with no issue.
It seems that it's still an often requested feature, e.g. here, here.

I am willing to polish the changes (documentation, code cleanups, add missing features, etc..), but I need feedback from @stefanwichmann to make sure they have a reasonable chance of being accepted and that it's not wasted work.

Otherwise, I'll probably make a proper fork of kelvin with the new way of specifying schedules, but I think that it would be much better to keep forces on a single project.

[alexmatthew321]

I have just discovered Kelvin after looking for something like this that works properly for quite some time. It's not quite there but it's so close. If the above proposals, either the original proposal or RaphaelMariner's version, were implemented it would do 99% of what I want and quite honestly what I think most people expect it to do at the start.

[stefanvictora]

Thank you for this cool project, it was actually one of those that inspired me to write my own smart light scheduler ❤️ I was in a similar situation when I wanted more control over my lights' schedule, compared to what I saw in existing tools. There are still things on the roadmap, but I recently released an update that added state interpolations and improved transitions that could solve quite some use cases I saw mentioned in this thread.

Sorry if this feels too much like an advertisement, but maybe it's useful to some of you and can even inspire further improvements to Kelvin. I'm always happy to talk about anything related to light schedules :) So feel free to check it out: https://github.com/stefanvictora/hue-scheduler