Yes, I do think that’s a good idea, but I was still going to use the turn_on service call transition, not implement my own. Using sleep like in the example you provided is blocking and holds up the process while it wait, so that would have a negative impact on performance. I’m almost positive the component wouldn’t even be considered for official integration if that were there. I’m still thinking about it and will try to come up with a good solution but ultimately I think that should really be fixed at the device level.
Something’s definitely not right, the state of the sensor should never be below -100% as it shows in your screenshot, and it should be cyclic like in the pictures in the second post. I don’t see anything wrong from the attributes, but it might help if you post your configuration.
It depends. The main difference between this and the Flux component is that CL mimics natural light behavior more closely, so where Flux transitions from cool to warm from morning to evening, CL should go from warm at sunrise to cool at noon and warm again at sunset. So if the sun rose at lets say 4am and sets at 4pm where you are then I would expect the lights to be quite cool at that time. If however sunrise/sunset is at 8am/8pm where you are then they should be pretty warm still.
Can you show me an example config with the values you’re trying to use?
Also, might not hurt to turn on debug logs so I can help troubleshoot - here’s how you have to set configuration.yaml:
logger:
logs:
custom_components.circadian_lighting: debug
custom_components.sensor.circadian_lighting: debug
custom_components.switch.circadian_lighting: debug
Interesting I’m looking at it now and it’s at -155%. Will report back when I get a chance to look into it.
Yeah that’s perfect (using turn_on). I shouldn’t have linked to that script. Setting a shorter interval in the component config will work just fine.
Hey @claytonjn - your component is pretty rad man. Thank you!
Do you have an examples of how the following might be possible:
- Default to “correct” color temperature and brightness upon powering on hue lights with a physical switch (e.g., the light receiving mains power). I wasn’t sure if this could be done with a sensor, for example.
- Setting sleep state for a period of time based off of a hue dimmer switch button press example: press a button to go to sleep, resume default behavior at next sunrise, or when button is pressed to wake up, whatever comes first
- Setting disable state for a fixed period of time example: press a hue dimmer switch button to disable CL adjustments for a temporary period of time, or until they are turned off again, for only those lights that were adjusted by the dimmer switch
Perhaps some of these would be possible with the scene support you mentioned in your original post, but I’m still in learning mode here, so I wasn’t sure 
.
All the best, and thanks for all the work on this!
-Adam
This component “listens” for when a configured light changes state to on, so if the CL switch is on as soon as HA knows the light is on it will adjust. It really depends how quickly the bridge picks up that the light is online because no adjustments can be made until then. In my experience HA updates within milliseconds of the bridge updating so the real delay will be the bulb re-joining the Zigbee mesh. My best recommendation is keep “smart” bulbs hot at all times and if you want to maintain traditional switch control use the Hue tap or dimmer, or hold off for the upcoming “Friends of Hue” switches.
I think the best way to do this would be to have a input_boolean that you control with an automation - I don’t want to complicate things too much and make the component too daunting for new users, and this behavior can definitely be accomplished with the current feature set. Basically; define an input_boolean, configure it as the sleep_entity in CL; create an automation to set input_boolean when sleep button is pressed and unset at next sunrise or when button is pressed again.
Again, you should be able to accomplish this with automations and an input_boolean or just turning the CL switch off/on.
This worked for a day after installation, but for some reason after a restart, it’s no longer working.
Here’s the error:
Error during setup of component circadian_lighting
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/setup.py", line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/homeassistant/.homeassistant/custom_components/circadian_lighting.py", line 88, in setup
conf = config[DOMAIN]
KeyError: 'circadian_lighting'What does your configuration.yaml look like? You have entries for both the circadian_lighting component and the circadian_lighting switch?
I feel so stupid, I must have overwritten it by accident. In case anyone makes the same dumb mistake, I missed the
circadian_lighting:
In my configuation file. Thanks for catching that for me. 
Sorry for the delay.
Here are the logs
2018-11-23 10:26:49 DEBUG (SyncWorker_10) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:50 DEBUG (SyncWorker_12) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:51 DEBUG (SyncWorker_3) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:51 DEBUG (SyncWorker_7) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:51 DEBUG (SyncWorker_5) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:51 DEBUG (SyncWorker_14) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:52 DEBUG (SyncWorker_17) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:52 DEBUG (SyncWorker_15) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:52 DEBUG (SyncWorker_9) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:26:52 DEBUG (SyncWorker_10) [custom_components.switch.circadian_lighting] light.taula CT Adjusted - color_temp: 187, brightness: 255.0, transition: 1
2018-11-23 10:27:06 DEBUG (SyncWorker_12) [custom_components.switch.circadian_lighting] light.light_17 CT Adjusted - color_temp: 187, brightness: 242.25, transition: 1
2018-11-23 10:27:06 DEBUG (SyncWorker_19) [custom_components.switch.circadian_lighting] light.light_18 CT Adjusted - color_temp: 187, brightness: 242.25, transition: 1
2018-11-23 10:27:06 DEBUG (SyncWorker_2) [custom_components.switch.circadian_lighting] light.light_17 CT Adjusted - color_temp: 187, brightness: 242.25, transition: 1
2018-11-23 10:27:06 DEBUG (SyncWorker_6) [custom_components.switch.circadian_lighting] light.light_18 CT Adjusted - color_temp: 187, brightness: 242.25, transition: 1
Light.taula fails to turn off for at least 10 attempts (single bulb)
Light17 and 18 are a group and turns on/off perfectly
I don’t see much difference between them. Both come from deCONZ hub. Now the only bulb failing is light.taula
Thanks
Is there a way to make this component obey the min and max mireds of a light if it is set in customize? It appears that the only affect setting a min or max mired value has is on the slider in the UI. This component will still set the value significantly higher if able and for some RGB bulbs or light strips this results in a very very orangish yellow color light. Much more so than my bulbs that only adjust color temp.
Hi @claytonjn, Thanks for the awesome component!
I do however have a little bug, it seems that in the night, when the calculated switch brightness gets below 0,5000000, it still passes this value in the event that a light gets turned on, but because the code states that the brightness is > 0 it passes the value on (instead of using the 1% default), which then gets rounded to 0, which then turns my lights back off again…
I dont know if i’m on to something here, can you have a look? it might be something else, but i have a hunch that its a rounding issue…
Thanks again!
Hi @claytonjn; again, thanks for a fantastic component. I’m new to Hass.io but this is the first custom component installed / configured and its great for sensible lighting levels of an evening.
Just to add to the discussion; I have the same issues as @sergi.suarezj… Any component which takes a noticeable time to transition ( i.e. ZWave Command ( Off) -> ZWave Command Acknowledged (Off) ) the Circadian Switch is polling / updating during this transition and setting a new Brightness level overriding the Off command. Or so it seems! 
If you need logs etc let me know but I’m pretty confident this is the issue. For items I can I have set the transition to Zero and they have no issue… A cheaper ZWave bulb which I can’t reduce the transition any lower just dims and then goes back to previous brightness.
Alex
@claytonjn
Wow, all I can say is this custom component is simply amazing!
It was easy to set up and works like a charm.
My RGB bulbs & LED strips now have a real purpose for existing. 
Thank you very much for sharing it with the community!
Hey all, just wanted to let you know I’ve been reading all the posts and thinking about the issues with transitions. I haven’t had a lot of time to work on this but didn’t want you to think I’ve forgotten!
4 Likes
Hai there
Just noticed something silly…
the sensor component doesn’t return the brightness value !
Only value missing for some of my node-red automations
Should be a really quick fix, right ?
Hi @pixeye33, I’m pretty sure that the current calculated brightness is an attribute on the switch, so you should be able to get it from there.
Hello,
Yes i know it’s on the switch (and did that to wait for the fix)
but why can i get the rgb/xy value but not the brightness on the sensor component ?
i do believe that all the values calculated or set for circadian should be on the sensor component and should not be exposed as attributes on the switch.
This is not a bug, it is done intentionally. The reason there are multiple switches is that you can define different behavior for different sets of lights - therefore, brightness may not be the same for all lights and it can’t be in the single sensor. Color temperature on, the other hand, is in the sensor because the whole point of this component is that all lights match color temperature and therefore it should be the same for all lights.
1 Like