My original rule worked similarly and had programmed check points at 4:52 am, sunset and sunset + 60 min to set the colortemp to a constant. Different than yours my original rule took sunrise and sunset into account for the transitions. I now just set a constant at 4:52, the rest of it is calculated.
the new CT Over Time option has simplified things and honestly this new rule I posted above seems to working pretty well as long as I leave it alone. If things get off for some external reason hitting update rule and run actions will re-initiate it at the correct point in the transition.
I see two weak points - one is stacking pending events. I just hit run action several times while testing the rule and I had a bunch of pending events, which really shouldn’t have too much of an impact on the actual CT values, it should just cause it to be calculated more often that every 5 min. as long as I leave it alone, it seems to run fine.
the other is the aforementioned requirement of catching the sunrise and sunset times. the rule has to be running for at least one sunset and then one subsequent sunrise to have the correct numbers, otherwise those variables have to be manually adjusted to the correct epoch times. It works, but I’d love to just have access to what hubitat already knows without having to recapture it. then the rule would be essentially bulletproof.
sort of as a proof of concept I rewrote the rule for those that like the CT to rise from warm light in the morning to cool light by noon. its not perfect as it is expecting noon to be exactly halfway between sunrise and sunset, which it obviously isn’t. it raises the color temp until noon, then after noon it starts lowering it. at noon it may be off the target by a few hundred CT.
if this were to run on its own it would take the lights from ~6500 at noon, down to 2200 or 2700 (both variables are included) at sunset, then starting at sunrise the next day it would start raising them to a goal of 6500 by noon again.
I haven’t fully tested this, but it makes sense in my head!
The advantage to this over a dedicated app is just that it is lightweight and runs on the built in tools available, so it should hopefully be both reliable and low impact.
edit: If you wanted you could try to capture noon from the day before into a global variable and then just add 86400 to it (24 hours) to get an approximation of noon the following day. then do the math based on that.
edit2: here you go. two rules:
capture the times into global variables:
with the new time variables and with the "change color temp over time" RM action, setting color temperature has never been easier. here are my new example rules:
Global variables:
noon_variable -- time variable
sunset_variable -- time variable
colorTemp -- number variable -- also has a color bulb connector
Rule #1
this rule sets these variables every day 1 minute after midnight (I also have a sunrise_variable, although it is not required for these rules):
it requires two local variables:
start_time -- time variable
timespan -- number variable
The nice thing about this rule is that it will calculate the time between the time the rule is run and either noon or sunset, and adjust the rate of color temperature change accordingly. That way if the you have to change the rule or the hub is reset you can just hit "run actions" to restart the countdown.
Then all you have to do is use the variable %colorTemp% in your automations and it change the color temperature according to your circadian rhythm.
I'll present an example of my great room lighting automation. It is fairly complex b/c the lights are often on in this room when we are home. With these rules they adjust so slowly that it isn't noticeable even if we are sitting in the room reading a book. it requires 3 rules:
on/off and set color temp:
Of course it could be much simpler, especially in a high traffic area where the light turns on and off often. In that case a single rule that just adjusts color temperature to the variable will likely suffice.
Nice work. Just a thought....rather than have a set of rules like your last 3 here here above for each room, would it be more easy to set up a single rule that checks all groups (for me mostly rooms) and if each set/group is on, change their brightness/temperature to the appropriate circadian values? Then run that on a repeat to fire every 10 mins. I'm gonna try that I think. And of course set an override switch to allow other manual settings of lights to take precedence when desired (for specific scenes to be set etc).
I’d just have the trigger be the variable or CT change though, as that is already going to be running at whatever predefined interval you’ve setup. I’ve found that sometimes I have to manually adjust or change the CT, and if changing the variable is the trigger, then it will immediately change the lights as opposed to having to wait 10 min.
I've just completed an interesting wake up routine for our Master Bedroom (so not a general routine, but a specific one). It allows wake up time to be set from a dashboard for weekdays and weekends independently, along with a snooze time and number of snoozes. Then 30 minutes before the wake up it starts to bring the lights up (temp and level) until quite bright and daylight temp. Then an announcement from the Google Nest hub is made at the wake up time. If snooze is on then after that time a selection of sarcastic messages are broadcast pandering to my slightly obtuse British sense of humour. When we both get out of bed, the whole thing is cancelled (we have Withings sleep pads), lights go off after a while (allowing time to open the curtains) and the AC turns off. It's really cool. I'm very pleased with it. One day I will automate the curtains too ha ha ha. Will probably post it sometime soon to give others inspiration
I'm using "connectors". They allow you to enter values on a dashboard linked to global variables. Extremely cool. Here's the section of my dashboard for the wake-up/Alarm settings...
You have to fiddle around with the variables a bit so I have some simple rules to manipulate them into the required seconds, time etc (egm to start the circadian routine 30 mins prior to when wake-up is desired). It's been fun to set up. Not quite bullet proof yet but when I'm done with it I will post it all.
Sorry, i'm trying to copy your rule from the Jan 11 post. I see that %start_time% is set to current time, which was 12:40 at the time of your screenshot. Are you talking about setting the local variable on this page? What do i enter so it's just a null for the current time in the rule?
what you have will work fine. each time the rule runs it updates the start_time variable, so that will changes throughout the day.
the primary purpose of that variable is so that if the rule is activated at a time other than the trigger times it will calculate the time remaining and count down correctly. the primary time this would happen would be if the hub freezes and has to be rebooted. if the hub reboots cleanly, then it will actually continue the rule where it left off, so I have another rule that cleans things up a bit just in case the hub crashes:
that just makes sure that the rule is running, but that there aren’t multiple instances. its a redundancy i created after being frustrated a few times.
tl:dr:
the screenshot you posted will work fine. it will update the start_time variable each time the rule is triggered. you could put any value in there initially.
@jrau272, love the way you set up your apps to manage CT. Thanks for the inspiration. I have largely replicated your logic--tip of the cap. Two things I did differently fwiw.....
I took the middle-of-the-night logic that resets CT down to 2700K out of your rule #2 and put it in rule #1 since that runs once every night. Just simplifies the main app a little.
The bigger change I made is, rather than changing CT over time, I change a virtual dimmer over time (from 0 to 100 in the morning, then fade back down 100 to 0 in the afternoon). This way, your rule #2 doesn't have to care about multiple kelvin variants of the different bulbs, if you have them. I then used @adamkempenich's great Percent to CT App to convert the 0-100 dimmer to CT in kelvin for each bulb. To my thinking, it kept the layers of logic separate. And I believe (??? let's see if works) this way I won't have to embed CT management into any of my lighting automation. The main disadvantage of this approach, which I didn't realize until I did it, is that dimmer-fade can only be done in intervals of 60 seconds max, whereas the CT-fade can be done over a longer interval. Not sure I care since once per minute still isn't a significant load on the hub.
Eh, at the end of the day, to each his own. Just thought I'd share back my approach because I benefited so much by your logic. Props man. My two rules are below if helpful.
EDIT: Night one and I learned an important lesson--if you want to "pre-stage" the color temp of a bulb (i.e., set the bulbs color temp without turning it on), you have to go into the device details screen and set your bulb default to allow prestaging of color. If you don't, then your bulb will automatically power on as soon as you set the color temp.
Haha - as long as you click update rule first you should be ok. Otherwise it will just accelerate and you’ll have counted all the way down way ahead of time.
pandering to my slightly obtuse British sense of humour. When we both get out of bed, the whole thing is cancelled (we have Withings sleep pads), lights go off after a while (allowing time to open the curtains) and the AC turns off. It's really cool. I'm very pleased with it. One day I will automate the curtains too ha ha ha. Will probably post it sometime soon to give others inspiration 
