FAQ
TL;DR: For OpenLN882H users with LN882H/WL2S plugs, the freeze after 20–30 seconds was traced to NTP, not the plug hardware. As one developer concluded, "this is the solution": a time_t/gmtime mismatch broke LN882H and BL602 builds from 1.17.513 onward until the fix landed in 1.17.521. [#21019532]
Why it matters: This thread shows how to isolate a firmware regression quickly, avoid false leads like flash size or LED support, and restore stable NTP, web UI, and saved settings on LN882H smart plugs.
| Version / build |
Observed result on affected LN882H plugs |
Notes |
| 1.17.506–1.17.512 |
Stable |
No reported serial errors |
| 1.17.513 |
First failing release |
Device loses settings and freezes |
| 1.17.517 |
Still failing |
Stack-size change did not solve it |
| PR 1141 test build |
Working workaround |
NTP no longer froze device |
| 1.17.521 |
Stable fix confirmed |
Settings restored, no serial errors |
Key insight: The visible trigger was startDriver NTP, but the root cause was a cross-platform time bug: LN882H and BL602 used 64-bit time_t, while code treated NTP time like a 32-bit integer pointer. [#21020355]
Quick Facts
- The affected plug used an LN882HKI on a WL2S module with a BL0937 energy-monitor chip, and its startup command was
backlog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1. [#21017596]
- Regression testing narrowed the break to OpenLN882H 1.17.513, built Mar 19 2024 09:10:15; versions 1.17.507 through 1.17.512 stayed fully functional on the same hardware. [#21017325]
- On one failing unit, free memory dropped from about 90,912 bytes to 1,200 bytes immediately after NTP logged local time, which matched the hang window. [#21018244]
- The thread established a platform split: BK7231 used 32-bit
time_t, while LN882H and BL602 used 64-bit time_t, explaining why BK7231 kept working with the same code path. [#21019583]
Why does upgrading an Elivo LSPA9 smart plug with LN882HKI from OpenLN882H 1.17.506 to 1.17.513 or later make the device unresponsive after 20 to 30 seconds?
Because 1.17.513 exposed an NTP time-handling bug on LN882H, not a template or hardware fault. The affected plug booted, then froze after about 20–30 seconds, often after starting NTP, while 1.17.506 through 1.17.512 stayed stable on the same WL2S module. The final diagnosis was a
time_t size mismatch in code that passed NTP time to
gmtime, which corrupted behavior on LN882H.
[#21019532]
How can I narrow down which OpenLN882H release introduced instability on a WL2S-based LN882H smart plug?
Use sequential downgrade or upgrade testing until one version fails. 1. Flash known-good firmware, such as 1.17.506 or 1.17.512. 2. Test each release in order, checking web UI, saved template, and serial log. 3. Stop at the first build that shows freezes or
[WLIB_E] errors. In this case, versions 1.17.507 to 1.17.512 worked, and 1.17.513 was the first failing release.
[#21017325]
What do the serial log errors "[WLIB_E]HwEr:EC = 16" and "[WLIB_E]HwEr:EC = 12" mean on OpenLN882H devices?
They indicate low-level Wi-Fi or system error conditions seen during the freeze, but the thread did not assign them a final standalone meaning. On affected LN882H builds, they appeared repeatedly with
rsp wait timeout messages and loss of responsiveness. After the NTP time fix was tested, those errors disappeared on the same hardware, so they were treated as symptoms of the deeper time bug rather than the root cause.
[#21018252]
How does starting the NTP driver trigger freezes on some LN882H plugs running OpenLN882H 1.17.513 to 1.17.517?
Starting NTP triggers the buggy code path that converts NTP time to local time. Users reproduced the hang with
startDriver NTP, and one log showed the device becoming unresponsive right after
Info:NTP:Local Time, with free memory collapsing to 1,200 bytes. The plug could still sometimes ping or print temperature logs, but the normal web interface stalled or froze.
[#21018244]
Which change in OpenLN882H 1.17.513 was linked to the LSPA9 smart plug freeze: LED, WEMO, HUE, or something else?
The first suspicious change was the 1.17.513 commit that enabled LED, WEMO, and HUE support, but that was not the true root cause. Tests showed that enabling LED-related code correlated with the crash, while WEMO and HUE alone did not. Later debugging proved the real issue was time handling in NTP on 64-bit
time_t platforms, so the driver change only exposed the bug.
[#21018282]
What is the WL2S module in LN882H smart plugs, and how is it used for UART debugging and reflashing?
"WL2S" is a Wi-Fi module board that carries the LN882H chip, exposes serial access, and lets developers remove it from the mains plug for safer bench testing, UART logging, and reflashing. In this thread, the module was desoldered from the plug, connected to a UART-to-TTL adapter, and used to capture boot logs and test multiple firmware versions.
[#21016559]
What is the BL0937 energy monitor chip, and how does OpenLN882H use it in smart plugs like the Elivo LSPA9?
"BL0937" is an energy-monitoring IC that measures mains parameters for smart plugs, using dedicated CF, CF1, and SEL signal pins so firmware can calculate values like voltage, current, and power. The shared LSPA9 template mapped BL0937 functions to pins 7, 12, and 19, and the plug reported energy data correctly on stable firmware.
[#21016933]
How do I test whether NTP, SSDP, WEMO, HUE, or LED drivers are causing crashes on an LN882H device?
Disable or isolate one feature at a time and test with the same startup flow. 1. Boot with an empty
StartupCommand. 2. Start one driver manually, such as
startDriver NTP. 3. Compare behavior across custom builds that enable only LED, only WEMO/HUE, or none. In this thread, NTP consistently triggered the freeze, LED-related code initially looked guilty, and later testing traced the failure to time conversion, not WEMO or HUE.
[#21017655]
Why did a gmtime and time_t mismatch break NTP on LN882H and BL602 while BK7231 kept working?
Because LN882H and BL602 used 64-bit
time_t, but the code passed a 32-bit global integer as if it were a
time_t*. That meant
gmtime read extra, undefined bytes from RAM on those platforms. BK7231 kept working because its
time_t was still 32-bit, so the bad cast did not immediately corrupt the value.
[#21019583]
What does the TimeSize command show on LN882H, BL602, and BK7231, and how can it help diagnose time_t-related bugs?
It shows the platform-dependent size of time-related types, which helps confirm whether pointer casts are unsafe. The thread used
TimeSize to verify that LN882H and BL602 had 64-bit
time_t, while BK7231 had 32-bit
time_t. That one command explained why the same NTP code failed on LN882H and BL602 but initially behaved on BK7231.
[#21019555]
OpenLN882H on 1MB vs 2MB LN882H flash: how do flash size differences affect config storage offsets and stability?
Flash size was investigated, but this thread did not prove it caused the LSPA9 freeze. One developer noted the config offset sat above the 1 MB mark, which could break saves on true 1 MB devices, while the reported chip marking LN882HKI suggested 2 MB flash. Later tests solved the freeze with a time fix, so flash size remained a separate edge case, not the confirmed cause here.
[#21017584]
How can I safely capture serial logs from a mains-powered smart plug without risking contact with live wiring?
Remove the Wi-Fi module and debug it on the bench instead of probing a live plug. One participant explicitly avoided serial investigation on a powered plug because plug ground could connect to a live wire. In this thread, the safer method was to desolder the WL2S module, connect it to a UART-to-TTL adapter, and test firmware off-board.
[#21017013]
What startup command should I use to enable NTP on OpenLN882H, and how can I verify it is not causing hangs?
Use
backlog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1 and then watch logs for stable time sync. A healthy run prints NTP initialization, Unix time, and a normal local date like
2024/03/24 22:18:36 without freezing. If the web UI hangs or
[WLIB_E] errors appear immediately after NTP starts, your build still has the bug.
[#21018404]
Why would the web interface freeze while ping and some log output still continue after starting NTP on an LN882H plug?
Because the failure did not always hard-crash the whole device. In one reproduced case, after NTP started via
wget, the plug still answered ping and kept printing
TEMP lines, but regular
Info:MAIN logging stopped and the normal web interface became unusable. That pattern pointed to severe runtime corruption or starvation in specific code paths, not a total power loss.
[#21018147]
Did anyone get OpenLN882H working reliably on a 1MB LN882H device, and what flash partition or config changes are needed?
No confirmed working 1 MB LN882H setup was documented in this thread. The discussion only raised the concern that the current config-save offset sits beyond 1 MB, which could overlap or wrap on smaller flash parts. The tested LSPA9 hardware used LN882HKI, was treated as 2 MB, and was fully stable again on 1.17.521 after the time fix.
[#21020355]
Generated by the language model.
