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:
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!
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'
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.
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…
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.
@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!
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.
OOOHhhh it actually just clicked in my mind and this choice does makes sense to me
just FYI my use case : i use one of my bedroom lamps as a wake up light (turns on red at 1 % and over 30 min goes slowly to a warm temp at 100%)
with a circadian switch for the whole house and applied on my hue group “bedroom” it has the effect to turn on all my 3 bedrooms lamps directly at 100% when my wakeup light turns on.
fix i’m gonna try : set a dedicated circadian switch for my bedroom which is disabled by my wakeup automation during 30 mins
.
) in to thank you 