MI Desk Lamp: Erratic led brightness

[poofyteddy]

PROBLEM DESCRIPTION

A clear and concise description of what the problem is.
After Flashing, the initial brightness is way to high, causing flickering and crash if the brightness is increased to much.
As soon as you touch the light color, brightness is way to lower and have weird issue like

• fliker/crach at 100% brightness
• don't light up with mixed led (warm+cold) in the middle of the temp until ~45% brightness
• don't light up with single led even if it should light both until ~25%% (barely enough, the led flicked because of a lack of power)
• when changing the colors temp from light up with single led to a color blend under ~45% the light turn off, and stay off until we reach ~45%
• when look at directly and with enough brightness to work "normally", the LED seam to slightly "wave" in brightness

no mater what, it's not possible to get back at the initial "way to much" after changing the color without reseting

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in the docs
• Searched the problem in the forum
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): MI Desk Lamp
• Tasmota binary firmware version number used: 8.2.0.3
  • Pre-compiled
  • Self-compiled
    • IDE / Compiler used: platformio on Vscode under linux
• Flashing tools used: esptool.py
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:
00:11:23 RSL: stat/tasmota_7A5C21/RESULT = {"NAME":"Generic","GPIO":[255,255,255,255,255,255,255,255,255,255,255,255,255],"FLAG":15,"BASE":18}
00:11:24 RSL: stat/tasmota_7A5C21/RESULT = {"Module":{"66":"Mi Desk Lamp"}}
00:11:24 RSL: stat/tasmota_7A5C21/RESULT = {"GPIO0":{"0":"None"},"GPIO1":{"0":"None"},"GPIO2":{"17":"Button1"},"GPIO3":{"0":"None"},"GPIO4":{"37":"PWM1"},"GPIO5":{"38":"PWM2"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"150":"Rotary1a"},"GPIO13":{"151":"Rotary1b"},"GPIO14":{"0":"None"},"GPIO15":{"0":"None"},"GPIO16":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:
00:11:49 RSL: stat/tasmota_7A5C21/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["GDIOT",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005A00000000000000","00000000","00000000"]}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS4 = {"StatusMEM":{"ProgramSize":614,"Free":388,"Heap":21,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540C8","FlashMode":3,"Features":["00000809","8FDAE3D7","043683A1","000000CD","010013C0","C000F981","00000004"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37","Sensors":"1,2,3,4,5,6"}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS5 = {"StatusNET":{"Hostname":"tasmota_7A5C21-7201","IPAddress":"192.168.90.164","Gateway":"192.168.90.254","Subnetmask":"255.255.255.0","DNSServer":"1.1.1.1","Mac":"5C:CF:7F:7A:5C:21","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_7A5C21","MqttUser":"DVES_USER","MqttCount":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS7 = {"StatusTIM":{"UTC":"1970-01-01T00:11:49","Local":"1970-01-01T00:11:49","StartDST":"1970-01-01T00:00:00","EndDST":"1970-01-01T00:00:00","Timezone":"+00:00","Sunrise":"07:43","Sunset":"16:03"}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS10 = {"StatusSNS":{"Time":"1970-01-01T00:11:49"}}
00:11:49 RSL: stat/tasmota_7A5C21/STATUS11 = {"StatusSTS":{"Time":"1970-01-01T00:11:49","Uptime":"0T00:11:50","UptimeSec":710,"Heap":21,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Dimmer":34,"Color":"5755","White":34,"CT":324,"Channel":[34,33],"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"GDIOT","BSSId":"82:2A:A8:4A:B9:9B","Channel":11,"RSSI":100,"Signal":-44,"LinkCount":1,"Downtime":"0T00:00:04"}}}

• Provide the output of the Console log output when you experience your issue; if applicable:
  (Please use weblog 4 for more debug information)

  Console output here:

TO REPRODUCE

Steps to reproduce the behavior:
I guess just play with the dial on a Mi Desk Lamp with the Mi Desk Lamp Module

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.
0% brightness should be off, 1% should be the smallest stable value for all colors 100% should be the highest stable value for all colors

SCREENSHOTS

If applicable, add screenshots to help explain your problem.
Youtube video ?
Crash when to bright right after flashing : https://www.youtube.com/watch?v=pyXMDOxBUto
Light take many % before turning on : https://youtu.be/GmKQjHyEu4o?start=0&end=21
Light fliker when to bright until it freeze/crach : https://youtu.be/GmKQjHyEu4o?t21

and on https://youtu.be/6zbgkURWb7I:
t=0 first poweron after flash, turn on with high brighness
t=23 touch the color, brightness become to low to light on, can't set it back like it was
t=31 light is finaly back on after increasing brightness
t=44 decreasing brightness just enough to have flickering led
t=50 while on the same brightness, 100% cold light up just fine, same for 100% warm, but not 50%
t=70+ demonstrating how change in colors define how much brightness is needed to get a light

ADDITIONAL CONTEXT

Add any other context about the problem here.
Because of the risk of frying stuff when brightness is to high, i would recommend setting up a warning on the wiki page if this is confirmed

The device work well with the original firmware from MI

(Please, remember to close the issue when the problem has been addressed)

[ascillato2]

Hi,

Can you post the complete STATUS 0 Output please? Thanks.

[s-hadinger]

I understand there are multiple problems here:

• At first configuration, both channels are at 100% which overloads the power supply. Normally there is a security feature to avoid all channels being at 100%, but it seems not to work for 2 channels devices (reproduced)
• PWM should have a minimal value to turn leds on. We had a discussion already about PWM minimum value, let me check
• PWM should also have a maximum value?

Can you please confirm Color FF00 and Color 00FF are ok, or does it still overload the power supply?

Edit: just after initial configuration, the bulb is set to Color FFFF which drives too much current.

[poofyteddy]

Hi,

Can you post the complete STATUS 0 Output please? Thanks.

i'm sorry, but i actually did post the full status0 output
here is a new one

00:05:33 CMD: ------------------------------------
00:05:37 RSL: stat/tasmota_7A5C21/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"MqttLog":0,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["GDIOT",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["00008009","2805C8000100060000005A00000000000000","00000000","00000000"]}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS4 = {"StatusMEM":{"ProgramSize":614,"Free":388,"Heap":21,"ProgramFlashSize":1024,"FlashSize":2048,"FlashChipId":"1540C8","FlashMode":3,"Features":["00000809","8FDAE3D7","043683A1","000000CD","010013C0","C000F981","00000004"],"Drivers":"1,2,3,4,5,6,7,8,9,10,12,16,18,19,20,21,22,24,26,27,29,30,35,37","Sensors":"1,2,3,4,5,6"}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS5 = {"StatusNET":{"Hostname":"tasmota_7A5C21-7201","IPAddress":"192.168.90.164","Gateway":"192.168.90.254","Subnetmask":"255.255.255.0","DNSServer":"1.1.1.1","Mac":"5C:CF:7F:7A:5C:21","Webserver":2,"WifiConfig":4,"WifiPower":17.0}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS6 = {"StatusMQT":{"MqttHost":"","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_7A5C21","MqttUser":"DVES_USER","MqttCount":0,"MAX_PACKET_SIZE":1200,"KEEPALIVE":30}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS7 = {"StatusTIM":{"UTC":"1970-01-01T00:05:37","Local":"1970-01-01T00:05:37","StartDST":"1970-01-01T00:00:00","EndDST":"1970-01-01T00:00:00","Timezone":"+00:00","Sunrise":"07:43","Sunset":"16:03"}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS10 = {"StatusSNS":{"Time":"1970-01-01T00:05:37"}}
00:05:37 RSL: stat/tasmota_7A5C21/STATUS11 = {"StatusSTS":{"Time":"1970-01-01T00:05:37","Uptime":"0T00:05:38","UptimeSec":338,"Heap":21,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"POWER":"OFF","Dimmer":34,"Color":"5755","White":34,"CT":324,"Channel":[34,33],"Fade":"OFF","Speed":1,"LedTable":"ON","Wifi":{"AP":1,"SSId":"GDIOT","BSSId":"82:2A:A8:4A:B9:9B","Channel":11,"RSSI":100,"Signal":-44,"LinkCount":1,"Downtime":"0T00:00:04"}}}
00:05:58 CMD: -----------------------------------------------------

Can you please confirm Color FF00 and Color 00FF are ok, or does it still overload the power supply?

I can confirm it does not overload the power supply setting those value. and the light turn off when brightness goes under 28%

Thank's for the quick reply ! I didn't expect it ;)

[s-hadinger]

First issue (overload at init is fixed). I will look at PWM minimal value.

[poofyteddy]

thank's @s-hadinger i'm compiling your PR right know to confim, Sadly i'm in europe so i won't be able to do much for what is "tonight" here ;)

[s-hadinger]

Could you also do tests with LedTable 0 which disables Gamma Correction. 28% with Gamma correction should be roughly 3% without Gamma Correction.

Also please report if the brightness appears more linear with LedTable 0 or LedTable 1.

[poofyteddy]

overload at init is fixed by #8121 because it reduce brightness (to what is actually visual similar to an off state), Color still being FFFF mean that touching the colors temp drastically change the light brightness
I'll report on gamma correction tomorrow :)

[poofyteddy]

hello @ascillato2 and @arendst, This isn't globaly fixed, and the overloading still occure if i crankup the brightness, what @s-hadinger did only avoid the device from bootlooping because it light up to bright after flash.
The device is still non-functional in it's current state

[poofyteddy]

@s-hadinger with ledtable at 0, the brightness is enought to turn on the light around 4%, witch is much better, but

• when the brightness is low and the colors temp is one the far end (ff00, 00ff) changing the colors temp still only decrease brightness off the light-up led without lighting up the second one

• Light still overload at FFFF colors and reboot if the brightness is to high

• Brightness feel less linear and it feel way better with ledtable 1

[s-hadinger]

I hope I solved it. First, keep in mind that by design the sum of both white channels cannot exceed 255. However you can force arbitrary values with the Color command.

Color FFFF allows to bypass the safety and force both channels to max levels. Don't use it! I just mentioned it so you can understand.

With #8160 you can use DimmerRange 28,100 to force the minimum value of each channel to the equivalent of Dimmer 28. Of course, when a channel is off, it's value is zero.

Can you please report if the problem is solved?

[poofyteddy]

Thank's @s-hadinger for the hard work !
a couple of point after my test:

I misunderstood what #8121 did, and right now the colors gradient is still erratic after reset (i can make a quick video if needed) and touching the the colors slider does put it back to normal. So this is still to fix but it visibly nolonger overload the power supply (EDIT, i did manage to overload it after a reset, it look like it's driving both PWM identically until i touch the color wheel)

Your fix with #8160 work as advertised and i'm pretty happy with being able to chose what range to apply, event programaticaly with rule if i want, Awesome !
But i found 2 little bug.

When the web slider goes to 0, the light is turned off, but if i use the rotary dial to set is as low as possible, it only turn off one of the pwm channel (the one least dominant it seam) , the other one stay at DimmerRange minimal brightness

it seam that the way the colors step are calculated is based on brightness (you have obviously less bits to act on when the brightness is very low) and it seam it still use the 0-100% scale and not the one set by DimmerRange for this.
for example if i set DimmerRange 50-100, i will have at 1% (but truly 50%) almost no colors control

I have no idea if my last point was clear or not ... :( if it wasn't don't hesitate to tell me and i'll try to rework my sentence :)

I'v also found that changing anything with the rotary dial don't update the slider on the web app, nor log change in the console, i haven't test but i guess they won't be correctly reported by mqtt. But it's another kind of bug and i'll open it later :) i apparently don't know how to use the reload button 🤦

Once again, thank's a lot !

[s-hadinger]

For sliders, it's a web server option whether slider put to minimum turn off the light or not. Setting Dimmer 0 will always force a Power Off. I don't know how rotary works unfortunately.

Can you please explain a simple scenario to test it?

On the last statement, indeed at low brightness you can't have precise colors. That's due to the reduced number of bits.

[s-hadinger]

I looked at Rotary and by design dimmer will never go below 1. Internally it may indeed shut down one channel if its brightness is too low, and keep the other at minimal brightness.

Would turning rotary to minimum should turn the light completely off, or do you have a separate way to turn it off?

        int8_t d = Settings.light_dimmer;
        d = d + (Rotary.position - Rotary.last_position);
        if (d < 1) {
          d = 1;
        }
        if (d > 100) {
          d = 100;
        }
        DEBUG_CORE_LOG(PSTR("ROT: " D_CMND_DIMMER " %d"), Rotary.position - Rotary.last_position);

        LightSetDimmer((uint8_t)d);
        Settings.light_dimmer = d;

[poofyteddy]

now that you mention it i sound like the 2 "bug" i've encounter are the same indeed !
I was going to open an request for improvement in order to

• turn the light on to 1% if it's off and the rotary is turned up
• turn the light off when the rotary reach 0%

But i feel like this is a majors change for anyone already using the rotary function and wanted input from other on it.

On the last statement, indeed at low brightness you can't have precise colors. That's due to the reduced number of bits.
This is the issue, the brightness isn't to low, but tasmota think it is. I'm having a hard time explaining what i mean so please bear with me.

With default setting on a default theoretical dimmer who light up just enough at 1%, i should have 0 light blend capability. the more i increase brightness, the more blend i can get.
let's say at X% brightness i can have Y colors blend

brighness	number of colors blend
1%	2
5%	4
15%	16
50%	64
75%	128
100%	256

by setting dimmerrange to something like 50 100, we get something who can look like

real brighness (brighntess in tasmota )	number of colors blend
50% (1%)	2
52% (5%)	4
57% (15%)	16
75% (50%)	64
94% (75%)	128
100% (100%)	256

I realise now (writing this) that it make sens if the idea is that the light won't light up correctly under 50% ( our goal here ) so your fix make 100% sense.
With this hypothetical working light, we do loose 62 step of controls at 50% real brightness, but dimmerrange isn't made for light who work.

This in mind, the only issue i still see is that overloading after reset/flash who still occurs

[poofyteddy]

before i touche the color wheel:

00:05:19 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":22}
00:05:19 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3838"}

00:05:29 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":36}
00:05:29 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"5C5C"}

00:05:33 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":38}
00:05:34 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"6161"}

00:05:39 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":40}
00:05:40 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"6666"}

00:05:45 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":42}
00:05:46 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"6B6B"}

00:05:50 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":44}
00:05:50 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"7070"}

00:05:55 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":46}
00:05:55 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"7575"}

00:05:59 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":48}
00:05:59 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"7A7A"}

00:06:05 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":48}
00:06:05 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"7A7A"}

00:06:09 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":50}
00:06:09 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"8080"}

00:06:15 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":52}
00:06:15 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"8585"}

after i touch the color wheel:

00:07:50 CMD: backlog dimmer; color
00:07:51 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":39}
00:07:51 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3330"}

00:08:01 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":41}
00:08:01 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3633"}

00:08:06 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":43}
00:08:06 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3935"}

00:08:10 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":45}
00:08:10 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3B38"}

00:08:14 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":47}
00:08:14 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"3E3A"}

00:08:45 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":49}
00:08:45 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"403D"}

00:08:49 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":51}
00:08:49 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"433F"}

00:08:52 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":53}
00:08:53 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"4542"}

00:08:56 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":55}
00:08:56 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"4844"}

00:08:59 RSL: stat/tasmota_7A5C21/RESULT = {"Dimmer":57}
00:08:59 RSL: stat/tasmota_7A5C21/RESULT = {"Color":"4A47"}