Google leads me to this: sudo apt-get install libatlas-base-dev
From here: libf77blas.so.3: cannot open shared file: no such file or directory · Issue #14772 · numpy/numpy · GitHub, the first result in my Google search…
@bouwew Yes, I found it just after posting here. I have installed the package but yet to try upgrading CL back to the new version. Will try today and report back.
Anyone have any problems with this component preventing lights from being turned off? If I have a particular circadian switch for some particular hue lights on/enabled, and then I try to turn those lights off, circadian seems to instantly take over and turn the lights back to full brightness. My hue lights usually take about 1.5 seconds to go from 100% brightness to off/0% brightness, and it seems as though right in the middle of that 1.5 second quick fade-to-off transition, circadian seems to say “WHOAH, these lights are already on, and should be at 100% brightness, but they are currently 0<X<100% brightness, so I better crank them back up to 100%.” To solve this in my automations and scripts, I’ve been using a workaround either by adding delays, or even turning off the circadian switch first, then turning off the lights, adding another delay of 5-10 seconds just to be sure they are off, then finally turning the circadian switch back on.
My workaround, especially the latter, seems pretty burdensome and also seems to go against one of the main features of the component in that it is constantly monitoring the state of the listed entities and it’s a set it and forget it type thing. More importantly, my workaround only works for automations/scripts; if I just do a simple “hey google turn off the kitchen lights” and the circadian kitchen switch is on, there’s a very good chance that during the 1.5 second transition to turn off, circadian is going to stop it and crank it back to 100%. Any ideas? Maybe something with my interval or initial_transition settings?
Are your Hue lights connected through a Hue bridge or some other controller? I ask because I have 50+ Hue lights in my setup and don’t have these issues. Also, when you turn off the lights and CL turns them back on how are you turning them off (HA Frontend, Hue app, etc.)?
First place to start would be to turn on debug logging for CL because that should show why CL is turning the lights on - my guess is that HA is updating the state of the lights to on which fires CL but it’s possible it’s the interval setting too.
Noticed similar things with my deconz setup. Especially the gledopto bulbs I own turn off very slowly, so it happens some times. But never really debugged it.
I can usually turn them off by trying various times.
1 Like
What value or attribute are you using to get the brightness? I setup on-hold-release on a Hue dimmer switch to toggle circadian lighting, and a Nest Hub next to it to confirm the action using tts. On turning on, I set it to announce current target color temperature. Would like to also announce brightness, but can’t find the value in the CL sensor.
I don’t know if the issue was already discussed, didn’t find it by searching the thread:
I moved all my ~45 Philips Hue and Ikea Tradfri Lights to Deconz today, working fine so far.
I installed the Circadian lighting component, which works fine as long the lights are turned on. I still use hardwired wall switches (a lot of them, therefore hesitant to exchange them). Everytime I switch lights on with them, the circadian values are not applied. If I then push the Circadian Switch one more time, it adjusts the color temperature.
Is there anything I missed in config? Just enabled a group with all my ambient color temperature lights as well as a group with all my rgb lights:
circadian_lighting:
switch:
- platform: circadian_lighting
lights_ct:
- light.alle_lichter
lights_rgb:
- light.rgb_lichter
Thanks in advance!
Brightness can be configured per-switch, so it’s in the attribute of each CL switch.
I started this way as well -I had nothing but problems with both lighting and with other zigbee devices that needed to re-learn routes every time a relay device (light) was turned off. I would highly discourage this, but I digress. The only way to really know what’s going on is to turn on debug logging for CL, that should indicate what’s happening - although it’s almost definitely an issue outside of the control of CL.
2 Likes
consider the following config:
circadian_lighting:
min_colortemp: 2700
max_colortemp: 6500
switch:
- platform: circadian_lighting
lights_ct:
- light.a
- light.b
lights_xy: # set using XY
- light.x
min_brightness: 20
max_brightness: 100
sleep_colortemp: 2700
sleep_brightness: 10
I am wondering why light groups a and b are set to different white color temp.
lamps in group a are all of the same vendor.
lamps in group b are all of the same vendor, different from the vendor of the light group a.
all lamps are using the same firmware version of Tasmota.
Are they visually different or does HA report different values? Is 2700-6500 within the valid range for both sets of lights?
Visually different: yes
Range: 2700-6500 K, yes
HA Tasmota value range for CT: 135-500
group a CT setting: 370
group b CT setting: 500
The problem for the different CT values was a missing underscore in the entity name of light group b.
After correcting that, groups a and b are set to CT=370 (mireds)
However, that is not a very warm white color temp!
Late at night, shouldn`t with my given config groups a and b be using 2700 K? would that not correspond to CT 500 mireds?
sensor.circadian_values gives colortemp: 2700; rgb_color: 255, 166.71997008820716, 87.40549175897922; xy_color: 0.525, 0.388
I am wondering why it is not giving the actual CT value in mireds as it is written to the light (Kelvin is actually not the value scale for CT, but mireds 153-500!). I would be helpful if the actual CT mireds value would also be displayed as a sensor attribute.
OK 2700K are actually 370mir, which is not helpful, because all the lights have their warmest white at 500mir. The light they give at 370mir would does not correspond to their warmest white, which is specified at 2700K.
So as a fix i would use 2000K as the target CT to reach 500 mir. This is a crude fix though… not sure why the scales of the lights are off that much.
Ah, of cause… thanks!
And thanks for CL - much cleaner to setup than flux, and even with more control options. Really enjoy it.
Thank you for this custom component. I was searching for something like this and it really helps.
I got it setup in my bathroom.with 4 hue lights (no rgb, just adjustable white). It works great.
Also tried to set it up with an rgb light in my bedroom, it works, but when I turn the light on with the friends of hue switch which is setup to go on using the last known settings, it first goes from yellowish white, to red, and then to the circadian set light. That happens in about 1 to 2 seconds.
Is there a way to change this so the light goes on immediatly with the correct settings?
Yes, I have this exact setup throughout my house. It’s a little time-consuming to set up though. The way I handle it is by creating a “Circadian” Hue scene for each group of lights tied to a switch and set the switch to activate that scene. Then I have a separate CL switch configured for each of the same groups of lights. I have an automation that triggers on state change for sensor.ciracadian_values that runs a rest_command for each of those scenes/switches that uses the Hue API to send the proper values to the Hue scene.
I plan to add a much more detailed write-up about this at some point, but unfortunately I just haven’t had the time to do that yet.
Thanks for the response,
Would you mind sharing the code for this?
I kinda understand what you mean, but not how to create it
I decided to learn how to use the restfull commands and the hue api. Suprisingly it wasn’t that hard.
I got it all setup now using this code. (For security reason the url and ID’s for the api are replaced with
# Automation for changing hue circadian scene
automation:
alias: Circadian_hue_auto
trigger:
platform: state
entity_id: sensor.circadian_values
action:
- service: rest_command.circadian_rest_slaapkamer
## Rest command for changing HUE scene (Slaapkamer)
rest_command:
circadian_rest_slaapkamer:
url: 'https://<SECURED__HUE_URL>/api/<SECURED_USERNAME>/scenes/<SECURED_SCENE_ID>'
method: PUT
payload: '{"lightstates":{"3":{"on": true,"bri": {{ ((states("sensor.circadian_values")|int / 100) * 255)|int }},"xy": [{{ (state_attr("sensor.circadian_values", "xy_color"))|replace("(", "")|replace(")", "") }}]}}}'
verify_ssl: false
content_type: 'application/json'
It could probably be done in another way, but this seems to work for me.
I got my Friends of Hue switch setup that when I press the upperleft button, it will go on on the Circadian Scene. Every 5 minutes when the circadian_values sensor changes state, the automation will call the rest command and that command will update the circadian hue scene with the correct values.
Only thing that doesn’t work is that the light will change color when it is on. It has to be put off and on again to update to the newest settings. But that isn’t a problem since the light never will be longer on then lets say 30 minutes, and in that time there isn’t really a big change in lighting.
In the rest_command payload, I had to do a trick with the brightness, since from the sensor that comes in a percentage of the brightness. The hue light uses 0 to 255 (actually 1 to 254) as a brightness value. So 100 from the sensor, is actually less then 50% brightness.
Then the second part, for the XY values. When you extract the attributes from the sensor, it comes with the numbers surrounded by (). So I had to remove those by using the replace() function.
1 Like
Hey guys, I just set up Circadian lighting, thanks for this awesome component ! 
I was wondering, I have cards in my lovelace setup turning on a light with a specific color (custom-card rgb-light-card) that get overriden with CL : if I choose to turn on the light with a blue color, the light turns to CL white.
I also have an automation for “flashing lights” in a given color, which gets overriden as well.
Is there any way to tell CL not to trigger in some cases other than calling a script or automation disabling CL then turning on light then enabling CL back ?
I want CL to trigger only when toggling light without specifying colors.
Thanks for your help
Welcome to the community 
If your CL switch is ON for that particular light, then yes it will override the colour you send to the light… thats the designed behaviour. If you want to use a different colour then you need to disable that CL switch first. As you mention, automations / script ARE the way to do this, but it’s not at all difficult.
Personally I can’t think of a way to detect ‘light turned ON without specifying a colour’… maybe someone else can help but I don’t see this being possible
1 Like