OpenLN882H upgrade from 1.17.506 to 1.17.515 makes LSPA9 Smart Plug unresponsive

silvestro_gatto 3906 66

#61 21020825 26 Mar 2024 17:56

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #61
21020825 26 Mar 2024 17:56

Nice, since you'r at it, maybe also change ntp_eventsTime type to time_t?

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
#62 21021083 26 Mar 2024 21:01

max4elektroda max4elektroda

Level 20

Helpful post? (0)

Post #62
21021083 26 Mar 2024 21:01

O.k., I added a second version of drv_ntp_events.c.
No more casting for "gmtime", but now for the calculations

Please note, since I don't use NTP, I could only test, if it compiles...
ADVERTISEMENT
#63 21021118 26 Mar 2024 21:28

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home
Helpful post? (0)

Post #63
21021118 26 Mar 2024 21:28

The W800 does not compile:
Code: text Expand Select all Copy to clipboard
./bin/build/w800/lib/libuser.a(json_interface.o): In function `$t': (.text.JSON_ProcessCommandReply+0x916): undefined reference to `NTP_IsTimeSynced' ./bin/build/w800/lib/libuser.a(json_interface.o): In function `$t': (.text.JSON_ProcessCommandReply+0x916): relocation truncated to fit: R_CKCORE_PCREL_IMM26BY2 against undefined symbol `NTP_IsTimeSynced'

I guess this may be because you need to respect OBK_DISABLE_ALL_DRIVERS define which, if enabled, means that NTP_IsTimeSynced is not present in the build.

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
#64 21021199 26 Mar 2024 22:46

max4elektroda max4elektroda

Level 20

Helpful post? (0)

Post #64
21021199 26 Mar 2024 22:46

I will fix it tomorrow, thanks for the advice!
ADVERTISEMENT
#65 21021966 27 Mar 2024 16:10

max4elektroda max4elektroda

Level 20

Helpful post? (0)

Post #65
21021966 27 Mar 2024 16:10

Uploaded fixed version, it compiles now for all platforms.
#66 21021980 27 Mar 2024 16:17

p.kaczmarek2 p.kaczmarek2

Moderator Smart Home

Helpful post? (0)

Post #66
21021980 27 Mar 2024 16:17

Nice, but I am not sure about the if conditional for StartupUTC - what happens with Tasmota control if that field is missing from JSON?
Maybe change if to work in such a way that if value negative would be to happen, then plug 0 so it prints 1970-01-01 etc etc? So just a clamp, but still add JSON key.

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.
#67 21022036 27 Mar 2024 17:10

max4elektroda max4elektroda

Level 20

Helpful post? (0)

Post #67
21022036 27 Mar 2024 17:10

Sure, fair point. Just changed this code once more.

I was already asking myself why there are so many "fake entries" in this code (always reporting fixed strings but actual values ...)
Create an account, log in and become active in a forum and ads will not appear. You will receive points by participating in discussions.
Join this discussion.

Install the application

Topic summary

The discussion revolves around the Elivo LSPA9 Smart Plug, which became unresponsive after an upgrade from OpenLN882H version 1.17.506 to 1.17.515. Users reported that the device initially functioned well with energy monitoring but encountered issues post-update, including slow web interface access and eventual unresponsiveness. Serial logs indicated recurring hardware errors. Various users suggested testing intermediate firmware versions to identify the problematic update, leading to the discovery that version 1.17.513 caused the issues. A workaround was proposed by disabling certain drivers, and a fix was implemented in subsequent versions, restoring functionality and stability to the device. The final resolution involved modifying the handling of time synchronization to prevent the device from freezing.
Summary generated by the language model.

FAQ

TL;DR: A 64-bit time_t fix restored stability, slashing crash reports by 100 % after build 1.17.521; “This only hides the issue by changing the order stuff is allocated in RAM.” [Elektroda, p.kaczmarek2, post #21019519]

Why it matters: Users can now upgrade LSPA9 plugs without losing web control or energy data.

Quick Facts

• Firmware size jumped ≈11 kB (605.9 kB → 616.8 kB) between 1.17.512 and 1.17.513 [Elektroda, silvestro_gatto, post #21017325]
• LN882HKI modules ship with 2 MB SPI flash (not 1 MB) [Elektroda, divadiow, post #21017558]
• 32-bit `time_t` overflows on 19 Jan 2038; 64-bit extends to year 292,277,026,596 CE [Wikipedia “Year 2038 problem”].
• Fix 1.17.521 reports ≈100 kB free RAM on idle [Elektroda, Raufaser, post #21018404]

What exactly made the LSPA9 plug freeze after upgrading to 1.17.515?

Build 1.17.513 enabled the generic LED driver. Its code called gmtime() with a 64-bit time_t on LN882H, but the firmware passed a 32-bit integer. The mismatched pointer corrupted memory, so NTP startup exhausted RAM and the web server stalled [Elektroda, max4elektroda, post #21018282]

Which firmware versions are confirmed stable on LN882H smart plugs?

Users reported full stability on releases 1.17.507 – 1.17.512 and again from 1.17.521 onward. Builds 1.17.513–1.17.520 are risky unless compiled without ENABLE_DRIVER_LED [Elektroda, silvestro_gatto, #21017325; #21020355].

How was the bug fixed in 1.17.521?

Developers changed the global variable g_ntpTime to the platform-native time_t type and updated every cast. The patch removed all unsafe pointer conversions, so NTP no longer corrupts RAM [Elektroda, p.kaczmarek2, post #21019583]

Does the PowerSave command trigger the crash?

No. Tests showed crashes even with PowerSave 0. The root cause was the time-handling mismatch, independent of sleep settings [Elektroda, p.kaczmarek2, #21016837; silvestro_gatto, #21016933].

Can a WL2S module with only 1 MB flash run recent OpenLN882H builds?

Not reliably. Configuration data are written above the 1 MB boundary (offset 0x1E4000). On a 1 MB chip this wraps and risks overwriting code, so stick to modules with 2 MB or larger [Elektroda, p.kaczmarek2, post #21017584]

How do I check my module’s `time_t` size to verify the fix?

Run the console command TimeSize. LN882H and BL602 report 8 bytes, BK7231 shows 4 bytes [Elektroda, divadiow, #21019543; #21019571].

What is the quick roll-back procedure if an OTA upgrade bricks the plug?

Disconnect mains and attach a 3.3 V UART-to-TTL adapter to the WL2S module.
Hold BOOT while powering the module, then flash a known-good .bin (e.g., 1.17.512) with obkflash.
Re-apply template and reboot. [Elektroda, silvestro_gatto, post #21016559]

Does enabling Wemo or Hue emulation re-introduce the issue?

No. Only the LED driver dereferenced the wrong pointer. Wemo, Hue, and SSDP compile cleanly after the time_t patch [Elektroda, max4elektroda, post #21017655]

What edge case should developers still watch?

The HTTP JSON interface still contained signed 32-bit casts; if left unpatched it could display dates like “303272607/06/07” and mislead automations [Elektroda, Raufaser, post #21018244]

Is the 2038 problem now solved for OpenLN882H?

Yes for 64-bit platforms. Switching to 64-bit time_t means timestamps will remain valid for ~292 billion years. BK7231 (32-bit) will still overflow on 19 Jan 2038 unless recompiled with 64-bit time [Wikipedia “Year 2038 problem”].