Not sure, it’s working for me.
This line is interesting:
ImportError: No module named 'custom_components.circadian_lighting.switch'; 'custom_components.circadian_lighting' is not a package
Do you have the latest version from GitHub? If so, I would try reorganizing the files as described here: Circadian Lighting [Custom Component]
I am not sure which version I have. The date stamp is from Dec 6.What is the latest version?
Setting the file up as tepprr proposes does not change the issue. It did work for 0.85 and before so maybe I should report an issues at home assistant.
For some reason the component ignores the transition time. It seems to fire non stop and changes the lights instantly. I’m not entirely sure why this happens. I’ve added the transition time to the configuration file after not including it and altered the value, but this seems to make no difference. I’m using Philips Hue lights with the 2nd generation Hue Hub.
The way I found out is trying to change the lights manually but they only budge for like half a second, before it’s back to the circadian setting. I see absolutely no errors at all. When I focus on the lights when they’re scheduled to change, I notice they too change instantly.
What could cause this behavior?
Edit: Setting the interval and transition doesn’t change anything. I’m currently on 300/30 but tried several options.
That should be latest (I really need to implement some sort of versioning).
Is the sensor.circadian_values entity initialized? Are you sure that’s everything in the logs relating to CL?
It shouldn’t be firing non-stop, you can verify by turning on debug logging:
logger:
logs:
custom_components.circadian_lighting: debug
custom_components.sensor.circadian_lighting: debug
custom_components.switch.circadian_lighting: debug
It will however respond immediately if a light is adjusted because it listens for lights to turn on so they can be immediately set to the correct values. In this case it also ignores the transition time.
That being said, I do think something isn’t working properly. I also have almost exclusively Hue lights and the second generation bridge - I recently installed a Hue fixture in the kitchen where a lot of time is spent throughout the day on weekends, and I noticed that transitions in color temperature were quite noticeable when they should be gradual and imperceptible with the default transition and interval settings. I plan on troubleshooting when I have the time.
I should probably add that I’m also using a custom component to include Hue Motion Sensor data and Hue Tap buttons. Hue motion sensors + remotes: custom component.
I’m using that too 
My issue with 00.86.4 is solved. Now all the modules are loading again!
So what did I do to get this solved? I redid the upgrade of HA but that did not work, however there was a warning that pip needed to be upgraded to 19.0.1 so I did that and upgarded HA again. Restarted HA and now it is fine! I have no clue why this happened, maybe an bug in the old 18.0 pip?
Thank you!
It gave me an idea how make a better implementation for my case.
What I ended up doing, using 2 automations:
Actually quite simple, works like a charm with interval = 300 and transition = 10.
Hi I have various light bulb, if I understand correctly
each has to be assigned differently in circadian component?
Hue colour bulb
Hue white ambience
Hue standard white
Dresden led strip (5 pins controls white separately from RGB)
Yeelight colours
All Zigbee lights controlled by Conbee (not Hue bridge)
Great component! Thanks!
I wanted to have brightness and color temp change throughout the whole day, so I made the following edits. If anyone wants this here are the changes.
circadian_lighting.py: line 267
def calc_colortemp(self):
return ((self.data[‘max_colortemp’] - self.data[‘min_colortemp’]) * (( self.data[‘percent’] + 100) / 200)) + self.data[‘min_colortemp’]
in the switch component: starting on line 234 modify calc_brightness as below.
def calc_brightness(self):
if self._attributes['disable_brightness_adjust'] is True:
return None
else:
if self.is_sleep():
_LOGGER.debug(self._name + " in Sleep mode")
return self._attributes['sleep_brightness']
else:
return ((self._attributes['max_brightness'] - self._attributes['min_brightness']) * ((100+self._cl.data['percent']) / 200)) + self._attributes['min_brightness']Hi Klagio,
There are basically 4 options:
The first 3 are for lights that can change the color or the white-balance.
The last one is for lights that can only change the brightness.
You will need to find out yourself which lines to use.
I have Yeelight colorbulbs 2 and Ikea Tradfri lights that can change the whitebalance. For me they work when put under light_ct.
You can look at the attributes for each light in the HA Developer Tools: click on <> and find your lights.
If it shows min_mired and max_mired, then you can use lights_ct, I think.
I’m trying to configure a template switch called ‘Auto brightness on/off’. When I turn it on, I would like the lights that are currently on to automagically tune to the circadian brightness and color. But they don’t, I think because they are not changing state so the Circadian Light component does not trigger.
I saw a mention about a service ‘circadian_lighting.values_update’ that would seem appropriate, but what is the correct syntax for triggering that? Right now, it doesn’t seem to have any effect.
- platform: template
switches:
auto_brightness:
friendly_name: 'Auto brightness'
value_template: "{{ is_state('switch.circadian_lighting_colors_and_brightness', 'on') }}"
turn_on:
- service: switch.turn_off
entity_id: switch.circadian_lighting_just_colors
- service: switch.turn_on
entity_id: switch.circadian_lighting_colors_and_brightness
- service: circadian_lighting.values_update
entity_id: sensor.circadian_lighting_colors_and_brightness
turn_off:
- service: switch.turn_off
entity_id: switch.circadian_lighting_colors_and_brightness
- service: switch.turn_on
entity_id: switch.circadian_lighting_just_colors
- service: circadian_lighting.values_update
entity_id: sensor.circadian_lighting_just_colorsThe service gets called like any other service and doesn’t take any data, so just service: circadian_lighting.values_update without the entity_id should work in regards to that?
Ultimately it looks like you’re trying to have sometimes the color and brightness adjust and other times just color, is that correct?
That is correct. Thanks for your info, I will try.
Hi, does it matter which of this 3 option I choose?
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.