That's interesting, can you open a pull request with your changes?
Helpful post? Buy me a coffee.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
Info:NTP:NTP driver initialized with server=217.147.223.78, offset=0
Info:MAIN:Started NTP.
Info:CMD:[WebApp Cmd 'startDriver NTP' Result] OK
Info:MAIN:Time 55, idle 0/s, free 99832, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0
Info:NTP:Seconds since Jan 1 1900 = 3920307516
Info:NTP:Unix time : 1711318716
Info:NTP:Local Time : 2024/03/24 22:18:36
Info:MQTT:Publishing val 0.000 to smartsocket003/current/get retain=0
Info:MQTT:Publishing val 0.00 to smartsocket003/power_apparent/get retain=0
Info:MQTT:Publishing val 0.00 to smartsocket003/power_reactive/get retain=0
Info:MQTT:Publishing val 1.00 to smartsocket003/power_factor/get retain=0
Info:MAIN:Time 56, idle 0/s, free 97096, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/current/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/power_apparent/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/power_reactive/get
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/power_factor/get
Info:MAIN:Time 57, idle 0/s, free 100064, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0
Info:MAIN:Time 58, idle 0/s, free 94728, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0
Info:MAIN:Time 59, idle 0/s, free 94728, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0
Info:MAIN:Time 60, idle 0/s, free 100184, MQTT 1(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
to close the topic?
p.kaczmarek2 wrote:
This is not a perfect solution:
max@max-PC:~$ date -d "@$((0xFFFFFFFF))"
So 7. Feb 07:28:15 CET 2106
max@max-PC:~$
p.kaczmarek2 wrote:Hello! It's a great question you've brought up, especially considering how crucial understanding the `time_t` data type is for many applications.when will time_t overflow? What are the time_t types?
", for there we are using no unsigned, but signed int!
p.kaczmarek2 wrote:So I decided to merge the time_t fix:
https://github.com/openshwprojects/OpenBK7231...mmit/c07f66f3818c7067e60acbf27cb1a5d86f77e692
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/gmtimemismatch 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-bittime_t, while code treated NTP time like a 32-bit integer pointer. [#21020355]
backlog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1. [#21017596]time_t, while LN882H and BL602 used 64-bit time_t, explaining why BK7231 kept working with the same code path. [#21019583]time_t size mismatch in code that passed NTP time to gmtime, which corrupted behavior on LN882H. [#21019532][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]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]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]time_t platforms, so the driver change only exposed the bug. [#21018282]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]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]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]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]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]