openshwprojects / OpenBK7231T_App

Open source firmware (Tasmota/Esphome replacement) for BK7231T, BK7231N, BL2028N, T34, XR809, W800/W801, W600/W601, BL602 and LN882H
https://openbekeniot.github.io/webapp/devicesList.html
1.45k stars 269 forks source link

Exponential brightness "feature" #652

Open 662KDV opened 1 year ago

662KDV commented 1 year ago

Describe the bug Non programmer here. Using LSC Smart Ceiling light (RGBCW, T7231N), unable to disable "exponential brightness" feature.

Controls in web interface and HA are not accurate.

To achieve 10% warm/cold light, the slider must go up to 35%

Firmware:

To Reproduce Steps to reproduce the behavior:

Controls in web interface and HA are not accurate.

To achieve 10% warm/cold light, the slider must go up to 35%

Screenshots If applicable, add screenshots to help explain your problem.

Screenshot 2023-02-05 140250

Additional context Add any other context about the problem here.

openshwprojects commented 1 year ago

Hello, I can add an option to disable it, but you are the first person requesting it. Are you sure that you'd get better results without it? I've had reports that without it it's not possible to get down to very dark brightness levels and it improves overall brightness control quality.

662KDV commented 1 year ago

Hi openshwprojects,

With old firmware up .1xx the ceiling light I'm using worked without issues. I have automation in HA to turn on lights to 10% in the morning. Newer firmware up to .301 I could use the command "led_expoMode 0" and the behaviour of the lights was the same. (brightness slider worked without issues.

With firmware .302 and newer I can't use "led_expoMode 0 " any more. From what I understood it got replaced by "brtMinCW"

I tried using the last command without success. The console would report "unknown command" so for the moment I'm stuck with that "unintuitive slider"

The effect is that at 10% slider...the led's go down to 1% or close and you can barely see the light.

One workaround would be to redo the automation in HA and instead of 10% light, ask for 35% (to get the old 10%)

I might be doing something wrong. As I said I'm not a programmer so I'm using default generated config. (big THANK YOU for this feature, as looking for good/working configs was a pain for a noob like me)

There might be others with similar LSC devices who would need this "feature to the feature" :)

I have another LSC CW bulb, with BK7231T, I did not test the firmware on that device yet, but it might behave the same.

So please, if possible add some possibility to disable exponential brightness for both.

openshwprojects commented 1 year ago

Well, ok, if you think so... I added flag 32 for you, it disables gamma ramp totally, can you check if it works?

662KDV commented 1 year ago

I just flashed .412

The light stays at 100% no matter where I move the slider.

Just to make sure I explained correctly, look at the picture attached in first post.

With version .412 the value of Channel 5 (Dimmer / Brightness) stays at 100% all the time.

662KDV commented 1 year ago

This is the config I copied from HA.

device: identifiers:

openshwprojects commented 1 year ago

Oops, I forget to multiply by brightness. Can you check now?

662KDV commented 1 year ago

Thank you.

It is working as it should.

rogere66 commented 1 year ago

With the new flag LED Gamma and RGB Calibration can be disabled with a flag, but it can also be done using the led_gammaCtrl command. Correct command sequence to disable LED Gamma is (command + sub-command + value):

led_gammaCtrl gamma 1.0 led_gammaCtrl brtMinCW 0.0 led_gammaCtrl brtMinRGB 0.0 (only needed if RGB bulb)

For full details check the doc pages at: https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/led_gamma_control.md

662KDV commented 1 year ago

Update to the reported bug.

It seems that after a (accidental or not) power off, the ceiling light will not work. I have to disable the added flag - save - reboot light - enable the flag - save.

I'm not sure if this was happening from the beginning as I didn't think it was necessary to also test this scenario.

Thank you,