I’ll put together something here to test…
Seeing images published on GitHub, I can see 100% simikarity with Circadian lighting component.
I would like to know if it is based on some research or just copied from mentioned component?
On first glance it’s obvious that both brightness and color comes from sinus function shifted by 180 degree. Ok, it’s correlated with sun position (percentage).
But in reality it doesn’t work this way.
Colour of the light doesn’t change during a day this way. In fact after morning it stays blue for a most of the day.
But brightness has even bigger issue: why it reaches about 50% of intensity durring deep night? For today (Europe/winter) it’'s 3hours before end of sunrise (5am, 8am).
I know it’s exactly the same behaviour as in Circadian component. But while the latter is community one and could contain various glitches, but in case of official occomponent it can do better.
I hope I’m wrong and there is some research existing which proves that circadian light must be intense even if the Sun lits another side of Earth.
1 Like
So, it’s a copy of functionality without attempt to make it proper real circadian lighting (tbh I don’t know what ‘adaptive’ does mean in the component name. It adapts to what?)
I suppose most people doesn’t care because at 3am they are sleeping. But for example having just born child, with need to wake up several times during a night… Yeah I know I can hack it on my own. I do that. But it doesn’t change the fact that current implementation is… suboptimal.
BTW another usecase just came to my mind. So popular sunrise effect, promoted by Philips Hue product line. This is what it could be used for if providing proper light changes.
I hope that one day devs will come to the same conclusion making this component 100% aligned with what it is intended to be. Otherwise it will stay popular only in group of users who are exciting about automatically changing lights, regardless it’s realistic or not.
I’ll give your new improved version a shot when you release it!
BTW, see post #54 for the topic that the author @basnijholt has started. I’m sure he’s open to constructive criticism!
Give me a few days to publish it, I currently tweaking curves of brightness and warmth.
Yes… it’s configurable using spline curves being auto-aligned to sun phases. but… it’s NodeRed project.
In post #54 I can see: " automatically adapts the brightness and color of your lights based on the sun’s temperature and brightness" and
“It uses the position of the sun to calculate the color temperature and brightness that is most fitting for that time of the day.” - unfortunately those sentences are not true what I proven above.
I haven’t tacked NodeRed yet, but itching to have a go at it…
So I created these two scripts:
alias: Test Light Off
sequence:
- service: light.turn_off
data:
entity_id:
- light.office_light_1
- light.office_light_2
- light.office_light_3
mode: single
alias: Test Light On
variables:
entities:
- light.office_light_1
- light.office_light_2
- light.office_light_3
color_temp: |
{{ state_attr('switch.adaptive_lighting_office', 'color_temp_kelvin') }}
sequence:
- service: light.turn_on
data:
entity_id: '{{ entities }}'
kelvin: '{{ color_temp }}'
brightness: 80
mode: single
and they work fine for me except, I do need to delay for 5 seconds after turning them on before turning them off otherwise HA seems to get mixed up, probably with what AL is doing after the lights are turned on, which is likely a brightness adjustment at this time of day…
alias: Test Lights flip-flop
sequence:
- service: script.test_light_off
data: {}
- delay: '00:00:02'
- service: script.test_light_on
data: {}
- delay: '00:00:05'
- service: script.test_light_off
data: {}
- delay: '00:00:02'
- service: script.test_light_on
data: {}
- delay: '00:00:05'
- service: script.test_light_off
data: {}
- delay: '00:00:02'
- service: script.test_light_on
data: {}
mode: single
HA is moving more and more towards inner stuff being processed asynchronously in an effort to improve performance. Kind of like multitasking. So, after your entities have changed state, AL fires up and does it thing. If you simultaneously trigger something else while it is processing in the background on the same entities, well unexpected sequences can occur. I’m trying to sort out my good_night routine where I turn off all the house lights except bedroom. Those 2 lights sometimes turn off, sometimes one or the other, or they both go off then one comes back on like last night. My modified sequence as of today is turn off all other lights, process other actions like Did you prepare your coffee?, Is the garbage out?, set thermostat to Eco mode, lock the front door, close the garage door if not summer time otherwise ask, and finally (new) transition the bedroom lights to off over 60 seconds, wait for trigger that they’re off and then turn on input_boolean.sleep_mode which triggers automation to turn on AL Sleep Mode switches. Fingers crossed!
One more note: your HA machine’s horsepower is also a factor in async processing so you may need more/less delay than my testing.
1 Like
Hi everybody,
I have been experiencing some unexpected behavior of the min_brightness parameter. The lights above my dining table are not super bright, so I want them to be between 80 and 100% brightness and set the min_brightness accordingly. What I expected to happen was, for example:
min_brightness: 80
calculated: 50
actual brightness: 80
What actually happens is:
min_brightness: 80
calculated: 50
actual brightness: 90
Obviously the min_brightness does not serve as a limit that cannot be undercut, but as the “new 0” from which the actual brightness will be calculated. Is there a way to change this behavior, or at least some workaround?
Thanks
Robert
IMO the way I read the docs, this is by design so the answer as I see it is no.
The calculated percentage is always based on 0 to 100%.
Min is the minimum for the 0% calculation
Max is the maximum for the 100% calculation.
if min = 0
and max = 100
calculated is:
0% = 0
50% = 50
100% = 100
But if…
min = 25
max = 75
calculated results in:
0% = 25
50% = 50
100% = 75
If your desired range is 80:100 then in the middle of the night (0%) the light would be at 80. Middle of the day (100%) would be 100 and the times in between mid-day:mid-night would be somewhere between 80 to 100.
If I understand your desired goal, your want the light to adjust more quickly from 100% mid-day to 80% a couple hours later and never get dimmer than than, then start ramping back up from 80 to 100 a couple hours before mid-day?
Maybe post in @basnijholt 's topic (linked to in post #54)…
Or check out @maxym 's NodeRed project, soon to be released…
I would like to be the light to be at the actual, calculated values, unless they are below the min_brightness or above the max_brightness from the config. Right now, the values are pretty far off:
| min | 0 | 80 | 80 |
|---|---|---|---|
| max | 100 | 100 | 100 |
| % | calculated | calculated | should be |
| 0 | 0 | 80 | 80 |
| 5 | 5 | 81 | 80 |
| 10 | 10 | 82 | 80 |
| 20 | 20 | 84 | 80 |
| 30 | 30 | 86 | 80 |
| 40 | 40 | 88 | 80 |
| 50 | 50 | 90 | 80 |
| 60 | 60 | 92 | 80 |
| 70 | 70 | 94 | 80 |
| 80 | 80 | 96 | 80 |
| 90 | 90 | 98 | 90 |
| 100 | 100 | 100 | 100 |
The package cannot currently do what you want so I suggest reaching out to @basnijholt.
Maybe he’d consider adding additional parameters for you… absolute_min_brightness / absolute_max_brightness and then you would set min_brightness: 0, max_brightness: 100 and absolute_min_brightness: 80, absolute_max_brightness: 100…
Yes, I will do that. I was looking at the source code today and I think it’s not too much work (although my python knowledge is rather … quite limited 
)
I have been testing CL for a while now and it is not able to handle the brightness and color temp adjustments of my Ikea Tradfri White Spectrum bulbs properly.
With the AL separate_turn_on_commands option, it looks like this is the solution to that CL issue.
I see that the matter has been discussed in this thread. Could @dedepene and @haseat please confirm if the separate_turn_on_commands option 100% solves this known Ikea Tradfri bulbs brightness/color temp issue?
I have found it fixes the issue when the lights are on, but the initial turn on (from off) doesn’t work as well as i’d like - seems the color command kicks in to soon and cancels the brightness command mid transition (so only leaving it at half brightness).
That’s exactly what I’ve been experiencing too, in one occasion (Ikea Floalt 60x60) leading to wild flickering and color changing. This code works for all my Ikea lights:
- name: Hallway
initial_transition: 0
transition: 0
separate_turn_on_commands: true
lights:
- light.hallway_lights
Thanks. I saw the automation you added to address the initial turn on issue here. Will try to implement this as well.
@basnijholt, thank you for creating AL.
Is there a way to include/address this in AL itself to avoid adding the extra automation?
Thanks. This looks simpler than @apmillen’s automation. Will try this as well. Does setting initial transition and transition to 0 not result in any weird behavior since adjustments will be instant?
transition: 0 is not noticable at all, initial_transition: 0 only very rarely
Hi!
Need the community for some shared knowledge:
What are colored zigbee bulbs working well with Adaptive Lightning or Circadian Lightning?
I used some Gledopto bulbs which use seperate colored and white spectrum LEDs. The effect was really good, but the lights itself were really slow, so I changed them for Tradfri colored ones. Unfortunately the colors on these bulbs alwa look of (pinkish instead of yellowish). I found out Ikea colored bulbs odn’t use extra white spectrum LEDs, hence the white spectrum isn’t really great.
So: which colored bulbs are you using? Which bulbs are known to support color AND white spectrum well?