[LN882H] [WL2S] Elivco 20A BSD34 EU Power Monitoring Plug [BL0937]

divadiow 12135 38

TL;DR

Teardown and OpenBeken flashing of an Elivco/BSD34 20A EU smart plug using a WL2S module with Lightning Semiconductor LN882H and BL0937 power monitoring.
The WL2S module was desoldered, the A9/BOOT pad grounded to enter BOOT mode, the factory firmware dumped, then OpenLN882H UART firmware downloaded and the module resoldered.
A modified LN882H_Flash_Dumper capped the dump at 0x00200000, and the slow read took about 30-40 minutes.
OBK found A0 for the red LED, A3 for the button, A10 for the blue LED, and A11 for the relay; the plug worked, but BL0937 support was still nonfunctional.

Generated by the language model.

Report a violation of the law

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

Helpful post

Post #1

20935260 29 Jan 2024 19:35

Hello

I present my efforts with an Elivco 20A smart plug with power monitoring features. I first saw this variant in this thread here when sithyoda posted about a new Tuya module, the WL2S, which uses a Lightning Semiconductor LN882HKI chip. Fast-forward a few weeks and OpenBeken was developed to run on the LN882H chips thanks to the hard work of several posters in that thread. @p.kaczmarek2 has now posted a LN882H flashing guide here.

Other LN882H based modules and devices are being seen, including the usual 16A DIY mini switches of the Cozylife flavour.

This smart plug is not labelled as Elivco or LSPA9, as seen on @sithyoda's original post, but is instead marked as a BSD34, which is also seen here using a CB2S module and branded as Ledlux. It's also been seen with an ESP module in the past.

As with most of my toys, this was purchased from Ali Express, specifically from the Digitaling store.

I live in the UK, so have no immediate use for an EU plug, but I was intrigued to get my own WL2S to open and flash with OpenBK.

External pics of the unit and packaging received 5 days after the order was placed:

From teardowns in other posts, and by visual inspection, it was obvious where the unit would open up, -where the unit was glued/clipped along the top rim. Not happy with how some of the UK plug I've had to open have turned out, all gnarled up and battered, I sought a better, less destructive way. Maybe EU plugs are generally easier anyway, but this method was excellent for opening

.

The casing is a little different and I don't have F clamps, but I did use G-clamps and a bit of targeted force. Position the clamps just below the joining line then tighten until you hear the glue cracking - then loosen and move to a slightly new place and tighten again. Quite quickly the unit broke open without damage. With the top loose only the earth wire keeps the two sections joined.

Unscrewing fully the single screw on the PCB allowed me to push the two power prongs up and out of the case. I had to loosen the earth screw slightly to move the connector round a bit to allow the PCB to slide out.

Now that it's free I can photograph the internals:

silkscreen: BSD34-202110

Knowing this unit has powering monitoring by way of a BL0937 chip and not wanting this to get in the way of any flashing efforts (and also the angle and position of the module makes access to some of the pads difficult for in situ flashing), I took the plunge to desolder the entire WL2S module. I first applied lots of flux to both sides of the board, covering the soldered contacts completely. I then used extra pb solder to make a single sausage blob of solder along both sides, so the factory solder was melted and mixed into one. I then pasted copper solder braid with flux and used the soldering iron to soak up all solder. Very quickly the module dropped out of the main board. This technique has been demonstrated by Elektroda:

After cleaning the module with isopropyl alcohol I set up pogo pins connected to a USB-TTL adaptor, and separate (ie not the VCC from the USB adaptor) 3.3v power supply.

TX0 -> USB-TTL RX
RX0 -> USB-TTL TX
GND -> USB-TTL GND
3V3 -> External 3.3V PSU
External 3.3V PSU GND -> USB-TTL GND (so all 3 share a ground)

with this config, I could collect the uart boot log on power-up, which output as:

bootloader build time: 13:48:19
config item not found perip_param value
-- tuya project compile time: Jun 27 2023 16:30:24--
ble mac[e3:c7:f2:e1:82:c4]
[BLIB_I]BLIB Ver: 1.0.3 [build time:Jan 19 2023 12:14:45][0x010003ff]
xTaskCreate, name: rw_task, priority: 9, stack size: 2048
xTaskCreate, name: worker, priority: 2, stack size: 1536
xTaskCreate, name: ty_main, priority: 3, stack size: 4096
xTaskCreate, name: IDLE, priority: 0, stack size: 1024
xTaskCreate, name: Tmr Svc, priority: 10, stack size: 2048
Before enter tuya_main, Total:165888; Free:153552
GPIOA_9 high level, will enter Normal mode!
Failed to enter ate mode! Start tuya user main.
xTaskCreate, name: tuya_app_main, priority: 4, stack size: 4096
xTaskCreate, name: TUYA_TCPIP, priority: 9, stack size: 2048
tkl_ethernetif_init
tkl_ethernetif_init
[01-01 00:00:00 ty I][lr:0x100b662b] mqc app init ...
xTaskCreate, name: wq_system, priority: 3, stack size: 5120
[01-01 00:00:00 ty I][tal_thread.c:184] thread_create name:wq_system,stackDepth:                                                                                   5120,totalstackDepth:7168,priority:3
xTaskCreate, name: wq_highpri, priority: 4, stack size: 4096
[01-01 00:00:00 ty I][tal_thread.c:184] thread_create name:wq_highpri,stackDepth                                                                                   :4096,totalstackDepth:11264,priority:4
xTaskCreate, name: sys_timer, priority: 5, stack size: 4096
[01-01 00:00:00 ty D][tal_thread.c:203] Thread:wq_highpri Exec Start. Set to Run                                                                                   ning Stat
[01-01 00:00:00 ty D][tal_thread.c:203] Thread:sys_timer Exec Start. Set to Runn                                                                                   ing Stat
[01-01 00:00:00 ty I][tal_thread.c:184] thread_create name:sys_timer,stackDepth:                                                                                   4096,totalstackDepth:15360,priority:5
[01-01 00:00:00 ty D][lr:0x10078c65] init fs. Path: null
[01-01 00:00:00 ty D][lr:0x100aa331] *****************kvs_init.
[01-01 00:00:00 ty D][lr:0x100cdbe1] protected init. addr:0x001eb000
[01-01 00:00:00 ty D][lr:0x100cd9f1] init protected data length 495
[01-01 00:00:00 ty N][lr:0x100ac72b] key_addr: 0x1ec000   block_sz 4096
[01-01 00:00:00 ty N][lr:0x100aca05] get key:
0xaf 0x5 0x23 0x8e 0x2b 0xbe 0xbc 0x6f 0xda 0xc6 0x16 0x50 0x76 0x4d 0x78 0xbb
[01-01 00:00:00 ty D][lr:0x100cdbff] protected verify begin
[01-01 00:00:00 ty D][lr:0x100cdc61] check [gw_bi][282]
[01-01 00:00:00 ty D][lr:0x100cdc61] check [gw_wsm][141]
[01-01 00:00:00 ty D][lr:0x100cdc81] protected verify end
[01-01 00:00:00 ty D][lr:0x100ab97f] begin try update kv version
[01-01 00:00:00 ty D][lr:0x100ab99b] pre kv version is 2
[01-01 00:00:00 ty D][lr:0x100acea1] 111 k=3  i=18 0
[01-01 00:00:00 ty N][lr:0x100b2729] uni_random_init...
[01-01 00:00:00 ty N][lr:0x100b29cd] tuya_tls_rand_init ok!
[01-01 00:00:00 ty D][lr:0x10090ef9] init watchdog, interval: 60
----- tkl_watchdog_init
wdg shift_left_num:0x10, set num:65535, top:0x0d
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:0
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:1
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:2
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:3
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:4
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:5
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:6
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:7
[01-01 00:00:00 ty D][lr:0x10090e4b] add new node,type:8
[01-01 00:00:00 ty D][lr:0x10091009] watch_dog_interval:60, monitor_detect_inter                                                                                   val:600
xTaskCreate, name: health_monitor, priority: 5, stack size: 1536
[01-01 00:00:00 ty D][tal_thread.c:203] Thread:health_monitor Exec Start. Set to                                                                                    Running Stat
[01-01 00:00:00 ty I][tal_thread.c:184] thread_create name:health_monitor,stackD                                                                                   epth:1536,totalstackDepth:16896,priority:5
[01-01 00:00:00 ty D][lr:0x100b6531] mq_pro:5 cnt:1
[01-01 00:00:00 ty D][lr:0x100b6531] mq_pro:31 cnt:2
[01-01 00:00:00 ty D][lr:0x100b15b5] svc online log init success
[01-01 00:00:00 ty E][lr:0x100b5d3f] logseq empty
[01-01 00:00:00 ty N][lr:0x1006afcf] < TuyaOS V:3.5.4 BS:40.00_PT:2.3_LAN:3.5_CA                                                                                   D:1.0.5_CD:1.0.0 >
< BUILD AT:2023_01_09_16_12_01 BY ci_manage FOR tuyaos-iot AT ln882h >
IOT DEFS < WIFI_GW:1 DEBUG:1 KV_FILE:0 LITTLE_END:1 SL:0 OPERATING_SYSTEM:98 REL                                                                                   IABLE_TRANSFER:0 >

[01-01 00:00:00 ty N][lr:0x1006afd9] ln_elec_plug:1.0.4
[01-01 00:00:00 ty N][lr:0x1006afe3] firmware compiled at Jul  5 2023 15:01:06
[01-01 00:00:00 ty N][lr:0x1006affd] REST INFORMATION IS 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,over_vol: is 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,lose_vol: is 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,over_cur: is 20000
[01-01 00:00:00 ty N][lr:0x1006b28f] ,chip_type: is 0
[01-01 00:00:00 ty N][lr:0x1006b28f] ,ele_fun_en: is 1
[01-01 00:00:00 ty N][lr:0x1006b25f] ,ele_pin: is 26
[01-01 00:00:00 ty N][lr:0x1006b25f] ,vi_pin: is 8
[01-01 00:00:00 ty N][lr:0x1006b25f] ,sel_pin_lv: is 1
[01-01 00:00:00 ty N][lr:0x1006b25f] ,sel_pin_pin: is 24
[01-01 00:00:00 ty N][lr:0x1006b25f] ,resistor: is 1
[01-01 00:00:00 ty N][lr:0x1006b28f] ,vol_def: is 0
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,zero_select: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,zero_t: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,zero_io_pin: is not exsit  1
[01-01 00:00:00 ty N][lr:0x1006b28f] ,ffc_select: is 0
[01-01 00:00:00 ty N][lr:0x1006b28f] ,rl1_type: is 0
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,rl_type: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,rl1_drvtime: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,rl_drvtime: is not exsit  1
[01-01 00:00:00 ty N][lr:0x1006b28f] ,jv: is 1.0.4
[01-01 00:00:00 ty N][lr:0x1006b28f] ,module: is CB2S
[01-01 00:00:00 ty N][lr:0x1006b28f] ,net_trig: is 4
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,total_led_lv: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,total_led_pin: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,total_bt_lv: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,total_bt_pin: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,bt_type: is not exsit  1
[01-01 00:00:00 ty N][lr:0x1006b28f] ,bt1_type: is 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,netled1_lv: is 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,netled1_pin: is 7
[01-01 00:00:00 ty N][lr:0x1006b28f] ,nety_led: is 0
[01-01 00:00:00 ty N][lr:0x1006b28f] ,netn_led: is 1
[01-01 00:00:00 ty N][lr:0x1006b28f] ,netled_reuse: is 0
[01-01 00:00:00 ty N][lr:0x1006b25f] ,reset_t: is 5
[01-01 00:00:00 ty N][lr:0x1006b28f] ,ch1_stat: is 2
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,total_stat: is not exsit  1
[01-01 00:00:00 ty N][lr:0x1006b25f] ,ch_num: is 1
[01-01 00:00:00 ty N][lr:0x1006b131] channal num is 1
[01-01 00:00:00 ty N][lr:0x1006b38b] ,rl1_lv: is 1
[01-01 00:00:00 ty N][lr:0x1006b38b] ,rl1_pin: is 6
[01-01 00:00:00 ty D][lr:0x1006b31d] ,rl_on1_lv: is not exsit 5
[01-01 00:00:00 ty D][lr:0x1006b31d] ,rl_on1_pin: is not exsit 5
[01-01 00:00:00 ty D][lr:0x1006b31d] ,rl_off1_lv: is not exsit 5
[01-01 00:00:00 ty D][lr:0x1006b31d] ,rl_off1_pin: is not exsit 5
[01-01 00:00:00 ty N][lr:0x1006b38b] ,bt1_lv: is 0
[01-01 00:00:00 ty N][lr:0x1006b38b] ,bt1_pin: is 10
[01-01 00:00:00 ty N][lr:0x1006b38b] ,led1_lv: is 0
[01-01 00:00:00 ty N][lr:0x1006b38b] ,led1_pin: is 23
[01-01 00:00:00 ty N][lr:0x1006b38b] ,ch_dpid1: is 1
[01-01 00:00:00 ty N][lr:0x1006b38b] ,ch_cddpid1: is 9
[01-01 00:00:00 ty D][lr:0x1006b1dd] ,ble_pair_time: is not exsit  1
[01-01 00:00:00 ty D][lr:0x1006b6b3] get_measure_chip_type is 0
[01-01 00:00:00 ty D][lr:0x1006b727] get_standard_vol is 0
[01-01 00:00:00 ty D][lr:0x1006b6b3] get_measure_chip_type is 0
[01-01 00:00:00 ty N][lr:0x1006b929] product have measure , chip is 0 vol is 220                                                                                   0  res is 1
[01-01 00:00:00 ty D][lr:0x10078c65] init fs. Path: null
[01-01 00:00:00 ty D][lr:0x100aa331] *****************kvs_init.
[01-01 00:00:00 ty N][lr:0x10097513] mf is open need stop fastconnect
[01-01 00:00:00 ty D][lr:0x1007b151] mf_core_init success
[01-01 00:00:00 ty D][lr:0x100cde05] protected read [gw_bi]
[01-01 00:00:00 ty D][lr:0x100cde93] protected read ret:0 length:282
[01-01 00:00:00 ty D][lr:0x1008e8eb] gw_bi read ret:0
set work mode 1, is open 0, current ln mode: 0
wifi not start, turn on first
adapt wifi start <m:1>, hw_ready:0
start rf preprocess and image cal
[WLIB_E]idx=00, iq_hex_cal=0x7B7F, i=123, q=127, iavg= 35, qavg= 37
[WLIB_E]idx=01, iq_hex_cal=0x797C, i=121, q=124, iavg= 69, qavg=  3
[WLIB_E]idx=02, iq_hex_cal=0x7679, i=118, q=121, iavg= 10, qavg=  4
[WLIB_E]idx=03, iq_hex_cal=0x7173, i=113, q=115, iavg= 25, qavg= 72
[WLIB_E]idx=04, iq_hex_cal=0x6870, i=104, q=112, iavg=  4, qavg= 47
[WLIB_E]idx=05, iq_hex_cal=0x7B7F, i=123, q=127, iavg= 52, qavg= 38
[WLIB_E]idx=06, iq_hex_cal=0x7A7D, i=122, q=125, iavg= 46, qavg=  7
[WLIB_E]idx=07, iq_hex_cal=0x7779, i=119, q=121, iavg= 57, qavg=  9
[WLIB_E]idx=08, iq_hex_cal=0x7273, i=114, q=115, iavg= 35, qavg= 89
[WLIB_E]idx=09, iq_hex_cal=0x6A70, i=106, q=112, iavg=  9, qavg= 44
[WLIB_E]idx=10, iq_hex_cal=0x7B7F, i=123, q=127, iavg= 55, qavg= 39
[WLIB_E]idx=11, iq_hex_cal=0x7A7D, i=122, q=125, iavg= 40, qavg=  3
[WLIB_E]idx=12, iq_hex_cal=0x7779, i=119, q=121, iavg= 51, qavg= 11
[WLIB_E]idx=13, iq_hex_cal=0x7273, i=114, q=115, iavg= 38, qavg= 77
[WLIB_E]idx=14, iq_hex_cal=0x6B70, i=107, q=112, iavg=  4, qavg= 58
[WLIB_E]idx=15, iq_hex_cal=0x7B7F, i=123, q=127, iavg= 54, qavg= 34
[WLIB_E]idx=16, iq_hex_cal=0x7A7C, i=122, q=124, iavg= 40, qavg=  3
[WLIB_E]idx=17, iq_hex_cal=0x7778, i=119, q=120, iavg= 50, qavg=  3
[WLIB_E]idx=18, iq_hex_cal=0x7274, i=114, q=116, iavg= 49, qavg= 72
[WLIB_E]idx=19, iq_hex_cal=0x6A70, i=106, q=112, iavg=  9, qavg= 79
[WLIB_E]idx=20, iq_hex_cal=0x7A7F, i=122, q=127, iavg= 29, qavg=100
[WLIB_E]idx=21, iq_hex_cal=0x787E, i=120, q=126, iavg= 38, qavg= 46
[WLIB_E]idx=22, iq_hex_cal=0x747B, i=116, q=123, iavg= 41, qavg= 51
[WLIB_E]idx=23, iq_hex_cal=0x6E78, i=110, q=120, iavg= 51, qavg= 78
[WLIB_E]idx=24, iq_hex_cal=0x6376, i= 99, q=118, iavg= 45, qavg= 52

Then with A9/BOOT pad grounded I could continue with the factory flash dump and upload of the work-in-progress LN882H OBK firmware.

Unplug USB-TTL, power off external 3.3v
Plug in USB-TTL with A9/BOOT ground (and all other connections) in place
Power up 3.3v

The LN882H will see that A9 is pulled low and enter BOOT mode and await flashing.

Using a slightly modified LN882H_Flash_Dumper.py (with flash size capped at 0x00200000 after this discovery), I dumped the factory firmware which I attach to this post. I also attach the modified LN882H_Flash_Dumper.py, which will instead say complete when it hits 2mb, rather than erroring.

python LN882H_Flash_Dumper.py COMx flashdump

The dump speed is fixed and is very slow, so this took ~30-40 minutes.

After unplugging and replugging everything to reset and get into BOOT mode again, I could download (that is, download to the device from my PC) the latest OpenLN UART flash firmware. This was all done from the LN882H_CMD_TOOL (see flashing guide thread), where OpenLN882H_1.17.432.bin had been downloaded.

LN882H_CMD_Tool.exe COM9 download flash 2000000 0x0 OpenLN882H_1.17.432.bin

The output from this is just an "OK!". Thankfully this step only took a few seconds to complete.

Removing the A9/BOOT gnd and resetting the power resulted in a new "LN882H_XXX" AP to which I connected and got a 192.168.4.100 IP address.

browsing to 192.168.4.1 presents you with the OBK web config pages

With a steady hand, plenty of flux, a small point on the soldering iron and some patience I soldered the module back in place. I think I did OK!

Thanks to @sithyoda is looks like we have the GPIOs for the BL0937 but I don't believe we can test this yet (as at 29th January 2024) as the driver is not functional.

Using the GPIO finder in the web app I was able to determine the following for the other bits

A0 LED (red)
A3 Btn
A10 LED_n (blue)
A11 Rel

which makes the OBK template for this device

I have tested this to work as expected. When off, the red LED is lit and when on the blue LED is lit. The 20A relay clicks on and off as expected.

Attachments:

LN882H_Flash_Dumper.py.zip (1.16 KB) You must be logged in to download this attachment.
factory firmware BSD34 WL2S LN882HKI EU Smart Plug.zip (644.67 KB) You must be logged in to download this attachment.

Cool? Ranking DIY

About Author

divadiow divadiow

Level 38

Offline

divadiow wrote 5074 posts with rating 898, helped 441 times. Live in city Bristol. Been with us since 2023 year.

ADVERTISEMENT
#2 20935396 29 Jan 2024 20:49

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #2
20935396 29 Jan 2024 20:49

That's a very good and detailed guide, not to mention that's one of the world's first LN882H flashing programming procedure tutorials ever posted. That's why I decided to feature it on our front page, as well as on repository:
https://github.com/openshwprojects/OpenBK7231...mmit/6c1dc5f7f19397d2d1fb15bc75e2d354b097d9f3

The BL0937 support requires adding an interrupt counter in drv_bl0937.c, I may try to do that remotely for you, but you would need to test. I don't have that specific plug.

Still, I've got one LN882H device anyway, and, by the way, it's thanks to your donation, @divadiow . I am currently working on video flashing guide for that as well:

PS: an interesting observation of mine:
divadiow wrote:

The dump speed is fixed and is very slow, so this took ~30-40 minutes.

I really don't know why it happens, but when I was trying to read the flash of the device you've donated, at first I've started flash read procedure on my PC without doing PC restart and windows had 24 or so hours of uptime (oops), and flash read took several hours, but then next morning, when I did a fresh reboot of Windows, the flash read took 15 or so minutes. So, I don't know exactly what affects that flash read tool, but something must be affecting that, strangely enough.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#3 20935784 30 Jan 2024 06:27

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #3
20935784 30 Jan 2024 06:27

p.kaczmarek2 wrote:
That's a very good and detailed guide, not to mention that's one of the world's first LN882H flashing programming procedure tutorials ever posted. That's why I decided to feature it on our front page, as well as on repository:
https://github.com/openshwprojects/OpenBK7231...mmit/6c1dc5f7f19397d2d1fb15bc75e2d354b097d9f3

High praise! thank you. I look forward to watching the new video when it's ready!

p.kaczmarek2 wrote:
The BL0937 support requires adding an interrupt counter in drv_bl0937.c, I may try to do that remotely for you, but you would need to test. I don't have that specific plug.

sure, will happily test anything if I can.

p.kaczmarek2 wrote:
I really don't know why it happens, but when I was trying to read the flash of the device you've donated, at first I've started flash read procedure on my PC without doing PC restart and windows had 24 or so hours of uptime (oops), and flash read took several hours, but then next morning, when I did a fresh reboot of Windows, the flash read took 15 or so minutes. So, I don't know exactly what affects that flash read tool, but something must be affecting that, strangely enough.

interesting indeed. I do have another untouched LN-02 device that needs desoldering and flashing, so will experiment with reboots and maybe a fresh install of Windows on a laptop to see if anything affects the dump speed.
#4 20937210 30 Jan 2024 22:11

miegapele miegapele

Level 16

Posts: 173

Help: 15

Rate: 29
Helpful post? (0)

Post #4
20937210 30 Jan 2024 22:11

Tried to make a driver for bl0937 here but can't figure out how to enable drivers
#5 20937214 30 Jan 2024 22:14

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #5
20937214 30 Jan 2024 22:14

This is because for this platform you need to manually add file paths to makefile list, so the compiler knows what to compile. The makefile list is in the separate repository. See:
https://github.com/openshwprojects/OpenLN882H/blob/master/project/OpenBeken/CMakeLists.txt

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#6 20938139 31 Jan 2024 16:42

miegapele miegapele

Level 16

Posts: 173

Help: 15

Rate: 29
Helpful post? (0)

Post #6
20938139 31 Jan 2024 16:42

Not sure what files are needed, made a PR https://github.com/openshwprojects/OpenLN882H/pull/5
#7 20938152 31 Jan 2024 16:56

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #7
20938152 31 Jan 2024 16:56

I think that you need to include at least one file more, namely bl_shared.c:
Code: text Expand Select all Copy to clipboard
# app/src/driver/drv_bl_shared.c

This is because the following file has all the shared routines that are used by both BL0937, BL0942 and similiar power metering chips.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#8 20938166 31 Jan 2024 17:08

miegapele miegapele

Level 16

Posts: 173

Help: 15

Rate: 29
Helpful post? (0)

Post #8
20938166 31 Jan 2024 17:08

Added that one too
#9 20946708 05 Feb 2024 19:29

max4elektroda max4elektroda

Level 24

Posts: 756

Help: 48

Rate: 187
Helpful post? (0)

Post #9
20946708 05 Feb 2024 19:29

You are great!

I got a bunch of "LSPA9" plugs with LN882H (wanted Zigbee ones, but ordered WIFI ) so I stumbled over your work on LN882H.

Works from the start, only the BL0937 not working, so I tried on my own and ended up in a plug not booting...

With some minor changes I tried the files from the pull request, and - ta da it works (not tested too much, no calibration ...)

Here the files changed as a tar file and a diff (didn't get it to diff CMakeLists.txt, so this is in tar only (sorry, I'm not so familiar with git etc to see how this could be integrated).
The main work (all the code in drv_bl0937.c) was done by @miegapele, I just changed the path to the includes and one typo).

Once again, thanks to everybody working on this project!

Max

[edit]
Sorry, I included the wrong "CMakeLists.txt" file here, please see #14 for the correct one
[/edit]

Attachments:

git_files.diff.txt (4.19 KB) You must be logged in to download this attachment.

changedfiles.tgz (8.42 KB) You must be logged in to download this attachment.
#10 20946728 05 Feb 2024 19:39

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #10
20946728 05 Feb 2024 19:39

That's a very good news! I've merged this PR, I hope it's a correct one:
https://github.com/openshwprojects/OpenLN882H/pull/5
and I will update SDK and merge the main PR as well:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1054
Is anything more needed for it to work?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

#11 20946777 05 Feb 2024 19:59

max4elektroda max4elektroda

Level 24

Posts: 756

Help: 48

Rate: 187

Post #11

20946777 05 Feb 2024 19:59

Thanks, great.

As I said, I'm not really familiar with git, so I couldn't make the changes there but added everything in the tar.

For the driver I only had to adjust the path and fix one typo to the last code in the pull


--- drv_bl0937_pull.c	2024-02-05 18:28:29.223638000 +0100
+++ drv_bl0937.c	2024-02-05 18:53:48.705013704 +0100
@@ -27,8 +27,8 @@
 #include "../../../../../../components/hal_drv/bl602_hal/hal_gpio.h"
 #include "../../../../../../components/hal_drv/bl602_hal/bl_gpio.h"
 #elif PLATFORM_LN882H
-#include "hal_common.h"
-#include "hal_gpio.h"
+#include "../../sdk/OpenLN882H/mcu/driver_ln882h/hal/hal_common.h"
+#include "../../sdk/OpenLN882H/mcu/driver_ln882h/hal/hal_gpio.h"
 #else
 
 #endif
@@ -94,7 +94,7 @@
 
 uint16_t GetGPIOForPin(int pinIndex)
 {
-   return (uint16_t)1 << (uint16_t)(pinindex % 16);
+   return (uint16_t)1 << (uint16_t)(pinIndex % 16);
 }
 
 void GPIOA_IRQHandler()

Then I had to add driver for NTP in src/obk_config.h and quite a bunch of files to CMake.txt to keep the compiler from complaining about missing symbols ...
Then only typedef of u32 in src/new_common.h and thats it.

BTW: calibrating worked, so the numbers are o.k. for me now ;-)

#12 20946821 05 Feb 2024 20:21

miegapele miegapele

Level 16

Posts: 173

Help: 15

Rate: 29
Helpful post? (0)

Post #12
20946821 05 Feb 2024 20:21

I can clean this up, but are you sure you changed CMakelists.txt? It looks the same to me.
#13 20946834 05 Feb 2024 20:30

max4elektroda max4elektroda

Level 24

Posts: 756

Help: 48

Rate: 187
Helpful post? (0)

Post #13
20946834 05 Feb 2024 20:30

Just closed my PC.
All files changed are in the tgz file in the post.
The changed CMakelists.txt should be there, too??

Sorry, dind't make it to check earlier:
Obvoiusly I didn't attach the correct CmakeLists.txt in the tar
Will correct this later, but I followd a trial and error apporach (all done with the "docker" environment):

Tried to compile,
looked for the source, containing the Symbols listed as missing
uncommented the corresponding file
and tried again ....

until build was o.k.

#14 20948381 06 Feb 2024 19:46

max4elektroda max4elektroda

Level 24

Posts: 756

Help: 48

Rate: 187

Post #14

20948381 06 Feb 2024 19:46

o.k, here is the used "CMakeLists.txt" from the ccorrect path ("sdk/OpenLN882H/project/OpenBeken/CMakeLists.txt")
Or, as a diff against the actual CMakeLists.txt:

--- sdk/OpenLN882H/project/OpenBeken/CMakeLists.txt	2024-02-06 19:35:12.296063565 +0100
+++ sdk/OpenLN882H/project/OpenBeken/CMakeLists.txt.max	2024-02-05 15:36:05.591985473 +0100
@@ -21,9 +21,9 @@
     app/src/cmnds/cmd_tcp.c
     app/src/cmnds/cmd_test.c
     app/src/cmnds/cmd_tokenizer.c
-#    app/src/devicegroups/deviceGroups_read.c
-#    app/src/devicegroups/deviceGroups_util.c
-#    app/src/devicegroups/deviceGroups_write.c
+    app/src/devicegroups/deviceGroups_read.c
+    app/src/devicegroups/deviceGroups_util.c
+    app/src/devicegroups/deviceGroups_write.c
 #    app/src/driver/drv_adcButton.c
 #    app/src/driver/drv_adcSmoother.c
 #    app/src/driver/drv_battery.c
@@ -54,7 +54,7 @@
 #    app/src/driver/drv_max72xx_single.c
 #    app/src/driver/drv_mcp9808.c
 #    app/src/driver/drv_ntp_events.c
-    app/src/driver/drv_ntp.c
+   app/src/driver/drv_ntp.c
 #    app/src/driver/drv_pt6523.c
 #    app/src/driver/drv_pwm_groups.c
 #    app/src/driver/drv_pwmToggler.c
@@ -78,9 +78,9 @@
 #    app/src/driver/drv_tm_gn_display_shared.c
 #    app/src/driver/drv_tm1637.c
 #    app/src/driver/drv_tm1638.c
-#    app/src/driver/drv_tuyaMCU.c
+    app/src/driver/drv_tuyaMCU.c
 #    app/src/driver/drv_tuyaMCUSensor.c
-#    app/src/driver/drv_uart.c
+    app/src/driver/drv_uart.c
 #    app/src/driver/drv_ucs1912.c
 #    app/src/driver/drv_wemo.c
     app/src/hal/ln882h/hal_adc_ln882h.c

Attachments:

CMakeLists.txt (5.06 KB) You must be logged in to download this attachment.

#15 20953393 09 Feb 2024 17:56

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #15
20953393 09 Feb 2024 17:56

nice work
OpenLN882H_1.17.454.bin
#16 20953481 09 Feb 2024 18:49

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #16
20953481 09 Feb 2024 18:49

Thank you, but the credit should go to @miegapele , I just helped with organizing the build. It was easier than I expected.

@divadiow have you tried HASS Discovery on LN882H?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#17 20953490 09 Feb 2024 18:53

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #17
20953490 09 Feb 2024 18:53

Well done @miegapele

@p.kaczmarek2 I have a basic HASS I've hardly configured in a Docker container on the NAS. I haven't started using HASS yet.

Do you just want to know that it gets discovered and that power, relay etc values come into HASS?
#18 20953708 09 Feb 2024 21:09

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #18
20953708 09 Feb 2024 21:09

I had report saying that executing HASS Discovery causes ERR_MEM in MQTT and I would like if it no longer happens. I've increased MQTT buffers to match the required sizes.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.

#19 20954030 10 Feb 2024 08:01

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898

Post #19

20954030 10 Feb 2024 08:01

Info:MQTT:Publishing val 258.2 to euplug/voltage/get retain=0
Info:MAIN:Time 36535, idle 0/s, free 96048, MQTT 1(2208), bWifi 1, secondsWithNoPing 36470, socks 0/0 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/voltage/get
Info:CMD:[WebApp Cmd 'logfeature 2 0' Result] OK
Info:MQTT:Publishing val 0.047 to euplug/energycounter/get retain=0
Info:MQTT:Publishing val 0.000 to euplug/energycounter_last_hour/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/energycounter/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/energycounter_last_hour/get
Info:MQTT:Publishing val 260.3 to euplug/voltage/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/voltage/get
Info:MQTT:Queued topic=homeassistant/switch/OpenBK_LN882H_WL2S_EUPlug_PM_relay_0/config, 1 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_0/config, 2 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_1/config, 3 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_2/config, 4 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_3/config, 5 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_4/config, 6 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_5/config, 7 items in queue
Info:MQTT:Queued topic=homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_rssi/config, 8 items in queue
Info:MQTT:Publishing val (325 bytes) to homeassistant/switch/OpenBK_LN882H_WL2S_EUPlug_PM_relay_0/config retain=1
Info:MQTT:Publishing val (359 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_0/config retain=1
Info:MQTT:Publishing val (359 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_1/config retain=1
Info:MQTT:Publishing val (353 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_2/config retain=1
Info:MQTT:Publishing val (376 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_3/config retain=1
Info:MQTT:Publishing val (396 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_4/config retain=1
Info:MQTT:Publishing val 0.011 to euplug/current/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/current/get
Info:MQTT:Publishing val (315 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_sensor_5/config retain=1
Info:MQTT:Publishing val (330 bytes) to homeassistant/sensor/OpenBK_LN882H_WL2S_EUPlug_PM_rssi/config retain=1
Info:MQTT:Channel has changed! Publishing 0 to channel 0 
Info:MQTT:Publishing val 0 to euplug/0/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/0/get
Info:MQTT:Publishing val 258.2 to euplug/voltage/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/voltage/get
Info:MQTT:Publishing val 0.000 to euplug/current/get retain=0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic euplug/current/get
Info:MQTT:Publishing val 260.1 to euplug/voltage/get retain=0

#20 20954116 10 Feb 2024 09:19

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #20
20954116 10 Feb 2024 09:19

So it's working now. I will mark Github issue as solved.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
ADVERTISEMENT
#21 21010987 19 Mar 2024 19:33

beloborodom beloborodom

Level 2

Posts: 3
Helpful post? (0)

Post #21
21010987 19 Mar 2024 19:33

Hello,
thank you so much for the guide,
i flashed it with the lastest firmware, but i noticed that the watchdog just dont work,
when it come to 60 seconds, the module just deactivate wifi, and do nothing
also, if the module disconnects from wifi, it will never reconnects anymore, i need to restart it manually(phisically)
the web interface button restart works!
Ota updates also works
Module Name:
LIGHTNING
LN882HKI(or 1 i cant see, or L)
748AY T16
AA8 M2223

Elvico 16A Tuya smart plug

thank you so much

EDIT:

this is how it disconnects, and never reconnect
#22 21014454 22 Mar 2024 09:07

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #22
21014454 22 Mar 2024 09:07

Hello @beloborodom , can you specify whether you're referring to the MCU watchdog or to our "ping watchdog" mechanism? Those are two separate things.

I will check that disconnect issue. @divadiow , you seem to have LN882H as far as I remember, do you also have that problem?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#23 21014546 22 Mar 2024 10:06

beloborodom beloborodom

Level 2

Posts: 3
Helpful post? (0)

Post #23
21014546 22 Mar 2024 10:06

Thank you so much for the answer, and your time.

Im refering to "ping watchdog", configurable trough the web interface

Thank you so much,
tell me if you need other info

Best Regads
#24 21015501 22 Mar 2024 22:20

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #24
21015501 22 Mar 2024 22:20

p.kaczmarek2 wrote:
I will check that disconnect issue. @divadiow , you seem to have LN882H as far as I remember, do you also have that problem?

nope. the LN882Hs I have have stayed up (with the exception of the dodgy candle lamp). I'll leave one on overnight tonight. I don't have any in actual use around the house, but I've definitely not noticed them dropping off after a set time.
#25 21015705 23 Mar 2024 08:34

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (0)

Post #25
21015705 23 Mar 2024 08:34

@divadiow and what if you have LN882H connected to router and then you will turn off router for 10 minutes and reboot the router? Will LN882H reconnect to WiFi connectly?

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#26 21016643 23 Mar 2024 21:36

max4elektroda max4elektroda

Level 24

Posts: 756

Help: 48

Rate: 187
Helpful post? (+1)

Post #26
21016643 23 Mar 2024 21:36

Hope it's o.k. if I give my results

After shutting down WiFi I could see LN882H responding in two different ways (after loosing it's connection):

Directly starting WiFi scan over and over again for quite some time ( ~2 minutes, it was to much to see the start for it was too much for the buffer ) and then switching to a scan every now and then (see log1). Interesting: at least the shown scan results were incomplete - it only showed weak signals and only one SSID per AP.

When switching WiFi back after more than 10 minutes, it took some time (showing only the weak BSSIDs) and after about 45 seconds it reconnected. (see log 2).

During another check, after turning WiFi AP off, it just showed "disconnected" and went directly into the "scanning from time to time mode", which was reached after a longer period of "heavy scanning" during the other try ... (see log 3).

In the end, my conclusion is:
Don't know why it behaves differently after loosing connection to AP, but in the end, it did a reconnect during my tests.

Attachments:

log1.txt (12.22 KB) You must be logged in to download this attachment.

log3.txt (6.95 KB) You must be logged in to download this attachment.

log2.txt (11.06 KB) You must be logged in to download this attachment.
#27 21020118 26 Mar 2024 07:39

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #27
21020118 26 Mar 2024 07:39

p.kaczmarek2 wrote:
@divadiow and what if you have LN882H connected to router and then you will turn off router for 10 minutes and reboot the router? Will LN882H reconnect to WiFi connectly?

shall I still do this?
#28 21020379 26 Mar 2024 11:21

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Posts: 14637

Help: 655

Rate: 12649
Helpful post? (+1)

Post #28
21020379 26 Mar 2024 11:21

I think you can still try, just on the latest version. We don't know if there was one issue or two.

I am creating multiplatform open source firmware (Tasmota replacement), right now supporting BK7231T, BK7231N, XR809, BL602, W800, W600, LN882H and soon supporting RTL and W701:
https://github.com/openshwprojects/OpenBK7231T
If you like my work, support me at: https://paypal.me/openshwprojects

Helpful post? Buy me a coffee.
#29 21021470 27 Mar 2024 09:31

divadiow divadiow

Level 38

Posts: 5074

Help: 441

Rate: 898
Topic author Helpful post? (0)

Post #29
21021470 27 Mar 2024 09:31

scripted disablement of wlan1 on test router for 20 mins. no other devices connected to this network but 1 LN-02 mini switch and one WL2S EU smart plug with power monitoring and my PC.

both latest OBK and online for 30+ mins before starting

on wlan1 re-enablement both LN devices are seen as connected again within a few seconds. total uptime is consistent with when they were first powered on.

is that test enough?
#30 21021494 27 Mar 2024 09:53

beloborodom beloborodom

Level 2

Posts: 3
Helpful post? (0)

Post #30
21021494 27 Mar 2024 09:53

I have a quick update: I've recently updated to version 1.17.517 three days ago. So far, everything seems to be running smoothly without any disconnects. Over the next few days, I plan to test by disconnecting the WiFi to see how it performs, also will try the ping watchdog

Thanks to everyone

today i update to the 1.17.521
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Reply Cool? Ranking DIY | New topic

Notify about new articles

📢 Listen (AI):

Report a violation of the law

Topic summary

✨ The discussion centers on the Elivco 20A BSD34 EU smart power monitoring plug based on the LN882H chip and WL2S Tuya module, featuring the BL0937 power metering IC. Initial efforts involved flashing the LN882H device using OpenBeken firmware, with community contributions providing a detailed flashing guide and driver development for BL0937 support. Challenges included manual makefile configuration and driver integration, resolved through pull requests and code adjustments. Users reported successful flashing and basic functionality, including MQTT and Home Assistant integration with HASS Discovery, though some experienced issues with the "ping watchdog" causing WiFi disconnections and reconnection behavior variability after router outages. Firmware updates and MQTT threading fixes improved stability. Additional observations identified GPIO pins controlling LEDs and buttons, with some devices showing always-on red LEDs regardless of relay state. The BSD34 plug shares hardware similarities with CBS2 modules and is sold under various brands like Ledlux and SURFOU. Testing confirmed LN882H devices can reconnect to WiFi after temporary outages, though behavior varies. The community continues refining firmware and drivers to enhance device reliability and feature support.
Generated by the language model.

Home page
/
Forum
/
Smart Home
/
Smart Home IoT
/
Smart Home Devices
/
[LN882H] [WL2S] Elivco 20A BSD34 EU Power Monitoring Plug [BL0937]

FAQ

TL;DR: For WL2S/LN882H plugs, a 2 MB flash dump can take 15–40 minutes, but “OK!” flashing takes seconds. This FAQ helps OpenBeken users open the glued BSD34 case, wire 3.3V UART flashing, apply the right GPIO template, and understand BL0937, Home Assistant, and Wi‑Fi recovery behavior. [#20935260]

Why it matters: BSD34-style smart plugs can look identical outside yet use different modules and pin maps, so one wrong template can break LEDs, metering, or relay control.

Variant discussed	Radio module	Main chip	Pin mapping status in thread	Flashing difficulty
Elivco BSD34 / WL2S version	WL2S	LN882H	Fully mapped for relay, button, LEDs, BL0937	Required LN882H UART flashing; module was desoldered in the main guide
BSD34-style Amazon version	CBS2/CB2S family	CB2S/CBS2 noted	Different pin map from WL2S version	Reported as easier to flash
WL2S to CB2S swap idea	WL2S replaced by CB2S	Mixed	Power and UART pads look similar, pin reassignment still needed	Electrically plausible, template changes expected

Key insight: Do not trust the enclosure name alone. In this thread, identical BSD34-style plugs shipped with WL2S, CB2S, and CBS2-family modules, and their working GPIO templates differed.

Quick Facts

The main BSD34 guide used a separate 3.3 V power supply, shared ground, and pogo pins; USB-TTL VCC was not used for the WL2S module. [#20935260]
The factory flash dump was capped at 0x00200000 bytes (2 MB), and the read step took about 30–40 minutes on one setup. [#20935260]
A second tester saw LN882H flash reads vary from several hours down to about 15 minutes after a fresh Windows reboot, suggesting host-side conditions affect speed. [#20935396]
Home Assistant discovery queued 8 MQTT config topics and published payloads of about 315–396 bytes without ERR_MEM on the updated build. [#20954030]

How do you open an Elivco BSD34 EU smart plug without damaging the glued case so you can access the WL2S module?

You can open it cleanly by cracking the glue line with clamps instead of prying the seam apart. Place G-clamps just below the top joining line, tighten until the glue cracks, then move slightly and repeat. The case separates quickly, and only the earth wire keeps both halves together. After that, remove the single PCB screw and loosen the earth screw slightly so the board can slide out. This method avoided the battered, chewed-up housing often seen after screwdriver-only opening. [#20935260]

What is the WL2S module, and how is it related to the Lightning Semiconductor LN882H chip used in Tuya smart plugs?

“WL2S” is a Wi‑Fi module that carries the Lightning Semiconductor LN882H chip, a Tuya-class radio/MCU used in smart plugs and mini switches. In this thread, the BSD34 plug used a WL2S module with an LN882HKI-marked chip, and OpenBeken support for LN882H had only recently become available. The same discussion also mentions other LN882H devices, including 16 A mini switches. That makes WL2S the board-level module and LN882H the actual controller you flash. [#20935260]

What is the BL0937 power-monitoring chip, and which GPIOs does OpenBeken need to read voltage, current, and power on the BSD34 plug?

“BL0937” is a power-monitoring IC that measures mains-related values by outputting pulse signals, with separate lines used for energy/current and voltage timing. For the WL2S-based BSD34 template in this thread, OpenBeken used GPIO 7 as BL0937CF1, GPIO 12 as BL0937CF, and GPIO 19 as BL0937SEL. The plug also used a BL0937 chip on the main board, so metering support depended on enabling that driver in the LN882H build. [#20935260]

How can you flash an LN882H-based WL2S module with OpenBeken using pogo pins, a USB-TTL adapter, and an external 3.3V power supply?

You flash it over UART with shared ground and the A9 boot pad held low. 1. Connect TX0→USB-TTL RX, RX0→USB-TTL TX, GND→GND, and power the module from an external 3.3 V supply only. 2. Ground A9/BOOT, then power up so LN882H enters boot mode. 3. Dump or write flash with the LN882H tools, then remove A9 ground and reboot. The reported write command targeted 0x0 and flashed a 2,000,000-byte image in a few seconds. [#20935260]

Why does the LN882H factory flash dump sometimes take 30 to 40 minutes or even several hours, and what seems to affect the read speed?

The thread shows that dump speed varies widely and seems sensitive to the host PC state. One dump of the 2 MB flash took about 30–40 minutes, while another maintainer reported a first read taking several hours, then only about 15 minutes after a fresh Windows reboot. No firmware-side root cause was confirmed, but the observed pattern points to the flash-read tool or Windows environment, not the BSD34 hardware itself. A maintainer explicitly said he did not know why it happened. [#20935396]

Which GPIO template works for the Elivco 20A BSD34 EU power monitoring plug with WL2S and BL0937 under OpenBeken?

The working WL2S/LN882H template used GPIO 0 LED, 3 Btn, 7 BL0937CF1, 10 LED_n, 11 Rel, 12 BL0937CF, and 19 BL0937SEL. The device metadata in the thread named it “Elivco 20A BSD34 EU Power Monitoring (BL0937) Plug” with board WL2S and chip LN882H. The author also confirmed the relay and LEDs behaved correctly: red when off, blue when on. [#20935260]

What do the A9/BOOT pad and boot mode do on the LN882H, and how do you use them during flashing?

The A9/BOOT pad forces the LN882H into UART boot mode when you pull it low during power-up. In normal power-up, the boot log showed “GPIOA_9 high level, will enter Normal mode!”; during flashing, grounding A9 before applying 3.3 V made the chip wait for the flash tool. After writing firmware, you remove the A9 ground and reset power so the module boots the new image and exposes the OpenBeken AP. [#20935260]

How was BL0937 support added for the LN882H build of OpenBeken, and which extra files had to be enabled in the OpenLN882H CMakeLists.txt?

BL0937 support was added by enabling the driver build and its missing dependencies in the LN882H project files. The thread says the LN882H port needed manual CMake path updates, plus drv_bl_shared.c because BL0937, BL0942, and similar chips share routines there. A working test build also enabled deviceGroups_read.c, deviceGroups_util.c, deviceGroups_write.c, drv_ntp.c, drv_tuyaMCU.c, and drv_uart.c. One maintainer later merged the PR and wrote, “It was easier than I expected.” [#20948381]

Why would Home Assistant discovery on LN882H trigger MQTT ERR_MEM errors, and what changed in later firmware to fix it?

It happened because discovery publishes many retained config payloads at once, which could overflow MQTT memory buffers on earlier LN882H builds. One maintainer said he had reports that HASS Discovery caused ERR_MEM and then increased MQTT buffers to the required sizes. A later test showed discovery queuing 8 config topics and publishing payloads around 325–396 bytes successfully, after which the issue was marked solved. [#20953708]

When an LN882H smart plug loses Wi-Fi, what is the normal reconnection behavior after the router or access point comes back online?

Normal behavior is automatic rescanning followed by reconnect when the AP returns. One tester turned Wi‑Fi off for more than 10 minutes and saw LN882H reconnect after about 45 seconds once the AP came back, though scan output looked incomplete and only showed weak BSSIDs at first. Another later test disabled WLAN for 20 minutes, and both LN devices reappeared within a few seconds after re-enable, with uptime preserved. [#21016643]

What could cause the ping watchdog on an LN882H OpenBeken plug to disable Wi-Fi instead of recovering cleanly after 60 seconds?

The thread points to an older LN882H firmware issue rather than a confirmed hardware fault. One user reported that the web-configured ping watchdog hit 60 seconds, then disabled Wi‑Fi and never reconnected until a physical reboot, although the web restart button and OTA still worked. Later builds, including 1.17.517 and 1.17.521, appeared stable, and a maintainer also integrated an LWIP MQTT threading fix during that period. [#21010987]

How can GPIO Doctor or Tuya config extraction help identify why the red LED stays on all the time on a BSD34-style smart plug?

They help by revealing whether the red LED is a relay LED, a Wi‑Fi status LED, or mapped to the wrong pin. In the later BSD34-style case, the tester found pin 23 acted as WifiLED;1, while pin 8 handled the blue LED behavior and pin 26 drove the relay. That explains why a WL2S template from the earlier plug could leave the red LED permanently on when applied to a visually identical but differently wired unit. [#21433856]

WL2S vs CB2S in BSD34-style smart plugs: what differences in pin mapping, flashing difficulty, and compatibility showed up in this thread?

The thread showed clear differences despite nearly identical housings. The original BSD34 used WL2S/LN882H and mapped relay and LEDs to GPIOs 11, 0, and 10, while a later Amazon-branded lookalike used a CBS2/CB2S-family module with relay and LED functions on pins 26, 23, 10, and 8. The later user also said flashing worked fine without desoldering the module, unlike the original WL2S guide that removed the module for easier access and to avoid BL0937 interference. [#21438406]

How feasible is it to swap a WL2S module with a CB2S module in a smart plug like the one discussed here, and what pin assignment changes would likely be needed?

It looks feasible electrically, but you should expect to remap GPIOs. A tester noted that VCC 3.3 V, GND, and even RX/TX seemed to share the same layout between the smart-plug boards, so the replacement should at least power up correctly. He also warned that the main work would likely be changing pin assignments afterward. That means the swap is not template-compatible by default, even if the footprint is close enough to solder in. [#21733480]

If two BSD34 plugs look identical externally but use different modules like WL2S or CBS2/CB2S, how should you verify the correct pinout before applying an OpenBeken template?

You should verify the module type and pin functions first, then apply or build the template. Start with GPIO Doctor or Tuya config extraction, because the thread documented externally identical BSD34-style plugs that used different modules and different LED, button, relay, and BL0937 pin maps. One maintainer explicitly advised using GPIO Doctor to find the LED pin or extracting the Tuya config before trusting the old template. That is the safest path when the enclosure and label match but the internals do not. [#21431833]

Generated by the language model.