Circadian Lighting [Custom Component]

Share your Projects! Custom Integrations
82

Hello,

Sorry - I’m probably being a bit dense but what format should the sunset offset be? Everything I’ve tried so far has led to errors…

Thanks!

1 Like
83

You should be able to do “2:30” for a two and a half hour offset, for example. What offset are you trying to accomplish?

84

Thanks for this excellent component! I’ve moved from fluxer to circadian and find it works better for me.

I have one issue though. My flux LED strips (RGBW) are not changing brightness. I’ve used lights_rgb in config:

lights_rgb:
  - light.master_bed_backlight

Log shows brightness set successfully but it remains unchanged.

[custom_components.switch.circadian_lighting] light.master_bed_backlight RGB Adjusted - rgb_color: (255, 177.2002651415765, 109.91724515381793), brightness: 10.148153320312499, transition: 0.0
[custom_components.switch.circadian_lighting] light.master_bed_backlight RGB Adjusted - rgb_color: (255, 177.2002651415765, 109.91724515381793), brightness: 10.148153320312499, transition: 1

Also, a feature request for RGBW lights, which have an attribute white_value to control brightness of White LED. Can you also adjust this attribute in addition to brightness?

EDIT: Using lights_xy does this just fine. It sets white value as well.

1 Like
85

So copying and pasting that, I get the following error:

Invalid config for [circadian_lighting]: offset “2:30” should be format 'HH:MM' or 'HH:MM:SS' for dictionary value @ data['circadian_lighting']['sunset_offset']. Got '“2:30”'. (See ?, line ?). Please check the docs at https://home-assistant.io/components/circadian_lighting/

Any idea?

I don’t know the exact offset I need yet, but I’m trying to reconcile my old sunset lighting automations with the colour temperatures from this component (at the moment, it’s a bit too warm a bit too early for my use, so I want to delay it by probably 45 mins or so).

86

I think I’ve fixed the issue I found with rgb (ATTR_BRIGHTNESS was not being set before service call). And some other minor ones with xy (srt instead of str, white_value instead of brightness).

https://pastebin.com/s4aLw33C
Check lines 288-9, 308 @claytonjn

87

Just pushed a few fixes:

  • Fixed case where sunrise_time or sunset_time were specified, but not both.
  • Changed sensor attributes to only be strings if needed (so lists, floats, etc are proper object types. This is helpful if you want to specify the appropriate color in a turn_on service call in a python_script, for example.
  • Include rgb_color and xy_color in sensor attributes. They were being calculated anyway and could be useful for service calls.
  • Fix for sunrise/sunset offset (@wjs)
  • Fix brightness in RGB light adjustment (thanks @mouth4war)
  • Fix logging XY light adjustment (thanks @mouth4war)

The following files were updated:

1 Like
88

Sorry, should have been single quotes not double (i.e. '2:30' or '-1:00'). There was a bug in the previous code too though, so you’ll have to update before it will work (see above).

1 Like
90

Brightness for xy light is not being changed when sleep mode is turned on. Color temperature changes but brightness doesn’t. Once interval passes, the change happens. Should it not be the same as colortemp i.e. as soon as sleep entity changes state?
UPDATE: Seems like there is no call to calc_brightness in adjust_lights. Could this be why?

Also, the sleep mode attribute in the switch doesn’t change at all. Once set to on, it stays on despite the updates happening.

91

No, if you look at the code adjust_lights uses the brightness attribute, and that uses calc_brightness. When you’re in sleep mode does the brightness attribute of the switch show the proper sleep brightness?

I’m not sure what you mean by this, can you elaborate?

92

Amazing - works now, thank you! And thanks again for developing this - it has received approval from my partner which I think is about the highest praise in home automation :sunglasses:

93

Figured out what was going on, can you test with the updated config/custom_components/switch/circadian_lighting.py?

94

Looks like it has fixed the delayed brightness adjustment. Thanks!

The attribute sleep_state in the switch entity is still showing state as on while the sleep entity is off. It should be updated when sleep state is detected or not. Minor issue though. Just confusing for debugging.

I have a question about using sensor value in automations. The sensor shows state as -85%. I assumed it was brightness_pct but that cannot be -ve. Where do I pick up brightness from? The switch has brightness but that’s only available when switch is turned on.

95

Are you referring to the “sleep state” like here:

image
image753×185 8.34 KB

If so, those are only intended for referencing your configuration, those aren’t meant to change. Actually, for the switch entity, the only things that should ever change are “hs color” and “brightness”

So the sensor percentage is the percentage above/below the horizon the sun is. That’s used to calculate color temperature and brightness, but you could use it to calculate other things. Brightness is calculates on a per-switch setting because each switch may have different min/max, sleep, etc. As you said, brightness is not available when the switch is off because the switch doesn’t do any updating when the switch is off so brightness would just stay at the value it was when turned off. I could potentially change the logic so that everything is still calculated but lights aren’t adjusted when off, or you could use the sensor percentage to calculate what brightness you’d want. What’s your use case for using it in automations when the switch is off?

96

Thanks for clearing that up! Was expecting those config attributes to refresh. My mistake.

About the brightness, it’s not a big deal at all. I just thought it was available outside of switches.

Use case is in the occasion that a scene has been used to override circadian lighting and motion is detected afterwards while circadian is off.

I have lighting scenes (candlelight, dim, medium, bright) that disable circadian and then it has to be turned on manually.

97

You really need to put example values with each of the settings. It’s an annoying crap shoot to figure out how each setting should be formatted.

Other than that, I love this component and thank you for the work. It definitely should be graduated to a regular component eventually.

98

Yes, I agree. I didn’t because the first couple posts were so long already but I do need to add more detail.

I’d love if this component had enough support that I could add it and maintain it as a native component. I haven’t really pursued that because it has the same purpose as the Flux component (although with very different behavior).

99

Don’t be discouraged, there are lots of components that duplicate functionality. This is plenty different enough.

100

Hate to be the bringer of bad news but the latest HASS dev breaks this component

2018-10-30 17:02:10 ERROR (MainThread) [homeassistant.setup] Error during setup of component circadian_lighting

Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.6/site-packages/homeassistant/setup.py”, line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File “/usr/local/lib/python3.6/concurrent/futures/thread.py”, line 56, in run
result = self.fn(*self.args, **self.kwargs)
File “/home/homeassistant/.homeassistant/custom_components/circadian_lighting.py”, line 106, in setup
load_platform(hass, ‘sensor’, DOMAIN)
TypeError: load_platform() missing 2 required positional arguments: ‘discovered’ and ‘hass_config’

1 Like
101

I have the same problem.

102

@mouth4war @roofuskit working on it now, looks like an easy fix. I’m testing on my dev instance and my live instance so it’ll be a few minutes but hopefully soon. Thanks for the heads up!