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)
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).
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.
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?
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
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.
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!
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
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.
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
That’s not how this works. The colour temp and brightness attributes are updated globally all the time (as per the update interval) and then the light turns on to whatever they are when you turn the light on. I think the confusion was that you gave the impression there are lights which know what colour etc you want them to be before turning them on. :ie sending colour data while off, then simply sending an On command. If you have a CL light setup and turn it ON, it should be the correect colour and brightness straight away.
Yes I would like to have option to disable CL for each lamp separatelly leaving others untouched at the same time. this is the point of this use case. Why should I disamble CL in alk rooms if I’m trying to find a lost screw in one of them?
Now I’m confused. I think you’re considering turning it on from HA only. What if I turn it on using smart relay? This is how Shellys work (dimmer, rgbw2) independently from HA. those can be triggered by physical switch (common wall switch). In such case those just turn light on (with recently known attributes). So either they must already know the colour or it has to be sent immediately after CL detects state change to on. For the first case those attributes must be updated all the time when light is off. In the secons case there might be a delay in applying CL colours. Am I wrong?
I was excited to discover this add-on, but I can’t even get it to run in the first place.
Running HA 0.114.3 on a RPi4. Followed the install directions closely:
Installed HACS into HA v0.114.3.
Restarted HA.
Waited the requisite hour.
Installed CL v1.0.13 via HACS.
Restarted HA, got the error message plus one about timezonefinder.
Spent some time researching and reading in this forum.
Uninstalled CL v1.0.13.
Restarted HA
Installed CL v1.0.11 via HACS
Restarted HA. Got the error messages below. (But I did not see one about timezonefinder this time.)
2020-08-31 09:35:22 WARNING (MainThread) [homeassistant.components.switch] SwitchDevice is deprecated, modify CircadianSwitch to extend SwitchEntity
2020-08-31 09:35:22 ERROR (MainThread) [homeassistant.setup] Error during setup of component circadian_lighting
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/setup.py”, line 191, in _async_setup_component
result = await task
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/config/custom_components/circadian_lighting/init.py”, line 92, in setup
conf = config[DOMAIN]
KeyError: ‘circadian_lighting’
2020-08-31 09:35:22 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform circadian_lighting.switch: Unable to set up component.
My HA install is only a few days old, so I don’t think I’ll notice if I roll back to an earlier version before SwitchDevice was deprecated (which should I choose?) but I don’t necessarily want to do that if I’m going to be playing Log Whack-A-Mole either. Thoughts/suggestions very welcome! Thanks in advance. Looking forward to getting this working.
– 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.