logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[Youtube] LN882H module pinout and setup for flashing - step by step video guide

p.kaczmarek2 13596 207

TL;DR

  • A step-by-step video shows how to flash the LN882HKI/LN882H module and set it up for cloud-free OpenBeken use.
  • The process uses soldered wires, grounds one BOOT pin, and then flashes new firmware over UART, much like ESP8266 recovery.
  • As of 2026, read/write support also works with BK7231GUIFlashTool, replacing the legacy flashing tool for the same wiring setup.
  • After flashing, the firmware can pair with Home Assistant and later enable features such as DHT11 support, SSDP discovery, and Tasmota Control via OBK scripting.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #181 21811087
    xakercdcom
    Level 3  
    Posts: 3
    >>21811084
    The hole in the controller can't be fixed, and you can't buy a separate microchip on AliExpress. I also have a BL602 relay that I also burned out with my experiments, and they don't sell microchips for it either.

    Close-up of green PCB with microcontroller, capacitors, and surface-mount components.

    Close-up of electronic module with BL602L20 chip and PCB antenna
  • ADVERTISEMENT
  • #183 21828175
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    I think DR means "Dual Role" (wifi + bt), in which case it can be removed. Added it just for testing, and forgot to remove it.
    0x40012034 is unknown, but it's also in RF_P0_BASE range.
    With it, i've had no packet drops for 10 minutes (but there were some duplicates).
    But i didn't test without it.

    Anyway, what could be merged:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1964
    winnermicro spi led.
    Reasonable limit - 340 leds. After - i think there would be problems, because setting up second transaction would take time.

    https://github.com/openshwprojects/OpenBK7231T_App/pull/1963
    LN882H/LN8825 ADC, H UART (with configurable pins), H changing log port.
    Disabled berry for now, added tuyamcu driver for testing. Plus i remember there was a request for BL0942 for H.
    Fixed 8266 crash (https://github.com/NonPIayerCharacter/OpenBK7231T_App/blob/95316e3bf42fc9efae36a355138f15714977b51b/src/mqtt/new_mqtt.c#L2450)

    https://github.com/openshwprojects/OpenBK7231T_App/pull/1970
    LTR driver.
    Enabled only on W800. Interrupt not tested, but was not required anyway.

    Possibly https://github.com/openshwprojects/OpenBK7231T_App/pull/1969
    Flash vars on BK and W600 in easyflash.
    With this, every platform would support KV storage.
    Moved fast connect data from config to EF.
    Disabled log and asserts in EF so that it would be more compact.
    Removed __FILE__ macro (would return empty string).
    Disconnect from wifi on reboot/short sleep (possibly make it bk only). As it is now, first connect attempt after reboot/wake would fail with psk option.
    All in all, + about 500 bytes to .rbl on 7238.

    For review
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1972 PixelAnim effects to HA via discovery.
  • #184 21828303
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    insmod wrote:

    https://github.com/openshwprojects/OpenBK7231T_App/pull/1964

    Great, merged!
    insmod wrote:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1963

    Acceptable, merged, I had to merge platforms.md as well, but please double check.

    insmod wrote:

    LTR-303 driver
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1970

    Perfect, merged, but double check obk_config.h after that

    insmod wrote:

    For review
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1972 PixelAnim effects to HA via discovery.

    Very cool, certain merge, but just let me know - maybe we could easily use some kind of "create dropdown helper" to make it more DRY? We already have one for a button. Don't we have a dropdown helper somewhere?
    However... it seems you're using fx_ syntax, not a generic dropdown?


    insmod wrote:

    Possibly https://github.com/openshwprojects/OpenBK7231T_App/pull/1969
    Flash vars on BK and W600 in easyflash.

    Flash vars, not obk config? So we don't lose backwards compatibility?
    Would also fix flash vars overwriting BK7238 RF?
    Seems like a good idea.
    Helpful post? Buy me a coffee.
  • #185 21828317
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21828303
    Only flash vars. Config is kept as-is.

    fx_ is how wled and others do it. Light-specific from what i understand.
  • #186 21828358
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    Ok, acceptable.

    So only flash vars left - any drawbacks there? So now RF on BK7238 will survive?
    Helpful post? Buy me a coffee.
  • #187 21828378
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21828358
    Will survive, but only on new installs.
    Plus, currently there is no way to disable them (via DISABLE_FLASH_VARS_VARS)
    It might even be possible to enable HLW8112 together with BL09xx in the same build (flash vars conflict before?)
    Would be good to test it on real 8112 device.

    Single flash vars structure can also be retired? And do it like on ESPs (it needs some rework though, considering that values are always written without check)
    https://github.com/openshwprojects/OpenBK7231...ob/main/src/hal/espidf/hal_flashVars_espidf.c
  • #188 21828563
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Easyflash holding flashvars on W600 would also allow enlarging config over the actual flashvars area so config V4+ would be possible without moving own flashvar structure.
    Downgrade will loose data, since it's not aware of the changes.
    But that was always the case (CRC over the whole V4 range will be different to the CRC over V3 config.)
  • ADVERTISEMENT
  • #189 21828825
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    If this let's BK7238 RF survive, then we need to merge it ASAP.

    Are there any potential drawbacks to merging this easyflash flashvars change?

    We can retire single flashvars struct later, but we need to analyze carefully how to split that, to avoid adding too big extra overheat.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #190 21829124
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    The only thing i've noticed is that first boot is slower, probably because it's erasing env area.
    What i tested: T, N, N_ALT and 8. If they work, then the rest will work too.
    Plus new sdk always logs when it's switching flash protect on/off.

    P.S i put flash vars at 0x1E5000, because on T1 there is some encrypted data at 0x1E4000, that looks similar to tuya config.
  • #191 21829144
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    So the place you chose is not overwriting anything? It's unused on Bekens?
    Helpful post? Buy me a coffee.
  • #192 21829162
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    Yes. begins at 0x1E5000 and ends at 0x1ED000, right before tuya config first block on T and N.
  • #193 21829373
    DeDaMrAz
    Level 22  
    Posts: 594
    Help: 34
    Rate: 122
    I tested the 1969 PR on N just now, all I have to say is - I can't figure out how to measure reboot time, it is that fast, will try to monitor the uart output to figure out what is going on....

    as @p.kaczmarek2 said it feels like reboot is broken :D

    @insmod Anything else changed to be aware of??
  • #194 21829677
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    Why would reboot speed change there? Or do you mean reconnect to WiFi speed?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #195 21830400
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    I think we need this. I merged it.

    Please double check on release, just in case.
    Helpful post? Buy me a coffee.
  • #196 21830408
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21830400
    Updated my N plug to 1.18.255. Works fine (at least for now).
    But it started spamming Button_OnLongPressHold. It didn't on 1.18.247_ALT (at least i don't think so, i've had logging disabled).
  • #197 21830536
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    Why would buttons behaviour change? Wasn't it untouched?
    insmod wrote:

    Disconnect from wifi on reboot/short sleep (possibly make it bk only). As it is now, first connect attempt after reboot/wake would fail with psk option.
    .

    @DeDaMrAz maybe that's what you mean by quick reboot? You mean... quick reconnect?
    Helpful post? Buy me a coffee.
  • #198 21830760
    DeDaMrAz
    Level 22  
    Posts: 594
    Help: 34
    Rate: 122
    p.kaczmarek2 wrote:
    maybe that's what you mean by quick reboot? You mean... quick reconnect?


    Not what I have seen, both reboot and reconnect worked and are quick, haven't seen failed WiFi reconnects... maybe I am wrong as my tests were short and I haven't observed the TX2 output I was more focused on other aspects, LFS, startup commands, last state.....
  • #200 21830986
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    Ahhh, I see. Silly mistake, please open PR. That expression always evaluates to true!
    Helpful post? Buy me a coffee.
  • #202 21831066
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    Thanks for the fix, how did you spot it?

    Interesting, PR and issues indexes seem to line up.
    Helpful post? Buy me a coffee.
  • #203 21831071
    divadiow
    Level 38  
    Posts: 4835
    Help: 420
    Rate: 851
    p.kaczmarek2 wrote:
    how did you spot it?


    My PR or the later insmod one to fix ln8825?

    I just asked LLM 😳 and the issues user confirmed with build
  • #204 21831379
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14390
    Help: 650
    Rate: 12313
    We probably need to try this LLM PR review tool, how it was called, CodeRabbit? The one that was free on public repositories?

    What do you think , @divadiow @insmod
    Helpful post? Buy me a coffee.
  • #205 21831383
    divadiow
    Level 38  
    Posts: 4835
    Help: 420
    Rate: 851
    ooh. never heard of it. I am interested.
  • #206 21834036
    divadiow
    Level 38  
    Posts: 4835
    Help: 420
    Rate: 851
    so, is there any use for this now?

    Screenshot snippet of a table: “Read Beken FlashVars (unused?)” and the link “Download Flash Vars”.
  • #208 21856219
    insmod
    Level 31  
    Posts: 1353
    Help: 160
    Rate: 425
    >>21856209
    Flash vars - yes, config - no. It's still at the same offset and is not stored in easyflash.

    Z2 flasher, use dump words instead of dump bytes for faster read times?
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion centers on flashing the LN882H (specifically LN882HKI) module using open-source tools and firmware such as OpenBeken and OpenBK7231T_App, with detailed guides and video tutorials available. Flashing involves grounding the BOOT pin and using UART communication, which employs ASCII commands and the YMODEM protocol for data transfer. Several tools have been developed and shared, including LN882Loader (Linux-based) and Windows GUI wrappers, with ongoing improvements to support faster flash reading and dumping via commands like "fdump." Users report challenges with UART adapters, power supply stability, and correct COM port usage, highlighting the importance of proper hardware setup (e.g., CH340G vs. FTDI232 UART adapters). SSDP support and Home Assistant integration are discussed, with SSDP requiring IGMP flag enabling and driver activation in firmware. GPIO pin behavior and limitations are examined, noting that certain pins (A13 to B2) are reserved for QSPI flash and should not be used as GPIO outputs. Firmware versions and SDK updates are tracked, with reverse engineering efforts revealing internal flash structures and configuration data. WiFi stability issues on LN882H modules are reported, potentially linked to power supply quality or environmental factors, distinct from BK7231N platform behavior. Pinout details for LN882HK1 modules are clarified, identifying UART TX and RX pins and the BOOT pin for flashing mode entry. Overall, the community collaborates on improving flashing tools, firmware features, and hardware understanding to enable cloud-free operation and integration with smart home systems.
Generated by the language model.
Today's popular

FAQ

TL;DR: Backing up 2MB from LN882H went from about 14 minutes to 12.5–24.8 seconds, and one tester confirmed, "SmartLife AP seen and pairs in Tuya app." This FAQ is for people flashing LN882H/LN882HKI modules with OpenBeken, restoring Tuya backups, and fixing UART, Wi‑Fi, GPIO, and SSDP issues. [#21609499]

Why it matters: LN882H devices often look simple to flash, but real success depends on correct boot wiring, stable 3.3V power, the right RAM loader, and avoiding reserved GPIOs.

Tool Best use OS Read/backup speed reported Notes
SharpLN882HTool Flash, erase, backup, restore Windows 24.77s at 921600; 47.52s at 460800 Later builds restored full Tuya dumps successfully
LN882Loader Linux flashing and backup Linux Earlier full 2MB dumps around 10–14 min Reverse-engineered, YMODEM-based
Tuya flasher / tyutool_cli Vendor flashing Windows / Linux extraction Read not supported in tyutool_cli One user saw: "Don't support read."

Key insight: The biggest breakthrough was not the firmware itself but the RAMCODE path: once the custom dumper switched to raw binary reads with CRC and stable UART polling, LN882H backup and restore became fast enough to be practical for everyday recovery and migration. [#21608266]

Quick Facts

  • Full-flash backup size is 2MB, and one successful custom dumper run finished in 12.5 seconds at 921600 baud after RAMCODE improvements. [#21608190]
  • Earlier dump methods were much slower: 2MB in ~14 min 20 s with LN882H_RAM_BIN.bin, and about 9 min 50 s after changing baud and stub choices. [#21605883]
  • A validated speed comparison for SharpLN882HTool v22 showed 184.05 s at 115200, 47.52 s at 460800, and 24.77 s at 921600, with identical SHA-256 hashes across those dumps. [#21609499]
  • Safe UART access points identified on a bare LN882HK1-on-PCB board were A2 = TX0, A3 = RX0, A9 = pull low for UART download mode, and B9 = TX1 boot log, often at 921600 baud. [#21593199]
  • One reproducible GPIO failure on LN882H was P13 crashing on “Set Output High” in firmware 1.18.42, later linked to flash/QSPI-reserved pins that should not be driven as normal outputs. [#21446468]

1. How do I flash an LN882H or LN882HKI module with OpenBeken step by step using UART and the BOOT pin?

You flash LN882H over UART by grounding one BOOT pin, powering the board at 3.3V, and sending a RAM loader before the firmware. 1. Solder GND, 3.3V, TX, RX, and the BOOT pin. 2. Hold BOOT low, power up, then connect with a flasher tool. 3. Upload the RAM loader, then write OpenBeken to flash at 0x0. The original guide says LN882H flashing is “very similiar to ESP8266,” with BOOT grounded to enter flashing mode. [#21372895]

2. Where are TX, RX, and boot-mode pins on an LN882HK1 chip mounted directly on the PCB, and how do I identify them safely?

On one directly mounted LN882HK1 board, the reported pins were A2 for TX0, A3 for RX0, A9 for boot-mode entry, and B9 for TX1 boot logs. Safest identification uses labeled pads, board photos, and UART observation before soldering to tiny chip legs. 1. Find GND, 3.3V, and EN first. 2. Check nearby pads against known LN882H pin maps. 3. Confirm with a logic analyzer or boot log on B9 before forcing boot mode. [#21593199]

3. Why does LN882H flashing fail with a USB-to-UART adapter even when it has a 3.3V output, and how can I troubleshoot power and COM port issues?

LN882H flashing often fails because the adapter is not actually transmitting, the COM port is wrong or busy, or the 3.3V rail is unstable under load. One user fixed repeated failures by replacing a faulty FTDI232 adapter with a CH340G unit; another was told to verify COM6 and check for port-hogging software like Cura. A separate report also found that an AMS1117-based 3.3V source improved flashing stability. [#21443865]

4. What is YMODEM, and how is it used by LN882H flashing tools and RAM loaders?

“YMODEM” is a serial file-transfer protocol that sends block-based data with acknowledgements and CRC checks, enabling reliable firmware or RAM loader transfer over UART. LN882H tools use YMODEM to upload the temporary RAM loader first, then often use it again to write the actual firmware image. Reverse-engineering in the thread identified YMODEM as the protocol behind the loader flow, and later tool logs showed ACK, EOT, CRC, and packet counters exactly matching that process. [#21376683]

5. What is SSDP discovery, and why did Alexa or Wemo emulation not work on LN882H until SSDP support was enabled?

Alexa and Wemo emulation did not work because LN882H lacked SSDP support in earlier builds. “SSDP discovery” is a local-network service discovery protocol that advertises devices over multicast, letting controllers like Alexa find compatible endpoints automatically. In the thread, Wemo emulation showed up in setup.xml, but Alexa still could not discover it until SSDP and the related networking support were enabled on LN882H. A later post said SSDP had been enabled the previous week. [#21430384]

6. LN882Loader vs SharpLN882HTool vs Tuya's LN882H flasher — which tool is best for flashing, backup, and restore on Windows or Linux?

SharpLN882HTool became the best all-around choice for Windows once fast dump, erase, and restore worked; LN882Loader stayed strong for Linux; Tuya’s tools were useful for reference but weaker for backup. A tester confirmed SharpLN882HTool erased flash, wrote OpenLN882H, restored a full Tuya dump, and then saw the “SmartLife AP” pair in the Tuya app. Another user also reported tyutool_cli could communicate with the chip but ended with “Don't support read.” [#21609499]

7. Why is dumping LN882H flash so slow with flash_read or fdump, and how did the custom RAMCODE speed it up?

The old dump path was slow because it read tiny chunks as ASCII hex over UART instead of sending raw bytes. One developer explained that flash_otp_read 0x0 0x100 returned text like AE BE 4F 2D 5A, meaning roughly 3 characters per stored byte. The custom RAMCODE changed the method to raw binary blocks plus CRC, which removed the ASCII overhead and made full 2MB reads practical in seconds instead of minutes. [#21607145]

8. How can I back up the full 2MB flash from an LN882H module and restore that backup later without losing Tuya or OpenBeken data?

You can back up the full 2MB flash, erase the chip, and later restore that exact image to recover Tuya or OpenBeken. 1. Use a tool that reads the full 0x200000 flash range to a file. 2. Save that dump before experimenting. 3. If needed, erase flash and write the saved file back at 0x0. A tester erased an LN882H, reflashed a Tuya dump with SharpLN882HTool, and confirmed the SmartLife AP appeared and paired in the Tuya app. [#21609499]

9. Which LN882H GPIOs are unsafe to drive as outputs, and why do some pins cause WDT resets or crashes in GPIO Doctor?

Some LN882H pins mapped to the internal flash/QSPI area are unsafe as normal outputs and can trigger crashes or WDT resets. One contributor stated that pins from A13 to B2 should not be used because they are reserved for QSPI, likely internal flash. Real testing also showed repeatable crashes, including P13 on “Set Output High” in version 1.18.42, and later fixes focused on disabling those dangerous pins in HAL. [#21446533]

10. How do I use GPIO Doctor or manual testing to find the relay, button, LED, and PWM pins on an unknown LN882H device?

Use GPIO Doctor carefully, starting with inputs and low-risk checks, then test outputs one at a time while watching for crashes. 1. Back up flash first. 2. Probe candidate pins as digital input or input-pullup before driving outputs. 3. Map relay, LED, button, and PWM by changing one pin at a time and noting physical responses. This matters on LN882H because some pins can crash the device, yet the same method still helped users identify working relay and PWM pins on unknown boards. [#21446543]

11. What Wi-Fi settings are actually available in OpenBeken for LN882H besides Power Save, and what else can cause random disconnects on one network but not another?

Beyond Power Save, the thread only names Quick Connect as another practical LN882H Wi‑Fi option in OpenBeken. A developer added that Wi‑Fi behavior mainly comes from the LN882H SDK, not shared OBK code, so stability can change by platform. In the reported disconnect case, likely causes included local RF noise, supply quality, MQTT load, and possibly flash state or calibration, especially because the same device stayed stable for 3 days on a different network. [#21579867]

12. Why did WPA3 or WPA2/WPA3 connections fail on older LN882H SDK builds, and what changed in the newer Wi-Fi library versions?

Older LN882H builds failed on WPA3 because the Wi‑Fi library rejected association, including repeated reason code 43 errors. That changed after the SDK moved to newer Wi‑Fi libraries, including WiFi Lib 1.5.0, where one tester successfully joined a WPA‑SAE (CCMP) access point and verified fast reconnection after the AP returned. The same tester also said WPA2-only and mixed WPA2/WPA3 then behaved correctly. [#21615134]

13. How does the faster custom LN882H RAM dumper work, including baud rate, CRC checks, and polling vs interrupt-based UART TX?

The faster dumper uploads a custom RAMCODE, reads flash in fixed binary blocks, appends a 2-byte CRC16 to each block, and transmits over a high UART baud rate. One implementation used 512-byte flash blocks plus CRC and achieved stable dumps at 921600 baud after switching UART TX from interrupt mode to polling mode. The author said polling was not faster by itself, but it was more stable and fixed CRC failures seen at higher baud rates. [#21610067]

14. What does LN882H RAMCODE do during flashing, and how is it different from the normal bootloader or secondary boot stage?

RAMCODE is a temporary program sent over UART into RAM so the chip can erase, write, dump, and inspect flash using richer commands than the ROM alone provides. “RAMCODE” is a RAM-resident helper program that runs after UART boot, adds flash commands, and then hands control back or resets after the task finishes. The SDK description in the thread distinguishes it from the normal bootload stage, which is the secondary boot path from flash to app during standard startup. [#21605903]

15. How can I build a custom OpenBeken OTA firmware for LN882H with extra drivers like SHT3X enabled, either locally or through GitHub Actions?

You can build it locally or through GitHub Actions by enabling the driver macro for LN882H. The thread’s build steps say to add #define ENABLE_DRIVER_SHT3X 1 under #elif PLATFORM_LN882H in src/obk_config.h, then run make OpenLN882H locally. If you do not have the toolchain, fork the repository, enable Actions on the fork, commit the config change, and download the finished firmware artifact from the workflow summary. [#21709798]
Generated by the language model.
ADVERTISEMENT