Master Circadian Colour Temp

Hi everyone, I am trying to create a rule in RM to use for circadian lighting.

I've looked at these two options...

... but the RM thread is based on the older configuration menu, and the app option seems to want to keep the lights on no matter what.

I think what will work is creating a master colour temp global variable that each bulb can reference, and then update if the circadian lighting mode is on for that particular light (set by a private variable for that RM/Button Controller rule).

I am hung up on how to determine where I am in the ramp-up/ramp-down from sunrise to noon and noon to sunset.

Say sunrise was at 05:20 today and solar noon is always at 13:18 for my location. The "sunrise to solar noon" time is then ~7.96 h for my example day.

Also, assume a time of 10:40. I can say I am at 66% of the way there from sunrise to solar noon (5.33h / 7.96h). I can use this to figure out to determine which colour temperature to set (with the range being 2200k during night/dusk/dawn and 5000k during peak daylight). This would be 2200k + (0.66 * (5000 - 2200)) ā‰ˆ 4048k.

I see there are now options to create a global variable in the UNIX epoch format, but can't quite figure out how to do "time progress" math in RM to figure out the percentage to multiply the colour temperature difference.

In the first link, I see others using fades to implement CT transitions, but I would love to have this hub-based with CT updates about every 15 minutes.

Any ideas, thoughts and comments would be appreciated!

The rule you create would still ultimately look more or less the same in the current version. Have you run into any specific problems when trying?

Not to be pedantic, but for current RM, you would want a "hub variable." ("Global variable" is a Rule Machine Legacy-specific feature that hub variables effectively replaced--and they can theoretically be used by any app.)

It's late enough that my brain is too tired to help with the math question if you still want to go down that route, but maybe someone else who sees this can try if so. :smiley:

1 Like

Honestly, what you are trying to do is better achieved with the circadian app if you are not going to use a CT fade. It runs every five minutes to update the CT. You can set the levels from 2200-5000.

There's a community created driver, I can't recall the exact name at the moment, that tracks the position of the sun based on your location. You could use that information to figure your color ramp throughout the day.

Edit to add link to thread: [RELEASE] SunCalc Driver

1 Like

Thank you for the suggestions so far, everyone.

The thing Iā€™m hung up about is how to implement a shifting colour temp mode, while also using RGB during different time ā€œmodesā€ on the same bulb.

This is my current set-up in Room Lighting:

This Room Lighting automation has its own activator device. This activator is synced to a Leviton Z-wave switch that controls switched outlets.

Do I first set up a virtual CT bulb that mirrors the CT from the Circadian lighting app device?

The biggest issue with Circadian app was the CT/RGB bulbs I specified in the app would just turn on at full brightness the next time the circadian CT was calculated and updated (every 5 minutes or so).

So, I use the Circadian app with a virtual bulb and [PRERELEASE] Virtual Prestaging to manage the CT changes. Basically, I have the Circadian app control a CT virtual bulb. I then use the Virtual Prestaging app to have the virtual bulb control the real life bulbs. This works wonderfully because the CT is constantly changing in the background even when the lights are off.

From there, the Virtual Prestaging app has a disable option when a switch becomes active. When I want to use colors on the real bulbs, I have the disable switch come on. This allows the Circadian app to keep going on the virtual bulb, but I control the colors. When I'm ready to go back to the Circadian, I just turn off the disable switch. You could create a rule to turn on the disable switch when a mode becomes active. This would allow the bulbs to shift to RGB as desired. You could then create a second rule to turn off the disable switch when a different mode becomes active and when you want the Circadian color temperatures.

2 Likes

You actually shouldn't even need the disable switch -- VP isn't supposed to send CT changes to a bulb that's in RGB mode. (Or hue changes to a bulb in CT mode, for that matter.) If both bulbs support the ColorMode property, it will only act if the source and target both present the same ColorMode value.

When you want it back under VP's control, change it to any CT value and VP will immediately push it the current temperature.

1 Like

Thanks for the clarification. I utilize Philips Hue scenes for colors and they do not update the ColorMode (at least in a timely enough fashion to prevent VP). So, my bulbs might have color, but Hubitat still has them as CT. This is why I'm just in the habit of activate disable switch, then push the Hue scene button.

Ah -- yes, changing them from the Hue side might well have a delay. I'd expect that if you changed them within Hubitat and that pushed the new color to Hue, it would be updated immediately.

Changing from Hubitat should eliminate the delay, but the delay might not be the actual problem--it could be that changing color (particularly setting scenes, I've noticed) on the Hue side puts the bulbs in to xy color mode, which Hubitat does not "natively" support and which conversion to/from is difficult. (The built-in integration, for example, seems to just assume CT mode and read the color temperature value from the Hue API when the bulb ins in XY mode as opposed to CT or HS mode, either of which works well with Hubitat and should be the result if you set color or CT from within Hubitat itself.)

Would enabling ā€œpush notificationsā€ in CoCoHue fix the delay?

Iā€™d love to skip the Hue hub, but the bulb I have in the ā€œGlobeā€ fixture is a Tradfri, which doesnā€™t do accurate RGB mapping (I thinkā€¦).

It depends on how you set everything up and where you are selecting your color. If they are brought into Hubitat via the Hue Hub and you change colors via the Hue app, Iā€™d recommend using the disable switch in VP. If you are changing via Hubitat, it does put the individual bulbs into RGB mode fine (at least Hue native). The catch to all of this is if you are using Rooms, Zones, or Scenes with Virtual Prestage. If you have a Virtual Bulb controlling a room or zone, and want to use Hubitat for colors, youā€™ll need to setColor the room or zone and not the individual bulbs. If you are using scenes or the Hue app to change colors on a room or zone, youā€™ll definitely want to have a switch available to disable VP.

Iā€™m a big fan of Virtual Prestage as it helps with maintaining a circadian rhythm even when my bulbs are off. However, the disable switch allows me to set up Hue scenes and implement them when my family wants color.

1 Like