Hello, do you plan to implement custom updater? https://github.com/custom-components/custom_updater
Thank you for answer.
I’ve been considering it, but it seems there’s some push to getting this added as a official component so I’ll likely pursue that first.
2 Likes
Hi,
I have just returned home after a few days, and updated to HA v0.81.6. Unfortunately i am now receiving an ‘Invalid Config’ error on my overview page. I have attached a screenshot of the error.
The Circadian Lighting component is my favorite of all the HA features, so i am a bit gutted i can’t use it at the moment.
Has anyone else had this error and fixed it in 0.81.6?
Thanks
Without logs there’s no way of knowing, but I assume you need the fix from last week, see post 104: Circadian Lighting [Custom Component]
Thank you so much, I really love hearing such positive feedback!
2 Likes
Perfect! I assumed after the update and the issues i have had with MQTT and media components that the update was the issue and that would be enough!
Thank you for putting the hard work and time into this project!
This may be a long shot but would you consider introducing a way to transition the lights from circadian to sleep mode values?
Reason: It’s hard as hell to manage with automations and turning the switch off and on. Would be great if it were built in to the light update function.
@sergi.suarezj, not sure if you saw my post here - I still think the logging could help us troubleshoot but I was able to reproduce the issue in a specific scenario. Do you by any chance send turn_off with a transition, or in general do the deconz lights take a while to fade off? With my Hue lights if I send turn_off to a Hue group with even a relatively short timeout (10 seconds for example) the group initially has an off state in HA but shortly after it updates back to on while the lights fade off. The problem is that with CL when the group switches state in HA back to on CL immediately updates the group, keeping it on.
If this is in fact what’s going on I’m not sure what the best solution would be, to be honest. Every solution I can think of would cause other negative behavior.
Couldn’t you just set interval to something like 1 second?
@claytonjn Yes I know, But I’m travelling right now without access to my HA.
When I’m back at home and do some home work I plan to change my setup and capture the logs you need.
I’m sorry to not letting you know that I was unable to get the logs in a shorter time.
No problem, I realized I didn’t quote you or tag you so I thought you may have missed it!
Ah I think I didn’t explain clearly what I’m trying to do.
It’s got to do with sleep mode and the fade/transition from normail circadian to sleep mode. I’m doing it using a script so I have to turn off the circadian switch then fade the lights then turn it on again.
I would instead ask for a sleep_delay parameter. This delay can be used to update the lights on a 2-3 second interval (sleep_interval?) from normal values (color_temp/brightness) to and from sleep mode values.
I see, so even with a short period it would cause the lights to abruptly change when entering sleep mode. I’ll have to think about this, I do think it’s a good idea but it would add a bit of complexity and I’m worried adding too many configuration options would cause confusion for users.
Hey it’s a feature and you can make it optional, defaulting to 0 second delay (instant update to and from sleep mode values). People who want a gradual change can set a value to have a gradual change.
I see you considered this before as well, in post 22 Circadian Lighting [Custom Component]
I finally did get this great component up & running, however I don’t appear to be getting the color values I would expect and am wondering if I need to tweak something in my config?
I am using Milight RGB bulbs via the MQTT Light platform (this hub https://github.com/sidoh/esp8266_milight_hub/).
When I turned the circadian switch on last night, the lights were deep orange and moved more toward red as it got later. Seemed to be working. However this morning it’s still returning a orange-warm value.
I guess I would expect at 9am for it to be a blue-cool white light, correct? To me eye they appear almost as warm as they were last night at 11pm.
Not a lot of room to get warmer here, this does match the RGB value above from the sensor.
I also noticed if I attempt to set a min_colortemp or max_colortemp it says that is an invalid config option. 5500K seems too warm to me, but I wasn’t able to set it any higher
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.