Seems that this is because of (deprecated?) ATTR_WHITE_VALUE parameter. I got mine working again with this first aid. Perhaps a proper patch should be done (this removes the XY mode that I don’t use).
diff --git a/custom_components/circadian_lighting/switch.py b/custom_components/circadian_lighting/switch.py
index 7c5b6cc..6357ab0 100644
--- a/custom_components/circadian_lighting/switch.py
+++ b/custom_components/circadian_lighting/switch.py
@@ -14,7 +14,7 @@ from homeassistant.components.light import (
ATTR_COLOR_TEMP,
ATTR_RGB_COLOR,
ATTR_TRANSITION,
- ATTR_WHITE_VALUE,
+ #ATTR_WHITE_VALUE,
ATTR_XY_COLOR,
)
from homeassistant.components.light import DOMAIN as LIGHT_DOMAIN
@@ -362,10 +362,10 @@ class CircadianSwitch(SwitchEntity, RestoreEntity):
elif light_type == "rgb":
r, g, b = self._calc_rgb()
service_data[ATTR_RGB_COLOR] = (int(r), int(g), int(b))
- elif light_type == "xy":
- service_data[ATTR_XY_COLOR] = self._calc_xy()
- if service_data.get(ATTR_BRIGHTNESS, False):
- service_data[ATTR_WHITE_VALUE] = service_data[ATTR_BRIGHTNESS]
+ #elif light_type == "xy":
+ #service_data[ATTR_XY_COLOR] = self._calc_xy()
+ #if service_data.get(ATTR_BRIGHTNESS, False):
+ # service_data[ATTR_WHITE_VALUE] = service_data[ATTR_BRIGHTNESS]
_LOGGER.debug(
"Scheduling 'light.turn_on' with the following 'service_data': %s",
How do I set up Cercradian lighting only to adjust the color temperature, not the brightness? Let the brightness be determined by the last value or whatever is set by the UI.
I saw a video about light adjustments, which I never really thought of tbh. It showed Circadian and I installed it an it works nicely on my hue and IKEA lamps - well, I installed it today, but hey, it works.
Another reason after a little research (as dumb as it may sound): I prefer having one sensor and a switch for groups rather than having endless entities I’m not using. That’s just me keeping it simple, but still a valid reason for me.
First thoughts on why putting Adaptive Lighting and Circadian together might make sense:
more people working on all the features people like to have
more stability and options to react to HA updates without added workload for both developers
some users may not like the manual work in Circadian while AL has sliders
features such as settings individual for each light rather than main settings in configuration.yaml
All that said: I have no experience in programming other than HA yaml and in no way are trying to tell you what to do! I just saw your question and wanted to give my input.
So far all I can say is thank you for a feature I never knew I needed
Invalid config for [switch.circadian_lighting]: value should be a string for dictionary value @ data['disable_entity']. Got ['input_boolean.sovetid_nora']. (See ?, line ?).
This component was written before frontend integrations UI existed and I thought it would be too confusing to configure multiple entities and their various states in YAML. I actually have regretted adding the disable_[…] options because it’s trivial to create automations that do the same thing and that approach provides significantly more advanced options.
This is expected, the switch will still be on but shouldn’t actually do anything to change the lights. I can’t have the disable_entity actually turn off the switch because when the switch is off there is no way for the switch to turn itself back on (at least that was the case when the code was written) - This is part of why I want to remove this functionality completely; it is a very confusing experience for users.
It’s just a regular switch, so a service call to switch.turn_on or switch.turn_off should be all that’s required.
Hi!
I have IKEA Tradfri RGB GU10’s connected trough ZHA.
I’m noticing something annoying. Each time CL applies the Color temperature, the light dims and then slowly creeps up.
Other types of lights don’t show this behaviour, but I have no idea where to start looking to fix this (drives my wife crazy).
To clear, I have disabled dimming (as I don’t want that).
Do these GU10s do the same thing when you adjust them from the Home Assistant dashboard or with a light.turn_on service call? For the service call, it would be good to test both with and without specifying a transition.
If I remember correctly Adaptive Lighting was basically a fork and upgrade of Circadian Lighting. I started with Circadian Lighting and moved across to Adaptive.
A couple years ago basnijholt made a bunch of great contributions to Circadian Lighting and then wanted to get it added as an official integration (which I have also wanted but had been unsuccessful with previously because it doesn’t really fit with the “master plan” for Home Assistant). As part of the work to get it officially supported, basnijholt created Adaptive Lighting and made a bunch of changes, including moving to UI Integration configuration, which I have not had time to implement. I don’t know what other differences there are with respect to features/behavior - the adjustments of lights is one of the single-most important features of my home automation and CL is tailor made for my use-case (while also trying to support as many features for other users as possible) so I have never considered switching to Adaptive Lighting.
hey clayton, thanks for sharing this with us. i’m really enjoying using circadian lighting to keep the brightness/color temp of my lights managed throughout the day for maximum effectiveness!
one thing i was wondering about - would it be possible to pull in outside brightness levels from a sensor, and use that to determine the brightness? i have an AmbientWeather weather station that reports solar radiation in lux and in W/m², and would like to be able to leverage that instead of the time-of-day calculations, as this would also take the weather into account (i.e. if there’s a storm that’s making it darker than normal outside for this time, the lights can stand to be a little dimmer than the time between sunrise/sunset would suggest).
This has been requested before and I haven’t added this functionality for two reasons:
It would take a while for me to extrapolate a brightness percentage to set lights from a lux value, and whatever I choose for my location probably wouldn’t translate well to other locations. I could make this configurable but that adds more complexity to a system that already has a confusing amount of settings.
The main function of the integration is to maintain a consistent circadian cycle for personal wellness (e.g. I’m prone to migraines and having the lights adjust color temperature and brightness in a consistent way has significantly reduced how frequently I get them). Adjusting based on lux would make the lights better align with outside conditions, but would also make them less consistent as day-to-day the behavior would change based on weather conditions.
I’m not completely disregarding this feature request, but that’s my reasoning for not adding it yet.