Circadian Lighting [Custom Component]

olisky · August 20, 2020, 10:45pm

Nice,
how about the dimmers,
I guess the “brightness only” group can also work with dimmers?
Or has the potential to work with dimmers?

sparkydave · August 20, 2020, 11:22pm

Yes, it works with dimmers too

olisky · August 21, 2020, 2:40am

Oh!!!
Very nice!

galv83 · August 21, 2020, 9:50pm

Hi @claytonjn,

Just wanted to drop by and leave a big thank you for making this custom_component.
I was using the default “dusk/dawn” settings within the Lifx app, and they were awful compared to this component that you have put together.

This is a massive upgrade, many thanks

jamespreedy · August 22, 2020, 6:24pm

Hi folks, hope you’re all well.

As with many of you, I’m loving this component - big thanks to @claytonjn

I did have an issue I couldn’t get my head around, and was hoping someone might be able to please point me in the right direction?

All my bulbs are Hue’s - either colour ambiance, or white ambiance.
I have motion sensors that trigger an automation, which in turn calls a script, and my lights come on.

The dream is to have the lights turn on at the right bigness and colour temperature, so they don’t need to spend a second or so adjusting.

I thought I had this nailed by including the brightness and hs color values in the initial light.turn on service - see below.

 turn_on_study_spotlights:
   alias: "Turn on the Study Spotlights"
   sequence:
     - service: light.turn_on
       data_template:
         entity_id:
           - light.1st_floor
         brightness_pct: "{{ state_attr('switch.circadian_lighting_study','brightness') | float }}"
         hs_color: 
           - "{{ (state_attr('switch.circadian_lighting_study','hs_color')[0]) | float }}"
           - "{{ (state_attr('switch.circadian_lighting_study','hs_color')[1]) | float }}"

This is fine during the day whilst the colour temp doesn’t change, but in the evening’s I’m getting an odd phenomenon.

Motion triggers the light to come on but after a few seconds the colour temperature changes. When motion is detected whilst the lights are on, another light.turn_on command is sent (there are timers etc being reset as well etc), and the colour temperature changes again. A few seconds later, the circadian lighting component corrects the colour temp again. Its a little like an ever changing colour temperature disco!

In short, my brightness and hs_color approach in the script seems to set the lights to a slightly different colour temperature than the circadian lighting component sets them too.

Example switch below.

  - platform: circadian_lighting
    name: Study
    sleep_entity: 'input_select.hassio_alarm_state'
    sleep_state: 'Night'
    sleep_colortemp: 2000
    sleep_brightness: 1
    disable_entity: 'input_boolean.study_override'
    disable_state: 'on'
    initial_transition: 1
    lights_ct:
      - light.study_spotlights
    lights_brightness:
      - light.study_tv_light

What information would be useful in trying to debug this?

Thanks in advance …

BrianHanifin · August 22, 2020, 10:48pm

I have documented a potential solution to the problem caused by light groups that allows you to keep using the Circadian Lighting component.

claytonjn · August 24, 2020, 2:18am

If you’re using Hue lights and your lights are configured under lights_ct (the best option) then you should replace

hs_color: 
  - "{{ (state_attr('switch.circadian_lighting_study','hs_color')[0]) | float }}"
  - "{{ (state_attr('switch.circadian_lighting_study','hs_color')[1]) | float }}"

with

kelvin: "{{ (state_attr('sensor.circadian_values','colortemp') | float }}"

Basically you want your script to use the same method of adjusting the lights as CL, because going between kelvin and rgb/xy/hs all require some estimating with various levels of accuracy.

jamespreedy · August 24, 2020, 6:28am

@claytonjn - Hiya, thanks for your help.
I made the changes you suggested, but HASS wasn’t a fan of me using

(state_attr('sensor.circadian_values','colortemp') | float )

I got an error saying it needs an int, not a float.

Invalid data for call_service at pos 1: expected int for dictionary value @ data['kelvin']

I’ve changed this to stop the errors …

kelvin: "{{ (state_attr('sensor.circadian_values','colortemp') | int ) }}"

… but cant help feel that I’m also maybe losing some colour temp accuracy by converting from float to int.

When the CL component adjusts the colour temperature for lights_ct, does it also do it as an int or is it able to adjust using a float?

Thanks again!

sparkydave · August 24, 2020, 8:43am

I have some RGBW downlights and an RGBW LED strip all setup as XY lights in CL. The LED strip gives a daytime colour that I expect, near full white, however the downlights are never white, but pink. The only difference I can tell between the two types is that the LED strip needs the brightness set to at least 1 in order to show any white value (ie: white value at max but colour brightness 0 gives no light at all) whereas the downlights will happily give a white light with the colour brightness at 0 and then the white brightness is controlled with the while value.

Any ideas what I can change to get the downlights to give white light during the day (other than disabling CL)

claytonjn · August 24, 2020, 3:20pm

Sorry, was out on the roof all day and a bit sloppy with the copy/paste. CL converts to int, but it sends mired not Kelvin so to match exactly you’d actually want to do:

color_temp: "{{ ((1000000/state_attr('sensor.circadian_values','colortemp')) | int ) }}"

I’d be very surprised if you could tell the difference between rounded and non-rounded Kelvin values though or the difference between rounded and non-rounded mireds (which inherently has less accuracy because it’s a smaller range).

claytonjn · August 24, 2020, 3:29pm

The only real options you have are to try different adjustment methods (ct/rgb/xy). The challenge is that color temperature (kelvin/mired) and color (rgb/xy/hs) don’t represent the same thing so there is a bit of estimation to get a color representation of a color temperature. Also, a great deal depends on the lights themselves, how accurate they are, and if they were calibrated for color temperature adjustments or if they are just intended for colors.

jamespreedy · August 24, 2020, 5:54pm

That makes perfect sense - thank you again @claytonjn.

I’ve replaced kelvin with color_temp for now, and will give it a shot tonight once we hit sunset. Have a great day!

bernhard · August 24, 2020, 8:06pm

I have the same issue that my LIFX, Innr and China RGBW strips don’t Match in Color. Should’ve sticked to one make

I will try to adjust the lifx and China LEDs not automatically but via an automation to adjust the color temp to match better. Maybe that works for you?

sparkydave · August 26, 2020, 4:24am

This makes sense, it’s just that is seems odd that the LED strip will be completely white (or close enough) in the middle of the day yet the downlights will still be pink…

I’ll have a play around and see if I can get them any better…maybe the downlights just aren’t very good

bassor · August 26, 2020, 2:47pm

Continuing the discussion from Circadian Lighting [Custom Component]:

I tried Flux…omg, it does not reflect the actual outside color temp at all. E.g. now it is raining, the ambient color temp is really something else that the estimated. It just does not fit, doesn’t feel natural lightning at all. The same must be with the Circadian light.
Wish, really come on, more people would understand what it means to replicate the outside light color temp!
Just connected the VEML6040… here are the results for the ambient light – delay between the each value is one second(!). Pay attention to the CCT-value:
467 BLUE: 223 WHITE: 2189 CCT: 3291 AL: 29.38
RED: 732 GREEN: 647 BLUE: 301 WHITE: 2747 CCT: 3533 AL: 40.71
RED: 962 GREEN: 905 BLUE: 422 WHITE: 3549 CCT: 3813 AL: 56.94
RED: 996 GREEN: 948 BLUE: 453 WHITE: 3633 CCT: 3920 AL: 59.65
RED: 1011 GREEN: 958 BLUE: 456 WHITE: 3635 CCT: 3890 AL: 60.28
RED: 1022 GREEN: 967 BLUE: 461 WHITE: 3647 CCT: 3886 AL: 60.84
RED: 1134 GREEN: 1060 BLUE: 503 WHITE: 3958 CCT: 3820 AL: 66.70
RED: 949 GREEN: 787 BLUE: 358 WHITE: 3674 CCT: 3237 AL: 49.52
RED: 4362 GREEN: 4662 BLUE: 2511 WHITE: 11843 CCT: 4898 AL: 293.33
RED: 6327 GREEN: 6915 BLUE: 4365 WHITE: 17274 CCT: 5795 AL: 435.09
RED: 3669 GREEN: 3849 BLUE: 2055 WHITE: 9436 CCT: 4751 AL: 242.18
RED: 1317 GREEN: 1120 BLUE: 502 WHITE: 4860 CCT: 3313 AL: 70.47
RED: 1335 GREEN: 1225 BLUE: 547 WHITE: 4890 CCT: 3621 AL: 77.08
RED: 1365 GREEN: 1251 BLUE: 549 WHITE: 5042 CCT: 3586 AL: 78.71
RED: 1382 GREEN: 1263 BLUE: 554 WHITE: 5142 CCT: 3573 AL: 79.47
RED: 1398 GREEN: 1273 BLUE: 561 WHITE: 5199 CCT: 3566 AL: 80.10
RED: 1401 GREEN: 1281 BLUE: 564 WHITE: 5257 CCT: 3581 AL: 80.60
RED: 1402 GREEN: 1283 BLUE: 563 WHITE: 5277 CCT: 3579 AL: 80.73
RED: 1405 GREEN: 1284 BLUE: 563 WHITE: 5293 CCT: 3572 AL: 80.79
RED: 1401 GREEN: 1275 BLUE: 563 WHITE: 5294 CCT: 3566 AL: 80.22
RED: 1400 GREEN: 1279 BLUE: 560 WHITE: 5295 CCT: 3568 AL: 80.47
RED: 1399 GREEN: 1275 BLUE: 561 WHITE: 5297 CCT: 3566 AL: 80.22
RED: 1402 GREEN: 1283 BLUE: 569 WHITE: 5301 CCT: 3597 AL: 80.73
RED: 1397 GREEN: 1269 BLUE: 566 WHITE: 5289 CCT: 3576 AL: 79.85

claytonjn · August 26, 2020, 3:07pm

I’m not sure what your use-case is for wanting to replicate current outdoor lighting conditions, but the point of this component is to use lighting to maintain a Circadian Rhythm. This means that the point is to be consistant and emulate the lighting that would be occurring on the average day so that your body isn’t jarred from day to day breaking that rhythm. If you want lights that dim when clouds go by or it’s raining or turn off when there’s a solar eclipse then this is definitely not the right solution for you. It seems you could easily just take the CCT values your detecting and write an automation to set lights to those values.

EDIT: Perhaps I should reword the first post a bit to make this more clear.

bassor · August 27, 2020, 9:04am

True, circadian rhytm is not really what I’m after, after all – I’m after the most natural feeling lightning. Not really about the brightness, but to “replicate” the feel (cct mainly) of the artificial light to be as similar to the outside ambient light conditions. An example would be a fake window that one cannot differentiate the light coming from that from normal window.
Just got the sensor working, need to find out how to deliver the data to the HA – being a newbie…
Thanks for your reply!

maxym · August 30, 2020, 5:52pm

Hello,
I have two questions about this component:

can this component update light continuosly even when it is turned off?
There are devices which accepts colour changes all the time, then turn on the light with recently retrieved attributes
Can this cycle be suspended for selected light? I would like to have possibility to force light values (using another automation) preventing overwriting the light params by Circadian component

thank you in advance

claytonjn · August 30, 2020, 6:06pm

No, as far as I know those devices use non-standard service calls to set those values. I could add this ability at some point in the future but it’s low priority because it’s a limited use-case and there are other options to get the lights to turn on with correct values that work across the board.

Yes, each instance is a switch entity so when the switch is off CL has no effect. Just configure a different switch instance for each light or group of lights you want to be able to control individually.

maxym · August 30, 2020, 6:21pm

Don’t know how services work and what is considered non-standard. But there are devices like Shelly RGBW2 or LifX lights which can work this way.
I’m just starting which this but I can imagine that turning on the light during sunset when the recently remembered light attributes are from midday might cause light flash.

Yes, found it in docs after posting my OP. However this approach means creating additional sensor for each lamp which is far from optimal. Maybe it could be done without it somehow. Service call or so?

Thank you for fast responce.

Edit: I just learnt that I can run circadian component against virtual (mqtt) light, then send its values to my lights applying custom logic I need. It should give results I’m expecting