RM Example: Circadian Color Temperature

Doesn't need a connection to the internet for this. Sunrise and sunset are from built-in astronomical clock.

I have rules that run every day at sunrise and sunset, and have for years. They have never missed a day.

You choose the interval. It fires on that interval. It doesn't fire "continuously". Even if you fire it every 10 seconds it's not much load on the hub. You're firing every 600 seconds, a miniscule load.

this has been some interesting food for thought. as always, thanks for your input. My original rule was doing a lot of math that is now built in with CT Over Time. I’ve rewritten my rule as follows:

ignore my variable values - those are just placeholders as I’m writing this before dawn.

I think this rule will handle self correction if it has to be rerun at a time other than sunrise. It just subtracts the the number of seconds of daylight that have passed from the timespan it is going to run over.

also, Change CT Over Time requires minutes, so I had to divide everything by 60. It also asks for the interval in seconds and gives a “1...60” example. It accepted 300, so I assume that is ok?

I put a conditional in there just keep me from borking all the numbers by running it at the wrong time, but that shouldn’t really be necessary.

I also created two other rules - one to set sunrise/sunset global variables and one to set the color temp to 6500 at 4:52 AM (i had to use RM for this as simple lighting doesn’t seem to allow for setting color temperature).

I’ll test this for a while before I change my lighting rules to use it.

final plea: my sunset value is really the night before, so I have to subtract the difference from 24 hours in order to get daylight hours. It would be nice to be able to access the upcoming sunset value and not just the one from the night before. It would be more accurate and I would not have to make sure to not do a hub update around sunset (which seems to be a common time for me to mess with hubitat).

I don't know if this will help, but I created a similar circadian rule in a much messier fashion that goes up and down, in contrast to your unidirectional rule. It has 3 opportunities to correct itself and get back on the rails, with a little buffer on either end. It's not exact and it's not a fine gradient, but it works. For your situation maybe you can set a few checkpoints along the way.

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.

1 Like

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! :stuck_out_tongue_winking_eye:

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:

then calculate:

edit3: you have to add a second trigger to the calculation rule at 1200 in order for it to restart the fade.

@bravenel is the man!

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

Rule #2
this rule changes the color temperature of the variable %colorTemp% up to 5000K by noon, and then back down to 2200K by sunset.

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:

adjust color temp even if the lights are on:

adjust level to start dimming at sunset:

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.

4 Likes

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

Definitely. Here is an example of another rule that controls the CT of multiple lights.

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.

Yes! Schweeeeet!
Thanks.

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 :rofl: 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 :smile:

What are you using to allow a wake up time to be set via dashboard?

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.

1 Like

Ha ha I just noticed my Snooze Time is set to 1 minute, that's because I'm testing it. Should be set to say 10 mins once I'm finished with it.

I really like this idea. I want to be able to set these variables via alexa however, which I don't think will be straightforward at all.

I can't figure out why the "current time" doesn't change from 12pm. Is there something wrong with rule machine?

your %start_time% variable should be set to noon, midnight, and sunrise +1 minute, depending on when the rule is triggered.

or any time you manually trigger the rule.

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.

Oh ok, when i manually triggered, the current time updated in the rule. I'm going to implement your reboot now. Thanks!

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

  1. 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.
  2. 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.

1 Like

Awesome, this is way better than my colorTemp hackjob. Looking forward to getting a finer gradient out of these lights. :slight_smile: