I am noticing strange behavior with 2 new color led bulbs w/ adaptive lighting.
the other white/tunable led bulbs are being set to ‘warm’ where the color bulbs are being set to ‘cool’ through adaptive lighting… actually it seems that the color led are simply dimming and not changing color/temperature.
I’ve been using this integration for several months now after previously moving on from the circadian_lighting integration. I started having issues a few days ago; I can’t seem to make any changes anymore via the Integration UI. I’m trying to add bulbs with the drop down menu, but every time I select “Submit” I get the following error message up top: “User input malformed”
Is…is it seriously just me? 100% of everyone else reading this can add bulbs and click submit via the UI and not get the “User input malformed” message? I’ve deleted and reinstalled everything to no avail.
Bonus question - does the config.yaml method still work? I’m thinking if the UI is failing me, I’m hoping I can do the longer more annoying method and manually add in some configs in the config yaml.
Is adaptive lighting supposed to Start at sunrise/sunset, or lead up to/culminate with sunrise/sunset? I had to set up in config yaml due to the user input malformed bug and I completely omitted the sunrise_time, sunset_time, sunrise_offset, sunset_offset in my yaml but it’s not working like I expected. Currently if I go to dev tools and check entity switch.adaptive_lighting_upstairs (the only ‘device’ I set up), I see brightness_pct of 72.27 which has been steadily dropping over the past hour or two. And sun_position is -0.28… Is this working as-designed? I would have expected with no offsets or overridden sunset times that my lights would be at minimum brightness by now. Not sure if it’s a bug where there’s an overridden sunset time somewhere or if I need to edit the sunset_offset in order to be closer to minimum brightness At sunset rather than a couple hours afterward.
also of potential note is that a ‘default’ adaptive_lighting entity exists, but I currently have it ‘off’ and i have no idea how it got there or how to configure it since I didn’t set it up in my config yaml and the UI config is broken.
I just saw an issue has been raised on GitHub as it was a HA 2021.11.x related bug. the bug has affected a number of custom integrations so hopefully it will get fixed soon-ish…
it appears that the the lights begin dimming right around when the sun elevation hits 0 and gets back up to 100 by sunrise the next day.
So in a practical example, tonight the sun will set at 5:30pm and rise tomorrow at 7:30am. So at 5:30pm the lights will begin dimming from 100 down to 1. It will hit 1 around 12:30am halfway between sunset and sunrise, and immediately begin brightening again, when it will finally reach 100 around 7:30am.
So I guess my new question is, is this ramp configurable? I don’t really need the ramp to last ALL night. Is there a way to say, go from 100-min over ~2 hours, hold there, then ramp up the next morning ~2hr before sunrise from min - 100 and hit 100 at sunrise?
Thanks for this info; it’s helpful and I’m glad to know it’s on the HA team’s to-do list.
In any event, I’ve tried reverting my core back to 3 different versions of 2021.10.xx with same result; hopefully an update gets released ASAP. I’m realizing this bug isn’t really coming to fruition for most of you since you already have the component setup the way you like it, and because you don’t have a need to add new bulbs, you aren’t discovering the bug like I am.
Started having issues since lately.
HA 2021.12.3
Deconz Integration 6.11.1
Adaptive lightning 1.0.15
When I us my Ikea dimmer switch to turn on the Hue light it first turns on with low brightness, then it needs a second to rump up the brightness to a set value.
Previously it would do this seamlessly with no one second delay.
I had the same a few times. I have no idea why that happens so far but I am not using the Adaptive lightning integration so it has nothing to do with it I believe.
Adaptive brightness sets lowest brightness before turning off the light. That same brightness is set on next turn in event. After that adaptive lighting rump’s up the brightness. That’s expected but now it takes a second for adaptive lighting to kick in
You might be right but as said: I do not have the integration at all and experienced this as well a couple of times.
Does this happen to you all the time or is this random?
So it seems the issue is within adaptive lighting integration. Doesn’t matter how the light is turned on, it kicks in late rather then immediately after light is turned on. Not sure if it was caused by the integration update or home assistant update. @dbrunt any idea?
I am no expert nor am I currently even using AL since I use a Circadian Routine in Node Red but I believe it might depend partly on the device and the integration since I seem to recall reading that some Zigbee devices are first sent an On and then followed by the brightness level. With everything in HA in constant flux and improvement I’m not going to begin to try and figure it all out!
If a light is turned on outside of AL, AL is just monitoring its state change and then adjusts after the fact so there will be a delay. Whether that delay is perceptible or not depends on countless factors. My office lights Sengled Zigbee) come on at the brightness they were last turned off. Circadian then kicks in and sets the current color/brightness. It’s always been noticeable if the difference is large.
It seems that for some reason the integration needs a second to react to light on event. Not sure why it changed. It would work instantly before. Not sure how not works but it would be beneficial to subscribe to an event and react immediately when the light is turned on.