There may be still some not added templates in the existing posts.
probably!
We would also need to check our ESP devices teardowns. They should be on Teardowns List as well, but they are often not added there due to the lack of time.
divadiow wrote:
p.kaczmarek2 wrote:
Internal temperature?
must be? I wonder how the power management differs to OBK code, what powersave level is used.
I wonder if we could try to compare the heating before and after flashing. Is OBK more or less efficient in that manner? Still, this would require a good measurement method. @DeDaMrAz has thermal camera that could do it.
I already know that in case of BK7231 devices the heating after flashing can be increased if you don't also enable PowerSave. Still, for now, PowerSave is not enabled by default, because of stability concerns - it seems that PowerSave breaks IR receiving (sending?) and BL0937 measurement.
I unfortunately bent the coil(?) and only later realized I can probably poke it out through the two holes on the inside... how do you otherwise remove that without damaging it, it seems very fragile? I ended up rescrewing it by force which sort of re-threaded it.
The OG Python script does not handle errors, I have forked it and gave it some resiliency, now one can actually see progress and it retries on errors -
https://github.com/C0rn3j/LN822H_dump_tool
It still crashed at the very end overwriting the FW it had until then, yet to fix that one:
```
.............Traceback (most recent call last):
File "C:\Users\SadCyclops\Downloads\LN882H_CMD_TOOL\LN882H_Flash_Dumper.py", line 81, in <module>
read_flash(flash_file, arg_port, flash_size)
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\SadCyclops\Downloads\LN882H_CMD_TOOL\LN882H_Flash_Dumper.py", line 26, in read_flash
bin = bytearray.fromhex(flash_hex)
ValueError: non-hexadecimal number found in fromhex() arg at position 23
```
Eventually I got the FW dumped and flashed OpenBeken, re-assembled it, configured Wi-Fi, configured the pinouts and startup command to swap red and blue as per the existing 9W device entry.
Nah, I don't think it's powersave. I think the default BP5758 current in OBK is higher than current used by these bulbs, that's why they are hot by default.
Default current in OBK is 14ma, but 10 is good even for GU10 bulbs.
I've about 10 of them, all with ESP32-C2 with ESPHome. Temperature goes up to about 80 °C.
LN882H is just very hot by itself.
The discussion centers on disassembling and setting up a Tuya-based RGB smart light bulb featuring the LN882HKI chip and a BP5758D LED driver. Initial disassembly was straightforward, and the user successfully backed up the chip firmware and flashed OpenBK (OBK) firmware at 115200 baud after failed attempts at higher speeds. Challenges included identifying correct GPIO pins for PWM control and interfacing with the BP5758D chip, which requires proper SDA and SCL pin mapping. Continuity testing with a multimeter was advised but caused device damage when performed on a powered device. Contributors developed and shared device templates and firmware patches to enable BP5758D driver support on LN882H-based bulbs, including pin mappings and LED channel configurations (e.g., "BP5758D_Map 3 4 2 0 1" and "2 1 0 3 4"). Thermal management issues were noted, with CPU temperatures reaching up to 100°C at full brightness, prompting recommendations to limit brightness and use BP5758D_Current commands to reduce power. Stability concerns remain, especially with MQTT and RGB loops causing disconnections. Firmware dumping tools and flashing procedures were discussed, including correct wiring for UART pins (notably reversed TX/RX lines) and boot mode pin grounding (P21/A9). The community shared resources such as firmware repositories, device templates, and documentation links to assist with flashing, configuration, and troubleshooting. The final confirmed device model is W509Z2, a 220V 9W E27 ES RGB+CCT bulb with LN882H chip and BP5758D LED driver. The discussion also touched on thermal imaging equipment for temperature assessment and comparisons of power management between original and custom firmware. Summary generated by the language model.
