Yes, indeed, also thanks from me.
Recently, I am having problems with my Tradfri-bulbs, lights would stop responding, communication errors in the HA-log, only a restart would resolve the issue. Happened several times a day, when the lights were on. And no obvious solution available on the interwebs.
After reading your post, I decided to switch off the Circadian components: no more occurrences since then.
Now I’ve made the modifications that you suggested, let see what that brings…
I still have the issues you describe, Tradfri lights becoming unavailable several times a week. I am thinking about building a separate sensors and automations. Circadian lighting component just doesn’t seem compatible with Tradfri.
I haven’t seen the errors return, but only one day has passed.
@ claytonjn, could it be that the switch-commands are send too quickly following each other? Any way to put some delay in-between the messages?
Do you mean, if you have a light configured under two individual CL switches, to add a delay between the two CL switches calling the adjustments? Off the top of my head I can’t think of a good way to implement that. The way the architecture works now, every interval the sensor calculates updated values and then sends a “broadcast” which the switches listen for and then execute. This keeps all of the switches (and therefore lights) in sync. I suppose I may be able to add a configuration option for a delay at the switch level but that would make an already complicated configuration even more so. I also can’t do that until I make CL run async, which is not something I have experience with so it will take some time.
I meant it more in general; that every message sent by any circadian switch should be sent with some time in-between. It was just an idea. I can very well imagine that your don’t want to do this in your code.
If the problem is in the timing of the messages, it should be solved somewhere deeper in the HA-code.
Hello, i really like this project. However i would like a different behavior, like fixed cold light during the day then slowly transitioning to fixed warm light during sunset time. Would it be possible to add a multiplying value so the value gets saturated to the max cold light? So for example if you have 1 you will get the standard behaviour but if i put 10 or 100 the values go saturated to a fixed light during day and night.
What you’re describing is basically the complete opposite of what this component does, have you looked at the native Flux component?
Oh shit, I’ve been troubleshooting this issue for a while now, thought it had something to do with my recent expansion of the system (I bought more tradfri lights a while ago, around the same time I started using this component). I have experienced a lot of weird glitches in the last few weeks, lights getting unresponsive, lights not turning off properly (even though they are marked as off in deconz and HA). Did the split method alleviate the issues for you? If so I’ll try that and see if it helps for me as well.
During a week of testing with the split method, the problem happened again 2 times.
At best, the occurrence of the problem has lessened, I think. But it is definitely not gone, in agreement with the reporting by @Emphyrio.
I built my own circadian colortemp sensor and automation. Just colortemp, no brightness adjustments. The issue of Tradfri becoming unavailable is also present this way. So the Tradfri problem is not connected to this Circadian Lighting component.
Perhaps we should stop hijacking this thread and continue the discussion in a new topic?
Yes, agree, now that we are sure that the issue is not caused by the circadian component, we should take the discussion elsewhere. I suggest we do it here: https://github.com/ggravlingen/pytradfri/issues/205
I think there is an error loading the sensor component now. Also the folder structure of the component needs to be changed to comply with the new format.
Thu Mar 21 2019 09:41:25 GMT-0500 (Central Daylight Time)
Error loading custom_components.circadian_lighting.sensor. Make sure all dependencies are installed
Traceback (most recent call last): File "/usr/src/app/homeassistant/loader.py", line 166, in _load_file module = importlib.import_module(path) File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 962, in _find_and_load_unlocked ModuleNotFoundError: No module named 'custom_components.circadian_lighting.sensor'; 'custom_components.circadian_lighting' is not a packageUpdate: never mind, I got it to work 
When looking in your code I realized you’re sending default light.turn_on commands with the calculated parameters to the involved bulbs.
So, now I send one single light.turn_on command with a short transition-time every time I want the lights to transition fast, one single time. After that, the corresponding circadian switch takes care of the rest.
@claytonjn; is there a way to temporary override the transition value via the circadian_lighting.values_update service?
I tried this:
- service: circadian_lighting.values_update
entity_id: group.kitchen_lights
data:
transition: 5
But it has no effect.
Hi Bouwe, I don’t quite understand what your solution is. How does it help the Tradfri issues of disconnecting etc? Can you elaborate a bit? Thanks!
Actually, what I wanted to achieve and what my question was about, has, I hope, nothing to do with the Tradfri issues.
I have a group of Tradfri-bulbs that I am switching between to circadian-switches, one with a low-brightness (= 1) setting and one with a higher brightness settings range (30 to 70). The high-brightness-range-switch must be on when someone is in the area. The low-brightness-range-switch is on when it is dark and no one is in the area.
During the evening, when the switch between the two “profiles” happens frequently, I want the brightness of the bulbs to transition quite fast, because of that, I have set the transition-value for circadian to 5.
As I did not like this, I want to set the transition-value to e.g. 300, I wanted to temporary set the transition-value during every switch between the two brightness-profiles to a much lower value: 2.
After looking around in Claytonjn’s code, I got an idea how to do this, using the light.turn_on service.
About the Tradfri issues, I was wondering, is me using the Circadian component, causing the issues to occur? Particularly, are the low settings that I use for interval and transition, causing the issues? That’s another reason for me to try and find this solution.
For anyone interested in the implementation, this is my automation to switch the bulbs off during daytime and to low brightness during evening:
alias: Keuken lampen uit door keuken sensor
trigger:
- entity_id: binary_sensor.motion_sensor_xyz
from: 'on'
platform: state
to: 'off'
condition:
- condition: state
entity_id: input_boolean.k_lights_on_k_sensor
state: 'on'
action:
- data:
entity_id:
- switch.circadian_lighting_tradfri_gu10_clr
- switch.circadian_lighting_tradfri_gu10_br
service: switch.turn_off
- data:
entity_id:
- switch.circadian_lighting_tradfri_gu10_dimmed_clr
- switch.circadian_lighting_tradfri_gu10_dimmed_br
service: switch.turn_on
- delay:
milliseconds: 500
- service: light.turn_on
entity_id:
- light.tradfri_bulb_8
- light.tradfri_bulb_9
- light.tradfri_bulb_10
- light.tradfri_bulb_11
- light.tradfri_bulb_12
data:
brightness: 1
transition: 2
- delay:
milliseconds: 1000
- data:
entity_id: input_boolean.k_lights_on_k_sensor
service: input_boolean.turn_off
- condition: and
conditions:
- condition: state
entity_id: input_boolean.k_lights_on_other
state: 'off'
- condition: state
entity_id: input_boolean.k_lights_on_by_entering
state: 'off'
- data:
entity_id: input_boolean.k_lights_off_by_autm
service: input_boolean.turn_on
- data:
entity_id: group.kitchen_lights
service: homeassistant.turn_off
I also have an automation to switch the lights on, the light.turn_on service in that one looks like:
- service: light.turn_on
data_template:
entity_id:
- light.tradfri_bulb_8
- light.tradfri_bulb_9
- light.tradfri_bulb_10
- light.tradfri_bulb_11
- light.tradfri_bulb_12
brightness: >
{{ (((state_attr('switch.circadian_lighting_tradfri_gu10_br','brightness')/100)*256)-1)|int}}
transition: >
{{ 2 }}
I am using several other interlinked automations, that is the reason for all the input_booleans.
How are you using this in automation’s. My automation’s trigger the lights wot turn off if I have the switch for the lights turned on the automation can not turn off the light. Is there a way around this to use this component?
The issue occurs when a light is turned off but the state isn’t reflected immediately in HA; in that case CL thinks the lights are still on and should be adjusted. There’s also a worse situation I’ve seen where a light is turned off in HA which causes the state to immediately go to off, but then the state reverts back to on until the light confirms the off state. This is an issue because CL immediately adjusts when a light is turned on so CL thinks the light is on and adjusts it, turning it on.
I have a variety of lights in my HA setup. With Hue, as soon as HA, the Hue app, Google Assistant, or the Hue switch/motion sensors turn off a bulb, it is reflected immediately in HA - therefore, there’s never an issue with CL. With Lightify, Zigbee, etc. integrations, however, I often experience both of the above situations. My solution is simply to have Automations turn off the CL switch before turning off the light(s) and then turn the CL switch back on before turning the light on.
Unfortunately there’s not much else that can be done. In the ~4 years I’ve had “Smart Home” devices I’ve come to the realization that cheaper solutions often mean a lot more work and a lot of compromises. This is obviously not always the case, but Hue is a great example - they’re expensive, but I’ve never had a single bulb fail, not turn on, or act up in any way. So rather than going out and buying a bunch of cheaper lights for the whole house I’ve decided to save up and slowly add Hue lights as I can afford them (and replace all other “smart” lights with Hue). I know there’s vastly different opinions on “premium” vs “cheap” solutions, but that’s just my $0.02.
Thank you for the info. Do you have an example of the automation you use to turn on and off the switch?
Guess I need some type of delay or pause to use.
- alias: CL Turn Kitchen lights
initial_state: True
trigger:
platform: state
entity_id: group.kitchen_motion
to: 'on'
action:
- service: switch.turn_on
entity_id: switch.circadian_lighting_kitchen_lights
- alias: CL Turn off kitchen lights
initial_state: True
trigger:
platform: state
entity_id: group.kitchen_motion
to: 'off'
for:
seconds: 45
action:
service: switch.turn_off
entity_id: switch.circadian_lighting_kitchen_lights
Here is my motion automation I use for my kitchen.
I switched the entities to fit the CL automation
You should be able to just do
- alias: CL Turn Kitchen lights
initial_state: True
trigger:
platform: state
entity_id: group.kitchen_motion
to: 'on'
action:
- service: switch.turn_on
entity_id: switch.circadian_lighting_kitchen_lights
- service: light.turn_on
entity_id: light.light
- alias: CL Turn off kitchen lights
initial_state: True
trigger:
platform: state
entity_id: group.kitchen_motion
to: 'off'
for:
seconds: 45
action:
- service: switch.turn_off
entity_id: switch.circadian_lighting_kitchen_lights
- service: light.turn_off
entity_id: light.light