It depends on your lights and what they support. lights_ct uses color_temp in the light.turn_on service call, lights_rgb uses rgb_color in the light.turn_on service call, and lights_xy uses xy_color in the light.turn_on service call. Every light supports different methods for adjustment, but typically, if a light supports color_temp that will be most accurate. You really just have to test what works best for you and your lights. Keep in mind, your lights don’t have to fall under one of those categories, you can mix-and-match.
I tried this, but it doesn’t seem to be working. Using Tradfri lights. Is there perhaps another way?
@Emphyrio, I tried something similar as you are doing, using the service: circadian_lighting.values_update. Also did not work for me.
I solved it for the brightness only by using 2 circadian switches, each with different brightness settings, switching one off at (re)start of HA and then toggling both switches (one to on, the other to off) at certain automation-events. I also had to set my interval-value to a small value (mine is 10) otherwise the transition between the two switch.circadian_… settings took too long.
My switch.toggle action looks like this:
- service: switch.toggle
entity_id:
- switch.circadian_lighting_tradfri_gu10_dimmed
- switch.circadian_lighting_tradfri_gu10
I cannot help w.r.t. the color switching, I never tried that. The only way to do this right now is by using the sleep_state and the sleep_color config variables, I think.
@claytonjn, I wonder why using circadian_lighting.values_update is not working?
I guess it sends the newest data from the sensor, and the data it sends is the same for all defined switches?
I mean the switch-settings like max_ and min_brightness are controlled by the switch, not the sensor.
So, at the moment, the brightness can only be step-changed when switching between two switch-variants. I hope you understand what I mean, sorry, English is not my native language 
But, maybe I’m wrong, and the circadian_lighting.values_update service sends the exact settings-data (color, brightness and other data) to each light-entity separately?
While I’m writing this, I wonder, why not having min_ and max_colortemp under the switch too? This would give us more control over the lights using various switches, as Emphyrio tries to do.
I’m also thinking, when the circadian_lighting.values_update service works as described after the “But,” above, then all the control we want, is already there. We just need to understand how to use the service correctly.
I’m not sure why the circadian_lighting.values_update is not working. It should trigger the sensor to update its values and then trigger all switches to do the same and adjust the lights.
I started some preliminary discussion about getting CL added as a native component, but one thing I want to do first is add the ability to enable/disable brightness and color temp adjustment independently, for each configured switch. The easy option would be to remove disable_entity and disable_state from the switch configuration and replace them with disable_bri_entity, disable_bri_state, disable_ct_entity, and disable_ct_state. My concern is that there’s already a lot of configuration options that can be confusing for users, and this method would require creating two input_booleans (or similar) for each configured switch. I would much rather just update the entity in the front-end to have two toggles instead of just the one, but that’s going to be a lot of work on my end creating new entity types for the front-end and back-end. I think the way I implement it is ultimately going to come down to what the Hass maintainers deem best, but either way it’s likely going to be a breaking change so I need to figure it out before I move forward with the process of submitting for native integration.
TL;DR: @Emphyrio it might take some time, but I plan on adding the ability to toggle brightness/ct adjustment individually, for each configured switch, which should solve your problem.
2 Likes
Ok, thanks for answering!
Good luck with your plans, I will be monitoring closely.
Thanks for your response! My problem is not toggling between switches (but it might have been easier without this workaround I admit :-)). The issue is that the lights brightness and color do not get updated at the moment of toggling. Using the values_update service, nothing seems to happen.
I think what I am looking for is for the update_values service to immediately update all lights that are switched on at that moment. So their colors and brightness shift to circadian right away.
@bouwew I will try setting the interval to 10. Perhaps this has the desired effect.
It should do exactly that - it works in my setup. You may need to play with transition time, and looking at the debug logs for CL may help troubleshoot as well.
@claytonjn, can I create more than one circadian_lighting entity? So I can use different color ranges for different sets of lights?
Like:
circadian_lightning_1:
...
circadian_lightning_2:
...
- platform: circadian_lighting
name: "Kitchen Lights"
lights_ct:
- light.yeelight_ceiling_7c49ebb39
- light.yeelight_ceiling_7c49ebb3a
- light.yeelight_ceiling_7c49ebb38
lights_rgb:
- light.gateway_light_34ce00fb6a
- platform: circadian_lighting
name: "Living Room"
lights_ct:
- light.yeelight_ceiling_7c49ebb21
- light.yeelight_ceiling_7c49ebb3a
- light.yeelight_ceiling_7c49ebb3a
lights_rgb:
- light.yeelight_rgb_34ce00910Thank you. But not what I’m after.
What I actually want is having 2 circadian sensors, each with its own settings for color temp range.
Hi!
I use your component to adjust my fish tank light.
I’m very happy with it.
I’m just wondering if it’s possible to use offset for sleep entity status somehow?
I use sun as my sleep entity, and the status is below horizon, but I want the switch to turn to sleep 1 hour after sun turns below horizon.
Regards,
Tamás
Maybe that’s just me being dumb, but 0.88 seems to have broken the component. I followed the debug instructions, renamed and moved sensor & switch in a new folder under custom_components but the addon won’t start.
The error log is pretty explicit:
ModuleNotFoundError: No module named 'custom_components.circadian_lighting.sensor'; 'custom_components.circadian_lighting' is not a package
I guess that’s linked to the new way of handling custom components.
Same here.
Since this is a component with multiple platforms the structure is a bit different than single conponents/platforms.
The “old” file custom_components/circadian_lighting.py should now be custom_components/circadian_lighting/__init__.py
So there should not be any circadian_lighting.py files in the root of the custom_components dir.
in the custom_components/circadian_lighting/ dir you should now have:
__init__.py
sensor.py
switch.py
3 Likes
Thanks a lot ! It seems to be working fine now :).
Hey all, I know I need to update the instructions for the new file structure. I’ve been holding out because I want to either get CL working with custom updater or I want to get it integrated as a native HA component. My big hangup for getting it integrated natively is that I want to add functionality to enable/disable colortemp and brightness on the fly for each CL switch. Ideally the front-end would have a button to toggle colortemp and a button to toggle brightness for each CL switch entity, either on the entity row or in the more-info panel. Problem is, there’s no existing front-end component with this functionality. I reached out in Discord, but I got the impression that there wasn’t much interest for me to add a special entity row or card for CL so I’m not sure if a PR would be accepted.
So at this point I’m trying to decide if I should keep pushing to get answers for native integration, or if that’s a waste of time and I should just move forward with getting CL working with custom updater and build a custom entity-row that people could manually add to Lovelace if they’re so inclined.
2 Likes
Thanks! Working here too 
@claytonjn if you go the custom_updater route hit me up on discord and we can probably find a solution that is easy for you and the users