Not really, when enabled for the ZigBee group, the integration will override the state of your individual lights with the next update interval.
Strange. It worked for me only when I added, the individual lights as well as the groups. Had this issue only with zigbee bulbs. I have a mix of ikea, sengled and osram bulbs.
Specifically, for me it would switch on lights that were part of the group but off (because the group is still in on state for HA/the integration).
Anyone struggling with the option whether to choose ārgbā over ācolor_tempā? They both have their pros and cons.
Iām running RGB+CCT led strips from Aliexpress, and controlling them with Gledopto Zigbee-controller. Originally I had so called ā1IDā controllers where you basically had either the āColor Temperatureā -mode (controlling on Cool and White leds), or the āRGBā -mode (only RGB leds). Just a few days ago I moved to āGledopto Mix -controllerā that will mix CW/WW + RGB for a smoother transition from white to colour. Itās clearly a much better controller, but it didnāt solve my problem Iām describing below.
My optimal lighting setup would be having 5500K bright clear white for the daytime, and when going closer to sunset, the light would gradually approach a nice 2700K yellowāish tint. And during the evening and early night I would like to have the light dim to orange around 2000K.
The problem with ārgbā / ācolor_tempā option is the following:
When choosing the ācolor_tempā Iām getting nice clean whites in the range 2700K-5500K. So optimal for daytime. The warmest the light can ever reach is āyellowā, even if setting the light to 2000K.
If I choose ārgbā, I can reach that nice orange and nice 5500K bright white (now with the mix-controller), but the rgb-transition in between is just horrible. The color transition completely misses the yellow, and thereās transition to ugly pinkish hue between 5500K and 2000K.
Before switching to the mix-controller, I had two separate āAdapive Lightingā entries for this led-strip with were otherwise identical, but other had ārgbā control and other ācolor_tempā control. I would use ācolor_tempā during daytime, and at a specific time (1h after sunset) disable this entry and enable ārgbā variant. Thereās a very noticeable transition from yellow to orange at this point. But it worksā¦
Now after this long post (sorry for that) Iām asking if thereās any solution for my problem how to get smooth transition from 5500K to 2000K without crossing that ugly pink? I see a solution where the transition curve RGB-values would be configurable from a lookup-table, or if there could even be 3 or 4 configurable points along the way.
Has anyone been able to get this to play nice when the initial āturn-onā is from a smart wall switch?
Here is what Iāve been messing around with:
-
Caseta Diva dimmer where I put the dimmer slider at minimum in case of being turned on in the middle of the night
-
Catch the state change with either an automation or NodeRed to update the brightness
-
2-5 second delay before the switch updates to the adaptive lighting value. Toggling strictly with Home Assistant or motion will eliminate this problem but I still need/want to use the wall switch at times for turning on or off.
I have the Caseta Diva dimmer switch. Itās connected to 7x waffer 2" down lights. Iām not sure how much the pertains to your situation, but I can share what Iāve learned. With having 7 lights on the switch, it seems they need enough power on the first turn-on to get them all to come on without much delay. After experimenting, I was able to set the low Trim in the Lutron app to 4%, but the wall dimmer has to stay at 18% for itās initial turn-on brightness. Once power is flowing, it can dim very low, but it does need that initial power, takes a second, and then Adaptive kicks on.
Yo.
I spent a fair bit reading through this and some other threads last night and canāt figure this out.
AL is working (lights are adapting).
My problem is that when I run a script or automation that sets a light at a specific brightness AL takes over. I was under the impression that turning on AL takeover control was going to disable AL in this case.
Iāve taken to adding a āset manual controlā to my script, or turning off adaptive lighting on another automation and then turning it back on.
Is there a better approach that Iām missing?
And, is there an actual list of āmanual controlā entities that I can reference to see what is or is not flagged as manual control at any time?
Thank you so much!
No, I think thatās currently the only way.
Oh!
This whole last couple weeks Iād been thinking that AL would automatically recognize manual adjustments and disable itself for that light. I thought that was the purpose of the first two settings. In my screenshot.
detect_non_ha_changes does not seem to work, and take_over_control really only works with light.turn_on. Any other services (like ZigBee scene activation) do not trigger manual control. But I agree that the documentation paints a different picture.
1 Like
copy that, thank you for your experience.
and
take_over_controlreally only works withlight.turn_on.
That fills in for me why I was getting inconsistent UX. Thanks!
We should really improve that documentation then make sure that this is clear. Does anybody have a suggestion of how to improve it?
1 Like
Maybe add a point about scene enitities not triggering manual control (donāt know how hard it would be to instead intercept those as well)? And what does detect_non_ha_changes actually do? It definitely does not detect the state changes caused by applying a Z2M scene.
I can take a whack at this if Iām clear what it does and doesnāt do.
As of right now my understanding is that take over is only functional with the service call light.turnon. otherwise set manual control is needed to disrupt AL.
and also not sure about detect_non_ha_changes either.
Is there a list of currently set manual control entities that can be inspected?
I think you can set manual control for the three of the four switches provided by the integration (either the overall switch or separately for brightness and color - not for sleep mode obviously).
What I mean is to inspect individual light entities that have been set to manual control. Maybe Iām misunderstanding again.
ie. If I set manual control and specify a light with the second option, would this be reflected anywhere within the UI, or a file/database?
According to the docs, an event adaptive_lighting.manual_control is fired. I donāt think there is any way to query the manual control state.
Thanks, that got me to look into the āeventsā section in docs and developer settings. Itās not something I understood before. It appears you can monitor for the event being āfiredā, but I canāt tell yet if thereās any type of logging beyond that.
These events were recorded when I ran a script that sets manual control
Iām having some issues where lights set to manual control (via take_over_control) then do not stop being manually controlled after being turned off, then turned back on via Home Assistant.
Does anyone know if there is a setting to control this?
I know I could set an automation to turn off manual controlā¦ but I thought the expected behaviour is that it would turn off by itself when the light was turned off.
What I did is set manual control off once Iām finished with it. Or cycle the master AL switch.
Edit - I guess I have to ask, after all my sorting things out. When you say āvia take_over_controlā what do you mean? Having the switch in configuration turned on?