Brightness factor is not strictly enforced

[Taudris]

What happened?

When using brightness factor to limit the average power draw of a PWM LED strip, sometimes the PWM duty cycle is able to exceed this value.

I don’t know if this behavior also affects digital LEDs.

To Reproduce Bug

Set a brightness factor of eg 20%, set brightness to 100%/255, then open the LED preferences screen and save (no changes are needed). The PWM duty cycle will then become 100% until the next brightness change.

I also observed an animation glitch where the brightness exceeded the brightness factor for a moment, but I have not been able to reproduce this.

Expected Behavior

The LED output must absolutely never exceed the configured brightness factor.

Install Method

Binary from WLED.me

What version of WLED?

0.15.1

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

I don’t know which flavor of ESP32 this device uses, but it’s whatever is in the GLEDOPTO GL-C-211WL. (They put a custom RF shield on the carrier that has the MCU, and the info screen just says ESP32.)

As a side note, since brightness factor could be used to keep power consumption within hardware limits and could thus constitute a safety issue, ideally it would be preserved when resetting the config by hardware button. (Maybe it already is; I haven’t tested it yet.)

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

@Taudris confimed and fixed. You can download the bins containing the fix here:
https://github.com/wled/WLED/actions/runs/16847354513

resetting the config means just that, it resets everything. Software limits are not there to make hardware safe, thats what a proper setup and fuses do.

[Arcitec]

@DedeHai I can confirm that this bug affected "Brightness Factor" on Digital LEDs too. I compared before and after the code change. Applying the "scaled brightness" thanks to your fix has solved it for digital LEDs too. Excellent work. :)

[DedeHai]

there may actually be more places where this should be done, see blazoncek@bac5210

I have WIP to change the whole brightness business (#4798) so these changes may not be needed afterwards

[Arcitec]

@DedeHai Ah, yeah it sounds like setBrightness should always use scaled brightness to preserve the brightness factor. Which makes me wonder... maybe setBrightness() itself should be changed to internally apply the scaling factor. That way external code can use the regular 0-255 range without worry.

I also noticed that you changed the order of the instructions, to place brightness after auto-/fix-segments (https://github.com/wled/WLED/pull/4827/files) . That seems to make more sense than changing it before segmentation. Do you know if that fixed another bug or was it just a good idea?

[DedeHai]

not always, you dont want network pixels scaled.
IIRC that was the order as it was in 0.15

[Arcitec]

@DedeHai Hmm. How about making the function signature automatically apply it, but be possible to opt-out by providing false in a few cases where scaling is unwanted. Like this:

void BusDigital::setBrightness(uint8_t b, bool applyFactor = true)

Since it's a bit painful having to remember and repeat this pattern manually everywhere: BusManager::setBrightness(scaledBri(bri)).

Since you're working on refactoring brightness handling, would it make sense to change this at the same time?