OK…this is great! I’m ready with my initial follow-up questions. Separately in Node Red I built more of a sunise / sunset fade for my RGBCTT bulbs from dim red to brighter red to orange before it cuts over to the white LEDs. I tried running that at the same time as this CL script and they seem to interfere with one another… not necessarily surprising. My dim red will briefly flash to the white LEDs before resuming it’s slow brightening and then another flash of white… not really a soothing sunrise. lol Is there an easy way to “engage/disengage” the CL script at a certain time? That way I could have it take over after my sunrise and then “give up control” to the bedtime “sunset.”
Question #2 - is there a way to “bias” the CL more towards blue in the early morning? As I understand it, blue light helps you wake up faster. Before I got this script working I had my “sunrise” transition to Cool White; would be nice if I could do the same in CL… otherwise I’m sure I can make it work if there’s a ready answer to Q1.
Is this normal? I’m just starting to play around with this, and my brightness stays at 100% for all three of my switches… Shouldn’t it vary with the movement of the sun? I know this is a small dataset, but there is no variation.
Regardless of method I get similar, but not exactly the same, color. In some of the modes the “white value” does not change by this addon, but in others it does.
What mode am I supposed to run to get the most accurate color and how do I know?
That’s a history graph card - there are a couple ways to get the attributes as states for the graph; you could use template sensors, or use custom lovelace cards that allow for using templates directly in lovelace, etc.
Basically lights_ct is best because color temperature is the proper measurement for the intended outcome and what you are ultimately trying to achieve. Also, for lights with designated white diode (RGBW), sending ct usually results in the R, G, B diodes to be off and only the W diode to be used which it typically more visually pleasing. lights_rgb and lights_xy use some formulas to estimate color equivalent to color temperature so they aren’t as accurate, but they are included so that color lights without color temp options can still be used. lights_brightness is there for dimming-only lights, or if you only want the brightness to be set.
Thanks for this awsome component. I’ve been using it for a couple of weeks and I’m really loving it.
I have a question, and am looking for some advice. I’ve created a simple Node-RED flow to turn a LIFX globe on at a certain time, at brightness: 1, and then transition it to maximum brightness over a preiod of half an hour. The problem is, whenever the flow triggers, the light turns on, then shortly after it suspends its brightness transition and is stuck at a low brightness; until manually adjusted.
I just did a test where I turned off the Circadian Lighting component and the flow worked as intended. Is there a way around this, so Circadian Lighting can continue to be turned on over the half hour while the transition occurs? Below are my config entry and Node-Red flow if that helps.
Once again, thanks for all the effort you have put into this component; it’s really nice!
As far as I know there are no lights than can simultaneously hand two different transition requests - so there’s no way that CL can adjust color temperature while the brightness transition continues to occur. Your only option would be to take the same approach as CL and rather than sending a single 30 minute transition you send a number of short intermediary transitions (e.g. send new brightness every second)
Thanks for this info Clayton. I’ll try changing mine to use lights_ct and see if it fixes my issue of pink downlights during the day (when the LED strip is showing white).
Is there a way to bias this CL plugin “earlier” somehow? The bulb CT is quite warm when I wake up in the morning and I’d love for it to be cooler since blue light is excellent for helping you wake. Similarly, it’s almost my bedtime and the CT is still 370; I’d love for it to be 500 by now. See what I mean about shifting the whole cycle earlier?
Edit - I’m looking in _init_.py and thinking it’s probably something to do with sunrise_offset but I’m not sure how or where to edit that to perhaps make the script think everything is happening (two hours?) earlier than it is… I’d hate to just put a “+2” on the end of a line somewhere and break the whole thing.
Recently, I have spent a lot of time in rewriting the fantastic cirdadian_ligthing component. About 600 lines are rewritten! (see all changes here)
In summary, I have added the functionalities:
add only_once option to switch, which makes the light change to the correct value only when turning it on (or disabled_state, sleeping_state switch). This is useful when you want to manually change the settings of the lights sometimes and make it stay.
add the ability to make sleep_state and disable_state lists of options. For example when using an input_select where something should be disabled on multiple states. This is a non-breaking change because it also accepts just a single string.
simplified the dependencies (making it easier to install)
the integration is now fully async, which means that when adjusting the lights, all lights get the service call simultaneously!
I encourage everyone to try out the latest beta 2.0.1b (on HACS too). Please open an issue if you have any problems.
