Seems to have quit adapting since 1.30.0

[MitchTalmadge]

Before I spend time making a bug report, I wanted to ask if anyone else is experiencing their lights no longer changing brightness or color shade automatically since the last update. They seem to just be stuck. If I reload the integration, all the lights go to the right color and brightness, and then are never adapted again.

My lights are also controlled by Lutron remotes through automations, basically remote wall switches. They can turn the brightness up and down. But in the past, if I turned the lights off and then back on, it would go to the adapted color and brightness. Now it's always wrong.

I'll make a more comprehensive bug report later. Just wanted to gauge if anyone else is seeing this

[maia]

I've also realised that all my adaptive lights stopped changing brightness a few weeks ago. I'm still clueless for the reason and unsure how to debug it, but as a quick first attempt I'm trying to revert from 1.31.1 to 1.29.0, this might narrow it down. @MitchTalmadge Have you found out the reason for the issue yet?

[MitchTalmadge]

@maia I think the bug is recorded in #1378. Looks like an attempt was made to fix it in #1380, but at least one person is saying it might not be fixed. Personally I downgraded to 1.29.0 (I did not restore a backup despite the warning -- it was fine), and everything is working again. I'll upgrade another day.

[maia]

Thanks, this is interesting. I am unsure if it is related. In my case I think I have issues with three usages: once a Hue light connected via Zigbee2MQTT, once a Zigbee group of two Hue bulbs, once a Nanoleaf lightstrip connected as HomeKit device. When they turn on due to motion or darkness, they adjust to the proper brightness. But frequently they just keep the same brightness for hours, ignoring sunset or sunrise. There's no manual interaction that could explain it. Turning them off and on again sets the proper brightness.

They all use tanh as brightness_mode with high values for time_dark and time_light (e.g. 1800), but other than that their configuration differs.

This behaviour started a few weeks ago (I think), so I wonder if it is related to a recent update to the integration. Let's see if reverting to 1.29.0 helped.

I might need to look into the growing number of checkboxes which might cause side effects (take_over_control, detect_non_ha_changes, only_once, adapt_only_on_bare_turn_on, separate_turn_on_commands, skip_redundant_commands, intercept, multi_light_intercept). Also I need to figure out how to debug such an issue using developer tools. I hope I won't need to manually search through many MB of log files that are created over night.

[MitchTalmadge]

That kinda sounds like the "only once" option is turned on. But I agree, there's so many options I find myself lost often and don't feel like I understand them all.

[maia]

Good guess - but unfortunately, it wasn't the case. Interestingly reinstalling 1.29.0 seems to have solved the issue. I need to figure out how to properly test/debug the issue on 1.30.x, as the expected brightness changes happen around 5am and that's usually when I don't have time to investigate technical issues. And when it's bright outside and I am awake, the lights are off.