Circadian Lighting [Custom Component]

Share your Projects! Custom Integrations
286

I was thinking something more like this:

The problem is convincing the front-end devs that something like that should be accepted as an official entity row.

1 Like
287

I have two lights controlled by circadian_lighting. However I only want one light to have disable_brightness_adjust: true. Is this possible? I tried adding a second circadian_lighting platform switch but seems HA only uses the first one.

EDIT: in order to get this working, you must define a unique name for each switch.

288

You have to set up a second switch, not a second platform.

289

My brightness stays at: 100. during the day. Did i miss somthing. Here is my config

circadian_lighting:
  interval: 60
  transition: 3
switch:
  - platform: circadian_lighting
    min_brightness: 18
    max_brightness: 100
    lights_ct:
      - light.milight_diningroom_1
    name: diningroom
290

It’s only supposed to dim at night. Is your switch turned on? IE: switch.circadian_lighting_diningroom

291

Hi, thanks for a truly great plugin!

I have a really strange issue though. I have a lot of automations using node-red and I have found that when I have an automation that sets a specific brightness to a light when turned on, the circadian lighting plugin cannot budge it. However the brightness indicator in the interface says that the brightness is as expected (255 for example).

To take an example. I have a motion sensor in my bathroom that turns on the light to brightness 100 if the state of the bathroom light was off. Simple.

However, in this case I would expect that circadian lighting would take over and dim the light to the appropriate lighting level (255 for the middle of the day). BUT this does not happen. The interface is updated to say that the light is at 255 brightness, but the light itself is not changed. And if I use the dimmer in home assistant, to change the brightness to like 99%, the lights very briefly brighten before being returned to the start.

The reason why I believe this to be a bug in your component and not in Home assistant is that no other thing behaves this way. This exact automation has been running in combination with dimmers etc without issue, and there has been no issue with the interface not showing the actual dimmed value.

If I change my automation to NOT specifically append brightness when turning on the light, everything behaves as expected. and also, strangely if I dim using my wall dimmer it also starts working (i.e. dimming while the light is on). This only seems to be an issue when the light is started with a set brightness.

As new users only can upload a single image, I have concatinated the three images I originally attached:

To the left is a working example:

To the right is the non working example, where I set brightness explicitly on trigger:

At the bottom is the entire node red flow, if that’s interesting, it’s the top svc: light:turn_on node that is showing:

image
image2786×2044 685 KB

This is an issue with all my automations that set the brightness this way, not just this specific one, but it was the easiest to explain. I really would like this to work with a set brightness, since I would like to default to a low brightness to avoid blinding someone in the middle of the night if the previous brightness was high on a lamp that is not used often.

My home assistant version is 0.84.5, and I know it’s not the latest, but I really need to prepare before updating to the lovelace ui, as I’ve heard that many people are having issues with their old config.

Again, thank you so much for this component, it is really striking, but this issue is driving me mad, and I truly hope you have some insight into what could be the issue!

Below I’ll attach the JSON for my node red nodes if that is useful:
[{"id":"2023a3a9.ab1d8c","type":"api-call-service","z":"f0f89a8e.bd0bc8","name":"","server":"8ad07cbe.ddf6","service_domain":"light","service":"turn_on","data":"{\"entity_id\":\"light.lower_bathroom_ceiling\",\"brightness\":100}","render_data":false,"mergecontext":"","x":1015,"y":2500,"wires":[[]]},{"id":"24a8387d.4e0bc8","type":"api-current-state","z":"f0f89a8e.bd0bc8","name":"Only turn on if off","server":"8ad07cbe.ddf6","halt_if":"on","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"override_payload":false,"override_data":false,"entity_id":"light.lower_bathroom_ceiling","state_type":"str","x":615,"y":2500,"wires":[["2023a3a9.ab1d8c"]]},{"id":"1c896d7b.1be5f3","type":"switch","z":"f0f89a8e.bd0bc8","name":"on/off","property":"payload","propertyType":"msg","rules":[{"t":"eq","v":"on","vt":"str"},{"t":"eq","v":"off","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":335,"y":2560,"wires":[["618024e.24ccddc","24a8387d.4e0bc8"],["6357a7ef.15c698"]]},{"id":"3c040d05.814b42","type":"server-state-changed","z":"f0f89a8e.bd0bc8","name":"Lower bathroom entrance","server":"8ad07cbe.ddf6","entityidfilter":"binary_sensor.lower_bathroom_entrance_motion","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","x":115,"y":2491,"wires":[["1c896d7b.1be5f3"]]},{"id":"618024e.24ccddc","type":"change","z":"f0f89a8e.bd0bc8","name":"Inject stop","rules":[{"t":"set","p":"payload","pt":"msg","to":"stop","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":595,"y":2560,"wires":[["21885c07.4f6664"]]},{"id":"6357a7ef.15c698","type":"api-current-state","z":"f0f89a8e.bd0bc8","name":"Sensor state toilet","server":"8ad07cbe.ddf6","halt_if":"on","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"override_payload":false,"override_data":false,"entity_id":"binary_sensor.lower_bathroom_toilet_motion","state_type":"str","x":510,"y":2620,"wires":[["f0f66891.572a58"]]},{"id":"4c297892.c61368","type":"inject","z":"f0f89a8e.bd0bc8","name":"","topic":"","payload":"on","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":115,"y":2620,"wires":[["1c896d7b.1be5f3"]]},{"id":"b86f01ab.e3b8f","type":"inject","z":"f0f89a8e.bd0bc8","name":"","topic":"","payload":"off","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":115,"y":2660,"wires":[["1c896d7b.1be5f3"]]},{"id":"e677c52a.d89af8","type":"server-state-changed","z":"f0f89a8e.bd0bc8","name":"Lower bathroom toilet","server":"8ad07cbe.ddf6","entityidfilter":"binary_sensor.lower_bathroom_toilet_motion","entityidfiltertype":"exact","outputinitially":false,"state_type":"str","haltifstate":"","halt_if_type":"str","halt_if_compare":"is","x":105,"y":2540,"wires":[["1c896d7b.1be5f3"]]},{"id":"21885c07.4f6664","type":"stoptimer","z":"f0f89a8e.bd0bc8","duration":"1","units":"Minute","payloadtype":"num","payloadval":"0","name":"","x":940,"y":2580,"wires":[["a1566272.93c25"],[]]},{"id":"f0f66891.572a58","type":"api-current-state","z":"f0f89a8e.bd0bc8","name":"Sensor state entrance","server":"8ad07cbe.ddf6","halt_if":"on","halt_if_type":"str","halt_if_compare":"is","override_topic":false,"override_payload":false,"override_data":false,"entity_id":"binary_sensor.lower_bathroom_entrance_motion","state_type":"str","x":740,"y":2620,"wires":[["21885c07.4f6664"]]},{"id":"a1566272.93c25","type":"api-call-service","z":"f0f89a8e.bd0bc8","name":"","server":"8ad07cbe.ddf6","service_domain":"light","service":"turn_off","data":"{\"entity_id\":\"light.lower_bathroom_ceiling\"}","render_data":false,"mergecontext":"","x":1195,"y":2614,"wires":[[]]},{"id":"8ad07cbe.ddf6","type":"server","z":"","name":"Home Assistant","legacy":false,"hassio":false,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open"}]

292

Have you tried turning on debug logging for Circadian Lighting, and if so, is the behavior different between when you do and do not set brightness in Node-RED?

Also, to confirm, you want Node-RED to turn the lights on at 100, then CL to adjust them immediately?

293

Thank you for your swift response. Unfortunately after enabling debug mode I can no longer replicate the issue. I’ll have to try again tomorrow, perhaps this is just an issue during the day (when the light levels are > 250) or something. I’ll try to check before work tomorrow, but worst case I work from home on friday.

Yes that is correct! 100 is just an arbitrary number, so it’s probably lower (like 1) at least for some lights.

294

Upon further research I realised that my error description was entirely wrong.

I can reproduce the issue just using home assistant and the brightness sliders. To reproduce:

  1. Turn off the Circadian Lighting switch
  2. Turn on the light at a set brightness, for example 1
  3. Turn off the light
  4. Turn on the Circadian Lighting switch
  5. Turn on the light
  6. Expect that the light adjusts. But in reality nothing happens and the light remains at brightness 1. However the slider in home assistant reflects the expected value of ~20%

Debug log says:

2019-02-26 20:43:22 DEBUG (SyncWorker_1) [custom_components.switch.circadian_lighting] light.lower_bathroom_ceiling CT Adjusted - color_temp: 400, brightness: 61.777598968505856, transition: 1
2019-02-26 20:43:22 DEBUG (SyncWorker_18) [custom_components.switch.circadian_lighting] light.lower_bathroom_ceiling CT Adjusted - color_temp: 400, brightness: 61.777598968505856, transition: 1

I am using the Deconz-integration in home assistant to control my trÄdfri-lights.

295

So according to CL it should have adjusted. CL uses the same service call to adjust the lights as the front-end (and everything else) so try this:

  1. Turn off the Circadian Lighting switch
  2. Turn on the light at a set brightness, for example 1
  3. Turn off the light
  4. Turn on the light
  5. On the dev-service page call the light.turn_on service with this service data:
{
  "entity_id":"light.lower_bathroom_ceiling",
  "color_temp":400,
  "brightness":61.777598968505856,
  "transition":1
}

The only thing I can think of is maybe Deconz doesn’t like non-integer brightness - the front end thinks the light changed due to the service call, but the light never actually adjusts. Try the above and let me know the result.

296

Ah, I think I found the issue! It seems that either Home assistant, or Deconz, or TrÄdfri cannot change both brightness and color in the same command

{
  "entity_id":"light.lower_bathroom_ceiling",
  "brightness":100.777598968505856,
  "color_temp":200,
  "transition":1
}

Does not work
However

{
  "entity_id":"light.lower_bathroom_ceiling",
  "color_temp":200,
  "transition":1
}

Followed by

{
  "entity_id":"light.lower_bathroom_ceiling",
  "brightness":100.777598968505856,
  "transition":1
}

Works brilliantly! Is a “dual step” something that could be a mode or something? I really don’t know how to track this issue further to the source!

297

Hmm, this seem to explain the issue at hand:

298

Sorry for the spam, but I found some kind of workaround:

{
  "entity_id":"light.lower_bathroom_ceiling",
  "brightness":25.777598968505856,
  "color_temp":100,
  "transition":0
}

Works fine, but is a bit
 choppy (as expected)

Edit:
So by modding the code to set the “on demand transition” to 0 instead of 1 on line 332, it works, albeit very choppily when “transitioning”. I suspect there would be som reworking needed to make it transition “pretty”. As far as I understand it TrĂ„dfri can only do one thing at a time, and that includes transition times, so it would have to do it a bit more involved


Thanks for your help in troubleshooting this! If you have any idĂ©as in how to implement a “trĂ„dfri compatible” fade, that would be much appreciated and would make my setup work a lot better, but as for now it at least kind of works :slight_smile:.

1 Like
299

I’m glad you got to the root of the problem! Certainly there are many possible options to fix this, but from the CL side of things it would basically require looping say 100 times with no transition and changing brightness 1/100th each time. While possible, there are some big drawbacks to this approach. CL can only control things through the standard hass.services.call. Every time that happens there are multiple things occurring, including: writing events to the event buss, updating states to the db, and potentially triggering other automations, etc. So if CL implemented such a workaround all that would happen times 100 for each light that’s adjusted.

The real solution, ultimately, needs to be implemented in the component that actually registers the entity (in this case Deconz).

By the way, you could pull the brightness attribute directly into Node-RED so that when it first turns on lights CL doesn’t have to re-adjust. CL would still control adjusting them throughout the day but in the initial turn_on they wouldn’t be at one level and then change :wink:

300

Yeah, it seems like it has to be solved properly at the Deconz level, however since the updates occur so frequently it would be possible to allow for example instead of doing a 15 minute brightness and color transition, you could do a 7 minute color transition followed by a 7 minute brightness transition. I think the results on the end user would not be very different, but of course it would require a bit of rework of the code. I don’t know how many TrĂ„dfri users are using your component, but some kind of workaround would probably be needed in this case.

However, if this issue is not present if the user is using the TrÄdfri gateway, the user base having this issue will be a lot smaller. Though as far as I understand the problem originates at the firmware level so I would suspect that the TrÄdfri gateway is also susceptible.

By the way, you could pull the brightness attribute directly into Node-RED so that when it first turns on lights CL doesn’t have to re-adjust. CL would still control adjusting them throughout the day but in the initial turn_on they wouldn’t be at one level and then change

Yeah, this is how I do it! A feature request would be to have both values at the sensor level, because now I have to fetch the brightness from a switch, but the temperature from the sensor, and if the switch is off (due to scenes overriding it etc) I get no brightness data. It seems that the brightness data is the same across all switches so it would make sense that it could be implemented.

I could of course make a “dummy switch” for a dummy light, but that seems a bit non-elegant. :smiley:

Also the possibility to “adjust” the brightness level for weaker lights would be really useful, for example I have a floor lamp with two weaker 400 lm lights as the main lighting in the dining room, that I would like to shine at the same brightness as the 1000lm ceiling lights in the other rooms to get the same observed brightness across the house. But due to that the brightness is set the same no matter the lumen output of the light or the dimming properties of the fixtures, the light in the dining room becomes very dark in the evening.

A “brightness offset” signed integer value for a switch could be a solution for this as lamp shades etc make it impossible to gauge the actual lighting effect of a set brightness percentage. This would require some tinkering by the end user, but could be very useful to get an even brightness across different fixtures.

Thanks again for your help in troubleshooting this issue and for making this component! Hopefully any other TrÄdfri users will see these posts and know what to do.

301

The Tradfri issue is actually at the bulb firmware level, not in deconz. The bulbs don’t support changing both brightness and CT in the same call, so deconz splits the call into two. That leads to a second issue where requesting a brightness change with a transition time followed by a CT change with a transition leads to one of the requests getting clobbered


As a workaround, if you define two Circadian switches, one to handle brightness and one to handle CT, with a shortish transition (like 10 seconds) and duplicating bulb references as needed, it all works pretty well


circadian_lighting:
  min_colortemp: 2000
  max_colortemp: 4000
  transition: 10

switch:
  - platform: circadian_lighting
    name: Circadian Colour
    lights_ct:
      - light.bedside_lamps
      - light.living_room_spot_lamps
      - light.bathroom_lights
      - light.office_light_2
    disable_brightness_adjust: true
  - platform: circadian_lighting
    name: Circadian Brightness
    lights_brightness:
      - light.bedside_lamps
      - light.living_room_spot_lamps
      - light.bathroom_lights
      - light.office_light_2
      - light.kitchen_lights
      - light.hall_lights

As an aside, if you are using deconz you should set up light groups in the Phoscon app and not use HA Light Groups. It works much better when deconz can just broadcast a single ZigBee message to a group id, rather than HA calling each bulb individually through the REST api


2 Likes
302

The brightness data actually isn’t necessarily the same across all switches. In the switch configuration you can define a minimum/maximum brightness. I implemented it like this for two reasons:

First, some lights (my Haiku ceiling fan light for example) have limited brightness adjustments - the Haiku light goes from 1-10. So when brightness it sent from a 1-100 (or actually 1-255) scale, anything below 5 rounds down to 0, thus turning off the light. Therefore, my min_brightness has to be above 5 for that CL switch, but my max can stay at 100.

The second reason is the other issue you described, where some lights are not as bright as others. If you have one light that’s 50% dimmer than another, for example, you could have the CL switch for the dimmer light go from min_brightness 50 to max_brightness 100 and you could have the brighter light go from 1-50. If I had implemented an offset as you described it would run into issues at the extremes - a light can’t go brighter than 100 or dimmer than 1 so at one end or another the lights would still be differing brightness.

Minute differences in brightness does not have the same effect on the body (from what I can tell) as color temperature does, which is why I enforce a single color temperature for all lights but allow differing brightness for each CL switch. So, while brightness is the same for all CL switches by default, as you could see from my examples above that is not necessarily the case.

304

Thanks for posting this. I’m trying these settings now with my Tradfri bulbs. This also seems to fix my other issue, where the lights would not immediately respond when the circadian switch is activated. As you said Tradfri cannot accept brightness & colortemp in the same call, so perhaps separating them like this fixes that.

For Tradfri, these settings seem optimal. Nice!

305

edit: post edited (removed), because I’m just dumb.

The issue I was facing was due to an incorrect timezone in HA configuration. I guess, when you’re cleaning up you docker compose file, make sure to use correct values for your .env file :stuck_out_tongue_closed_eyes:.

Cheers

306

I was trying to work out for the last month why my automation to change my Tradfri (using the Tradfri hub I may add) brightness and temperature at the same time results in nothing happening since I added a transition!

I’ll try changing the automations to change brightness first and then colour to see how it goes!

I’m not using Circadian Lighting yet but I’m really glad I’m nosy!

Thanks!