Avoid sending brightness changes, when no changes are to be made

[LordMike]

This component works great, so thanks for that :)

One minor change though - it seems brightness is being set, even when no change is made. F.ex, I will often see changes being pushed to lights going from 15% brightness to 15% brightness.. HASS does not seem to check if the brightness has changed, before sending the command out..

Could Adaptive Lighting be updated to check if there's a change, before calling light_on ? :)

Thanks in advance.

[sphanley]

This would be great - it’s got me thinking about an oddity with my Lutron Caseta lights, where I noticed a strange issue where they seemed to frequently dim and then restore to the same brightness.

I couldn’t figure out why and ultimately fixed it by checking the “only adapt once” box. I wonder if this could have been causing it - maybe my lights were trying to fade to the new value even if it shouldn’t have been changing?

[LordMike]

I quickly checked if only adapt once could help me - but no, it actually only does it once ... :P

But fun stuff... What do your lights do if you dim from say, 20 to 15 ... do they make a gradual change to 15, or do they go to 0/99 first, and then back to 15 ?

[maniacaris]

This would be great - it’s got me thinking about an oddity with my Lutron Caseta lights, where I noticed a strange issue where they seemed to frequently dim and then restore to the same brightness.

I have a Shelly dimmer hooked up to a circuit of three lights that exhibit the same behavior. Usually, it happens for me when the brightness value is passing through the ~31% range, although I don't believe it happens with the same frequency now.

[sphanley]

I have a Shelly dimmer hooked up to a circuit of three lights that exhibit the same behavior. Usually, it happens for me when the brightness value is passing through the ~31% range, although I don't believe it happens with the same frequency now.

That's interesting - yeah, with a bit more testing, it doesn't seem like my issue is likely related to this report, because if I repeatedly call "turn_on" with the same brightness, I don't see any unexpected dim-brighten cycling, and dimming from one number to another happens smoothly. I'll have to do a bit more investigation to try to narrow down my problem and report it separately.

[LordMike]

Could it be that adaptive lighting hits a number or so, where it bounces between two numbers, like a floating point issue.

[RouNNdeL]

I've also noticed the 'blinking' with a shelly dimmer. One additional problem with the shelly is that when the light is turned on Adaptive Lighting also immediately sends a brightness update completely canceling the turn on transition (the light instantly turns on). I've devised a workaround which involves disabling adaptive lighting and then turning it back on after a delay, but it's rather cumbersome to do everywhere. I'd love to see an 'adapt delay' of some sorts introduced.

[RouNNdeL]

I believe that both Shelly issues are caused by an event with brightness_pct: 0 being called (I don't know where this comes from, it was in the logs). Here's a script that replicates both the blinking and the transition canceling:

alias: Test
sequence:
  - service: light.turn_on
    data:
      brightness_pct: 0
    entity_id: light.bedroom
  - service: light.turn_on
    entity_id: light.bedroom
  - service: light.turn_on
    data:
      brightness_pct: 50
    entity_id: light.bedroom
mode: single

This exact sequence I found in the logs, all of this happens very quickly.

Interestingly enough removing the brightness_pct service call fixes the blinking problem, but removing the service all without any data fixes the transition problem.

Transition working:

alias: Test
sequence:
  - service: light.turn_on
    data:
      brightness_pct: 0
    entity_id: light.bedroom
  - service: light.turn_on
    data:
      brightness_pct: 50
    entity_id: light.bedroom
mode: single

No blinking:

alias: Test
sequence:
  - service: light.turn_on
    entity_id: light.bedroom
  - service: light.turn_on
    data:
      brightness_pct: 50
    entity_id: light.bedroom
mode: single

[sphanley]

That seems like good insight, but I feel like we've totally hijacked this original issue. Maybe a new issue should be opened for the dimming-brightening cycle issue?

[RubenKelevra]

Hey @LordMike,

this will be part of v2, as the pacing will be determined dynamically on the amount of change and limiting filters.

Keep this ticket open until you can verify that it's properly working in the upcoming version 2.