Rethinking the core functionalities of Kelvin about kelvin HOT 16 OPEN

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

from kelvin.

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.

from kelvin.

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.

from kelvin.

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!

from kelvin.

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.

from kelvin.

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.

from kelvin.

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

from kelvin.

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

from kelvin.

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

from kelvin.

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

from kelvin.

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

from kelvin.

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.

from kelvin.

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

from kelvin.

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

from kelvin.

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.

from kelvin.

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

from kelvin.