Thank you for the edited code. I never knew you could double up on the action.
Thanks for sharing this!
I was scratching my head already for some weeks now, why my IKEA lights would sometimes turn on for no apparent reason. Good to know this and how to work around the issue!
Unfortunately it makes the programming harder and harder, working around all these issues 
Excellent work, Iāve been following this custom component for a while now and have only just got around to using it.
Can I ask a feature request.
Can we have the disable_brightness_adjust option configured by time of day and or entity state?
Thanks,
Stu
Hi all,
i just setup this platform but NO lights turn on when i activate the switch
here the config:
circadian_lighting:
transition: 10
interval: 10
- platform: circadian_lighting
name: Circardian Light Downstairs
lights_brightness:
- light.led_strip_living_room
- light.hyperion
- light.gateway_upstairs
- light.gateway
- light.color_lamp_living_room
- light.chill_out_corner
- light.color_lamp_living_room
- light.spots_kitchen
- light.spots_living_room
- light.dining_room
- light.dining_room_lamp_wall
Lights are working properly ā¦ nothing in logs but:
2019-03-29 13:48:10 DEBUG (SyncWorker_7) [custom_components.circadian_lighting] Circadian Lighting Component Updated
2019-03-29 13:48:10 DEBUG (SyncWorker_7) [custom_components.circadian_lighting.sensor] Circadian Lighting Sensor Updated
2019-03-29 13:48:10 DEBUG (SyncWorker_15) [custom_components.circadian_lighting.switch] Circardian Light Downstairs Switch Updated
2019-03-29 13:48:10 DEBUG (SyncWorker_15) [custom_components.circadian_lighting.switch] Circardian Light Downstairs off - not adjusting
and when turning on:
2019-03-29 13:48:54 DEBUG (SyncWorker_18) [custom_components.circadian_lighting.switch] Circardian Light Downstairs Switch Updated
any idea?
Yes, I plan to add this functionality in one way or another. This is something I want to use in my own home so itās definitely a priority. I halted working on CL because I was trying to figure out what would be involved in getting CL mainstreamed for native integration. Unfortunately, itās a bit of a one-off situation and no one was really able to answer my questions, so it looks like CL will stay a custom component for the foreseeable future.
My top priority is refactoring GitHub for the new component structure and adding the necessary files for custom updater. Right now Iām fighting with my HA instance and working on migrating everything to a new server, but in the process Iām also migrating all of my Wi-Fi devices to different VLANs which is quite time consuming.
The CL switches donāt turn on/off the lights, they turn on/off CL adjustment (similar to the native Flux component). You still have to turn your lights on by some other means.
OK Thanks found this out then. I have an automation turning on the lights by turning on the switch
That is a shame but understandable. Hopefully you will get a chance to continue developing the component. It is a brilliant alternative to the flux component.
BTW sorting out my VLANS is on my to do list also, I feel your pain.
What does the component use to adjust the lights? The wife pointed out that when it was overcast outside the lights dimmed. Needless to say she didnāt like it so I had to show her how to toggle the switch. Is there a way to have lights not adjust when its dark outside but not after sundown.
CL only uses sunrise and sunset times for calculation (unless you have overrides set), it does not use weather conditions or anything like that. It would actually go against the core purpose of the component to mimic weather, the whole point is that CL helps your body maintain its Circadian Rhythm and following weather conditions would obviously cause non-rhythmic behavior.
As far as brightness is concerned, CL should stay at max_brightness from sunrise to sunset, then from sunset it will dim down to min_brightness and back up to max_brightness at sunrise.
@claytonjn, I have a question: how do the settings of āintervalā and ātransitionā determine how often a message is sent to a bulb?
FYI, I was having issues with my Tradfri bulbs when I had set interval to 300 and transition to 10.
Now I have set interval to 900 and transition to 120 and the issues seem to have disappeared.
Some bulbs still perform fast transitions (2 secs), but these are performed via the light.turn_on command.
I wonder whether there are significant differences in the amount of communication-actions performed by the circadian switches between the two scenarios?
Interval is how often CL adjusts the configured lights. Transition is simply passed into the service call to the lights, so itās up to the individual component to handle transition - with Hue, for example, thatās handled by the Hue bridge so interval is how often Home Assistant sends a command to each light.
Iām using circadian lighting in combination with zigbee2mqtt and tradfri lights.
Iāve noticed that circadian lighting results in a lot of traffic, actually so much traffic that it becomes problematic for my zigbee network and things become unresponsive.
Does anyone have any tips on how to set for example the transition time such that the traffic is minimized? I wouldnāt mind if the lights get adjusted 4 times per hour with a small transition time as long as it doesnāt cause so much traffic.
I am using groups in zigbee2mqtt already to reduce the traffic as much as possible but unfortunately it still seems too much.
I used the default transition and interval settings for a few months and would notice my lights (Hue and LIFX) adjust every 15ish (never timed it) minutes instead of transitioning smoothly. I recently set both values to 60 and they now transition smoothly (almost unnoticeably) as expected. Any idea why this is? Iām not concerned with debugging it but I figure I must have something setup wrong since it doesnāt correctly work OOTB with 2 major light brands.
@claytonjn, thanks!
I kind of figured that but I wanted to be sure.
So, the larger the interval-value, the lesser the amount of communication-messages, per time unit.
And the transition-value is not affecting this amount.
@TravelinMax, having a too large transition-value will not work for some bulbs, this might cause your issue. Also, interval and transition values donāt have to be equal.
@jlo88, I just realized I did that too: listing groups of lights under the circadian switches instead of individual lights! Thanks, I did not realize that this would help too in lowering the amount of comms messages. Another optimization found!
Circadian Lighting creates a sensor, which makes the calculated color temperature available in the front-end and to all other components. This means that in automation you can program lights to turn on to exactly the right color temperature, eliminating the jump from the color the light was at when turned off to the proper color.
I canāt for the life of me work out how to create an automation to eliminate the jump from my previous set colour to what the Circadian Lighting sensor has for my LifX bulbs, can someone provide a snippet of the code that is required? 
Iām assuming the zigbee2mqtt implementation simply sends incremental adjustments throughout the transition period to simulate a smooth transition. You could probably get away with interval of 300 seconds (5 minutes) and transition of 0 and things would likely be relatively smooth and commands would only go out once per light/group every 5 minutes.
The default interval and transition are both 900 seconds (5 minutes). In theory, this would mean that every 15 minutes CL tells lights to spend the next 15 minutes transitioning. When I first was testing this seemed to work quite well - I have almost exclusively Hue lights.
However, a few months back I was sent a Hue light fixture to test and I installed it above our kitchen table. I have noticed during breakfast time (when the color temperature curve is steepest) that the color temperature adjustment is relatively abrupt (about a 1 second transition and obviously noticeable color shift). In the Hue API, transitiontime is an unsigned 16 bit integer, so maximum transitiontime would be 6553 seconds - 900 is well within the limit in that case, but I suspect that perhaps different lights within the Hue ecosystem have different transitiontime limits.
I had a LIFX lightstrip installed in my soffit above my front porch but it went haywire, blinking and changing colors all throughout the night so that was quickly removed and I donāt have any more experience with LIFX unfortunately.
Anyways, I think that in the next major CL update I will change the default interval to 5 minutes and transition to 60 seconds. I think these settings will be more compatible overall with the variety of lights people have, will reduce commands for some platforms, and will result in smoother transitions in general.
The only thing to keep in mind is that using groups instead of lights can induce some behavior changes. Typically with groups, if one light is on the group is considered on - when this happens, CL will send its adjustment and all other lights in the group will turn on. Itās best to have CL configured the same way the lights are controlled - if you only ever control lights as a group, then add the group to CL. If you sometimes control lights individually then they should be configured individually in CL. For me, if thereās multiple bulbs in a fixture I control those as a group and use that group in CL, but multiple lights in a room I keep as individual lights in CL.
1 Like
I use python scripts for most things, so it looks something like this:
hass.services.call('homeassistant', 'turn_on', { "entity_id" : "light.garage_entry" , "kelvin" : int(float(hass.states.get('sensor.circadian_values').attributes['colortemp'])) , "brightness_pct" : hass.states.get('switch.circadian_lighting_garage_entry_circadian_lighting').attributes['brightness'] })
I honestly donāt remember why I convert colortemp to float and then intā¦
If you wanted to do turn on in a regular script or automation action something like this should work:
action:
service: homeassistant.turn_on
data_template:
entity_id: 'light.garage_entry'
kelvin: "{{ state_attr('sensor.circadian_values', 'colortemp') | int }}"
brightness_pct: "{{ state_attr('switch.circadian_lighting_garage_entry_circadian_lighting', 'brightness') }}"
That sounds like a reasonable explanation, thanks Clayton!