[Release] [App] Circadian Daylight (v0.80) (Port)

adamkempenich · December 7, 2019, 9:15pm

Color Temperature is the most accurate.

Color is 2nd most.

Dimmable is limited to dimming only.

I’d choose color temperature

adamkempenich · December 10, 2019, 4:04pm

I wanted to give an update on what's been going on with Circadian Daylight.

The original CD was a port from SmartThings. During the process of porting it, there eventually was a point where there was more HE code than there was original code. At this point, things were getting very messy, archaic, and confusing.

I opted to not waste more time on the port. Instead, I've been rewriting it from the ground up in a cleaner fashion.

The new app is being built around parent-child devices, and seeks to fix the common confusions and complications of the original version of Circadian Daylight.

I don't have a timeline currently, unfortunately. I'm working to complete it as quickly as I can, but life tends to be extra packed this time of the year

mluck · December 14, 2019, 6:56pm

Is there a way to have the app control only CT throughout the day without changing the colors?

My use case: I have other automation that controls the color(s) of the bulbs. What I assumed (dangerous) that CD would do is modify the color temperature in concert with the natural circadian rhythm. Am I off?

adamkempenich · December 14, 2019, 7:24pm

I’m not sure I follow your question exactly—
Are you asking if the app can change the CT, and then stop running if you change the bulb color outside of Circadian Daylight?

mluck · December 15, 2019, 1:09am

Yeah I think I didn’t articulate my question very clearly. Lemme try again.

Let’s say it’s mid afternoon and I suddenly have a huge need to Go Pink. So I (or my automations) select a pink theme and my bulbs all change to some lovely rainbow of various pinks. Glorious. Until....

At some point, it appears CD not only does the CT adjustments to match Circadian cycle, but it also puts the bulbs back to plain white. It’s essentially nullifies any color change, rather than applying the CT changes to whatever RGB values currently exist.

Clear as mud?

adamkempenich · December 15, 2019, 4:13pm

Yup! We are on the same page, I think

CD changes color temperature during the daytime as well, since that’s when lights should match an external light source (the sun). The changes get periodically scheduled.

I introduced a feature in 0.80 that added an option to stop circadian daylight if the brightness changes outside of the app. I can expand this to color and color temperature as well.

Edit: you could make a rule for the light—when you change the color, turn on a switch to disable CD until time N.

mluck · December 15, 2019, 10:25pm

So just I'm clear, this is my understanding:

I can use CD in its current form to progressively change CT throughout the day, aligned with the cycle of the sun. I think I'm using it this way currently and love it.
However, if there's some external change to color (not CT), then when CD changes temperature, the RGB value will revert automatically. There is no way to change this in the current version of CD.

Are each of the above correct?

I'm not looking to interrupt changes to CT. I rely exclusively on CD to manage color temperature. Rather I'm looking to prevent the CD-driven changes to CT from also changing the color/RGB of the bulbs also. If I make the bulb color yellow, I want the temperature of the yellow to follow the sun. If I make the color blue, I want the temperature of the blue to follow the sun. I want CD to control the CT without effecting the color value. Does that make sense?

adamkempenich · December 19, 2019, 4:51am

I’m not quite sure I follow, yet. Are you saying you want to use RGB+CCT simultaneously?

So, you set your color to Red on an RGB half of the device — we’ll pretend we’re using a device that can assign both separately— and then you want the color temperature channels to move, and not change the RGB assignment t?

mluck · December 19, 2019, 5:18am

Yes that's the idea conceptually.

[Warning what follows is a rambling discussion of color theory from a total amateur.....]

Having said that, the more I research color theory, the more I think my question is a total red herring. I have always viewed CT as independent of RGB value. That is to say, just like white can run from low-Kelvin warm orange-ish white to high-Kelvin cool blue-ish white, so too can red or purple or whatever. Or, said differently, for every RGB value (X,Y,Z), there exists a full temperature array from 1500 degrees Kelvin to 25,000+ degrees Kelvin. And so, predicated on this idea, I wanted CD to change the CT throughout the day, independent of the RGB value that was presumably set from some other automation or manual selection. If the bulb was white, warm it up in concert with the sun. If the bulb is red, warm it up in concern with the sun. Etc. etc. This was the thinking behind my original question.

But I'm now thinking that the whole question was founded on an incorrect understanding of color temperatures. It seems to me now that the right way to think about it is that every RGB value has a single temperature as an attribute. Thus, every color is considered to be "warm" or "cool" to some extent. So we can't change CT without also changing RGB, and vice versa.

Assuming the above doctor dissertation is correct, then here's what I should have asked you originally.....
Is there a way to suspend the automated progression of CT if there is an external change (i.e., other automation or manual intervention) to RGB? And then reactivate the CT progression later somehow?

Sorry I mucked this up terribly....

adamkempenich · December 19, 2019, 5:25am

No worries! I’ll page a few real doctors on the boards here and have them review your work

You can have CD pause its execution by creating a rule that enables a switch when an RGB value changes on a device. You could the restart the switch at 3 a.m., or so, and CD would work again the next day.

Those steps look like this:

Create a virtual switch (“~Disable CD”)
Select this switch in CD under the Disable when this switch is on setting.
Create a rule: [Trigger: When RGB changes] [Action: Turn ~Disable CD on]
Create a rule that turns that switch off at a certain time every morning

Edit: Some devices can actually use CT separate from RGB. I’ve got a driver and algorithm I’ve been working on that merges the two in a user-friendly fashion...

janwerner · January 7, 2020, 10:47am

Hi,

first of all thanks for your work! I recently switched form the original Circadian Daylight Coordinator app for ST to this app.

I use a mix of Hue and Osram Lightify CT bulbs. CD is using default settings, no overrides set. It's 11:40 AM right now and CD is decreasing the color temperature:

11:34 AM: 3105 K
11:40 AM: 3017 K
11:45 AM: 2937 K

Shouldn't the temperature be going up to ~ 6000 K around noon or did I get something wrong?

Thanks,
Jan

adamkempenich · January 7, 2020, 1:14pm

This version will use sunset/sunrise to determine where the middle of the day is. If you’d like, you can override that in the settings.

The other version of CD uses a shorter transition period. I’ve had it running on my ST hub alongside my HE setup here, and I’m not sure which is better. What’s everyone here think?

janwerner · January 7, 2020, 1:29pm

Hi Adam,

thanks for your reply - it's s still not quite clear to me however. Sunrise/sunset time is correctly detected for me (Central Europe):

getSunriseTime - System Sunrise time: [sunrise:Tue Jan 07 08:32:00 CET 2020, sunset:Tue Jan 07 16:31:00 CET 2020]

So the middle of the day would be around 12:00 and that's when I'd expect CD to use a color temperature of 6000 K - but it's actually below 3000 K.

This is the model that the previous app used - is this what your app is supposed to be doing as well?

Best, Jan

adamkempenich · January 7, 2020, 1:43pm

Oh wow, that’s drastically different from where it should be. I should have read your logs more closely

If you manually set a sunrise and sunset override, does that fix it?

janwerner · January 7, 2020, 4:26pm

Hi Adam,

I'm glad I'm not going crazy

Setting sunrise/sunset overrides doesn't have the desired effect either. This is the result with sunrise at 08:00, sunset at 20:00:

app:8382020-01-07 17:25:07.963 debugCircadian Daylight (Circadian Daylight): Color Temperature: 4365
app:8382020-01-07 17:25:07.960 infoCircadian Daylight (Circadian Daylight): The current mode is not set for an override.
app:8382020-01-07 17:25:07.956 debugCircadian Daylight (Circadian Daylight): Mode is Evening vs null
app:8382020-01-07 17:25:07.953 debugCircadian Daylight (Circadian Daylight): Sunset overridden to Tue Jan 07 20:00:00 CET 2020
app:8382020-01-07 17:25:07.951 debugCircadian Daylight (Circadian Daylight): getSunsetTime - System Sunset time: [sunrise:Tue Jan 07 08:32:00 CET 2020, sunset:Tue Jan 07 16:31:00 CET 2020]
app:8382020-01-07 17:25:07.950 debugCircadian Daylight (Circadian Daylight): Sunrise overridden to Tue Jan 07 08:00:00 CET 2020
app:8382020-01-07 17:25:07.949 debugCircadian Daylight (Circadian Daylight): getSunriseTime - System Sunrise time: [sunrise:Tue Jan 07 08:32:00 CET 2020, sunset:Tue Jan 07 16:31:00 CET 2020]
app:8382020-01-07 17:25:07.936 debugCircadian Daylight (Circadian Daylight): modeHandler calledlled

Could this be related to 24-hour time format or something like that?

Cheers,
Jan

adamkempenich · January 7, 2020, 4:50pm

Sweet.

This seems somewhat correct. The formula used would show your mid-day at 1400. The default mid-day temperature should be 6000k, and since it's ~1700 your time currently, that number should be in that area right about now. Although, if anything, it's a bit on the cold side. My quick math says you should be around 3900.

Has it been getting warmer as the day has progressed toward sundown?

It shouldn't be --- I use 24-hour time on my hubs

janwerner · January 7, 2020, 5:02pm

Color temp is definitely too cold (compared to Circadian Daylight Coordinator).

With sunrise/sunset set manually to the actual times - 08:32/16:31, I get 6000 K now (17:57) - same as with auto mode. Definitely not right. With CDC, color temp is 2700 K)

adamkempenich · January 7, 2020, 5:16pm

Thank you! I'll take a look this afternoon

janwerner · January 7, 2020, 5:27pm

Sorry - found the issue - mostly my fault.

For some reason, I'd previously entered (insensible) Color Temperature Overrides, but didn't really notice them when I checked because the Use Color Temperature Overrides switch was turned off, so I assumed the values entered wouldn't have any effect.

However, the useCTOverrides variable is not being validated in your code.

Best,
Jan

adamkempenich · January 7, 2020, 5:41pm

Yup. I've been fixing this in the rewrite of CD

Tell me --- do you prefer the way your SmartThings CD instance handled color temperature --- which shifts the color temperature only around sunset (a little more drastic of a chane)
Or do you prefer the method implemented in this driver, more, where it slowly changes throughout the day?

I've been a little uncertain of which is better. This is, after all, simply a port of the original SmartThings version...