logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

OpenLN882H upgrade from 1.17.506 to 1.17.515 makes LSPA9 Smart Plug unresponsive

silvestro_gatto 5784 66
Best answers

Why does upgrading OpenLN882H from 1.17.506 to 1.17.515 make my LSPA9 smart plug become unresponsive, and how can I fix it?

The freeze is caused by the NTP/time conversion code on LN882H, not by the plug template or the LED drivers: starting NTP on affected builds leads to bad `gmtime()` usage with a `g_ntpTime` value that is the wrong type/size for platforms where `time_t` is 64-bit, which can make the device behave erratically or hang [#21018282] [#21019583] A temporary workaround was to cast through a real `time_t` variable before calling `gmtime()`, and that immediately stopped the freeze in testing [#21018282] The proper fix was then merged by changing the NTP time handling to use `time_t` consistently, including related NTP event and JSON/httpserver paths [#21020171] After that fix, the reporter confirmed OpenLN882H_1.17.521 was stable again and settings were preserved [#21020355]
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #1 21016559
    silvestro_gatto
    Level 7  
    Device: Elivo LSPA9 Smart Plug with Energy Monitor
    Microprocessor: LN882HKI on WL2S module
    Energy Monitor chip: BL0937

    Last week I flashed OpenLN882H release 1.17.506 on the device and configured template based on PCB pin setting, getting a fully functional plug with energy monitoring.

    Today I updated the device with OpenLN882H release 1.17.515 and the device became unresponsive: connecting the device to main, it starts normally but access to web interface is slow and after 20/30 seconds the device becomes unresponsive.

    I removed the WL2S module from the plug and connected to UART2TTL to analyze serial log.

    The log shows the following recurring errors:

    [WLIB_E]HwEr:EC = 16
    [WLIB_E]HwEr:EC = 12
    [WLIB_E]HwEr:EC = 12
    [WLIB_E]HwEr:EC = 12

    Flashing back OpenLN882H release 1.17.506 made the device stable and reliable again.

    Any advice?
  • ADVERTISEMENT
  • #2 21016837
    p.kaczmarek2
    Moderator Smart Home  
    Hello, by any chance, do you have PowerSave 1 command? The only thing I changed recently was attempted PowerSave 1 fix.
    Helpful post? Buy me a coffee.
  • #3 21016933
    silvestro_gatto
    Level 7  

    Hello p.kaczmarek2, I do not have Power Save 1 command.

    This is the template I am using:

    Code: text Expand Select all Copy to clipboard
    
{
  "vendor": "Elivco",
  "bDetailed": "0",
  "name": "Elivo LSPA9 Smart Plug with Energy Monitor",
  "model": "LSPA9",
  "chip": "LN882H",
  "board": "WL2S",
  "flags": "1024",
  "keywords": [
    "",
    ""
  ],
  "pins": {
    "0": "LED_n;0",
    "3": "Btn;0",
    "7": "BL0937CF1;0",
    "10": "WifiLED_n;1",
    "11": "Rel;0",
    "12": "BL0937CF;0",
    "19": "BL0937SEL;0"
  },
  "command": "backlog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1",
  "image": "",
  "wiki": ""
}


    The only difference I noticed are the recurring lines

    [WLIB_E]HwEr:EC = 16
    [WLIB_E]HwEr:EC = 12
    [WLIB_E]HwEr:EC = 12
    [WLIB_E]HwEr:EC = 12

    in the serial log captured when the module was running OpenLN882H release 1.17.515.

    I still have the WL2S module on my bench and can try to upgrade release by release and see when the problem arise, unless you have any other suggestion to lay down this issue.
  • #4 21016961
    p.kaczmarek2
    Moderator Smart Home  
    Can you check some version in between like a 1.17.510 to determine which release breaks?

    Added after 52 [seconds]:

    @divadiow is your LN882H stable?
    Helpful post? Buy me a coffee.
  • #5 21017013
    max4elektroda
    Level 24  

    I'm not divadiow, but since I'm also following development of LN882H versions, I tried it on my plug:

    1.17.515 and 516 are running as expected, with or without PowerSave set (no long-term test, just some minutes).

    @silvestro_gatto: May I ask if you have a setup with multiple APs with the same SSID?

    For me it's not clear why, but from time to time the AP chosen by LN882H is not the one near to the device. It took me some time to figure out, why it sometimes was acting so slowly, till I found out about this.

    And, I didn't get further into this, because it only happens with the plugs, not with my module soldered out: Sometimes plug is available for a short period and then is "gone". Power cycling it will usually work. I didn't go further into this, for it's rare and I don't want to investigate the serial output on a live plug (the GND has connection to one of the plugs live wires)...
  • #6 21017079
    p.kaczmarek2
    Moderator Smart Home  
    I see you're very active on our forum @max4elektroda , I am very happy about that. Keep it on!
    Well, since you are not able to detect any problems, I am not sure what to do...
    I suspect that my powersave improve attempt may have broken stuff:
    https://github.com/openshwprojects/OpenBK7231...mmit/83d53cf82c58b61a02cdfb7e6661aa37176f7a8c
    but that's 516 not 515.
    516 has also new HASS discovery improvements, but still, we should check 515..
    And there isn't really much there. in 1.17.513 @divadiow enabled LED drivers, but again, they are not run on your LSPA9, are they?
    Then we have 1.17.512 when not much happens again, I have been updating SDK of LN882H to put files into Makefile.
    The initial LN882H powersave was added in 1.17.509, it seems, but it only gets called if you use PowerSave command.
    1.17.508 is a NULL character termination fix for TuyaMCU strings, so nothing related, again..
    And 1.17.507 is an attempt to calibrate BK7231 temperature...
    So, I can't see anything that may be breaking things, but still, can you @silvestro_gatto try some version in between to narrow down the possibilities of what may be a problem?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #7 21017173
    divadiow
    Level 38  
    Hello. I will test stuff asap. I am not home at the moment. I hope added drivers haven't caused an issue 😔

    I do recall the LN-02/RMW002 was stable all night Friday/Saturday but actually I think it was March 17th build. Sorry, that's no help.

    I will set a couple of LN882H up for testing
  • #8 21017278
    p.kaczmarek2
    Moderator Smart Home  
    @divadiow the thing is added drivers should not cause any issues, they take almost no RAM at all, so the issue is very strange
    Helpful post? Buy me a coffee.
  • #9 21017290
    divadiow
    Level 38  
    Sure, yes. I guess we just need to establish whether or not it's a fundamental issue with LN OBK or something not yet identified specific to the user reporting an issue. There are, of course, many variables.
  • #10 21017325
    silvestro_gatto
    Level 7  
    Hello p.kaczmarek2, divadiow and max4elektroda,
    thank you for your support with this issue.

    As suggested, I tried some version in between to narrow down the possibilities of what may be a problem, and this is the outcome:

    OpenLN882H_1.17.507 - Mar 15 2024 21:27:30 - fully functional - log not showing any error
    OpenLN882H_1.17.508 - Mar 16 2024 16:40:13 - fully functional - log not showing any error
    OpenLN882H_1.17.509 - Mar 17 2024 08:59:05 - fully functional - log not showing any error
    OpenLN882H_1.17.510 - Mar 18 2024 17:58:00 - fully functional - log not showing any error
    OpenLN882H_1.17.511 - Mar 18 2024 20:02:07 - fully functional - log not showing any error
    OpenLN882H_1.17.512 - Mar 18 2024 22:23:23 - fully functional - log not showing any error
    OpenLN882H_1.17.513 - Mar 19 2024 09:10:15 - unresponsive - [WLIB_E]HwEr:EC = 16 - [WLIB_E]HwEr:EC = 12

    The problem occurred after upgrading to OpenLN882H_1.17.513 release.

    The module lost all the settings from the template and after 20/30 seconds from boot became unresponsive.

    I noticed a slight increase of the .bin size from OpenLN882H_1.17.512 and the following releases:

    File list showing issue with OpenLN882H_1.17.513 version

    To make sure the problem is not related to my hardware, I also tested the OpenLN882H_1.17.512 release on another WL2S module and it showed the same issue after upgrading to OpenLN882H_1.17.513
  • #11 21017379
    p.kaczmarek2
    Moderator Smart Home  
    OpenLN882H 1.17.513 is "LN882H - enable LED, WEMO, HUE (#1131) (5e4f8a2), closes #1131"
    Information about the OpenBK7231T/OpenBeken release version 1.17.513.
    Here is the changes log:
    https://github.com/openshwprojects/OpenBK7231...mmit/5e4f8a23a274cb1bcb61a2bfb3a626769ca5e931
    I have created a version disabling it:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1140
    Can you try using this version?
    If you don't know how to get binary from PR, see this topic
    Helpful post? Buy me a coffee.
  • #12 21017465
    max4elektroda
    Level 24  

    Maybe it's totally wrong, but since it seems to be a problem not with all modules and as pointed out the size increased:
    There should be LN882H with 4 and 1 MB flash.
    Maybe this module is using the small one?
    From some fast search I didn't find some code for checking this...
  • #13 21017554
    silvestro_gatto
    Level 7  
    >>21017379

    Hello p.kaczmarek2,
    PR OpenLN882H_1140_merge_93aa21396021 release is working fine: the module is fully functional (keeping template settings) and serial log does not show any error.

    I have attached the .bin file here below, should someone want to try it.

    OpenLN882H...396021.bin (597.57 kB)You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #14 21017558
    divadiow
    Level 38  
    @silvestro_gatto what's the exact chip markings? I assume HKI, so 2mb? LN882H series comparison chart with chip nomenclature and ordering information from Lightning Semiconductor.
  • #15 21017561
    p.kaczmarek2
    Moderator Smart Home  
    @silvestro_gatto just to confirm - are you really sure that you're not starting any of mentioned drivers? No Wemo running, no SSDP, no HUE?
    Helpful post? Buy me a coffee.
  • #16 21017566
    divadiow
    Level 38  
    silvestro_gatto wrote:
    OpenLN882H_1140_merge_93aa21396021 release is working fine


    Interesting. I guess the question now is which of the drivers breaks it
  • #17 21017583
    silvestro_gatto
    Level 7  
    >>21017013

    @max4elektroda I have a setup with multiple APs with the same SSID, but I also tested the module with an AP with unique SSID (for bench testing) and in both cases the module was unresponsive after upgrading to OpenLN882H 1.17.513

    OpenLN882H_1.17.506 release did not show any issue working with multiple APs with the same SSID.
  • #18 21017584
    p.kaczmarek2
    Moderator Smart Home  
    Did anyone ever try OpenLN882H on the 1MB device?
    The interesting thing is that our flash config save, here:
    https://github.com/openshwprojects/OpenBK7231.../main/src/hal/ln882h/hal_flashConfig_ln882h.c
    It's saving CFG to:
    Code: text Expand Select all Copy to clipboard
    
#define CONFIG_OFFSET USER_SPACE_OFFSET + USER_SPACE_SIZE - 4096

    Code: C / C++
    Log in, to see the code

    This offset is way over 1MB mark... so I wonder how would that work on 1MB version... would that wrap around?
    Helpful post? Buy me a coffee.
  • #19 21017596
    silvestro_gatto
    Level 7  
    >>21017558

    @divadiow chip marking is LN882HKI, therefore flash size should be 2MB

    Close-up of an integrated circuit marked LIGHTNING LN882HKI on a printed circuit board.

    Added after 6 [minutes]:

    >>21017561

    @p.kaczmarek2 I can confirm that I am not using any of the mentioned drivers: no Wemo running, no SSDP, no HUE.

    My startup command line is as follows:

    Code: text Expand Select all Copy to clipboard
    backlog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1
  • #20 21017655
    max4elektroda
    Level 24  
    silvestro_gatto wrote:
    My startup command line is as follows:

    Code: text Expand Select all Copy to clipboardbacklog startDriver NTP; ntp_setServer 216.239.35.8; ntp_timeZoneOfs 1


    We are getting closer: This line also leads to the observed error on my plug with the installed version 516!
    Device is unresponsive some seconds after connecting WiFi. So it looks like it's connecting to the NTP server which causes the "freeze".

    Let me do some more tests ...

    Added after 13 [minutes]:

    Same behavior, when I start NTP with a command ("startDriver NTP").

    Two examples of log:

    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 133, idle 0/s, free 101048, MQTT 0(8), bWifi 1, secondsWithNoPing 1, socks 0/0 
Info:MAIN:Time 134, idle 0/s, free 101048, MQTT 0(8), bWifi 1, secondsWithNoPing 1, socks 0/0 
Info:MAIN:Time 135, idle 0/s, free 95592, MQTT 0(8), bWifi 1, secondsWithNoPing 1, socks 0/0 
----------------------------------------
WiFI_GetMacAddress
----------------------------------------
Info:NTP:NTP driver initialized with server=216.239.35.8, offset=0
Info:MAIN:Started NTP.
[WLIB_E]HwEr:EC = 16
[WLIB_E]rsp wait timeout, cfg_msg_id=(60), txmsg_id=(60)
[WLIB_E]HwEr:EC = 12
Info:MAIN:Time 25, idle 0/s, free 101048, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 26, idle 0/s, free 95592, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 27, idle 0/s, free 95592, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
[WLIB_E]rsp wait timeout, cfg_msg_id=(16), txmsg_id=(16)
Info:MAIN:Time 28, idle 0/s, free 101048, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
TEMP: adc raw:  782, temp_IC:   29 Total:137128; Free:101048;
Info:MAIN:Time 29, idle 0/s, free 101048, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
+--------------- net device info ------------+
|netif type    : STA                         |
|netif hostname: ln_sta                      |
|netif ip      = 192.168.0.81                |
|netif mask    = 255.255.255.0               |
|netif gateway = 192.168.0.1                 |
|netif mac     : [00]         |
+--------------------------------------------+
Info:MAIN:Time 30, idle 0/s, free 101048, MQTT 0(2), bWifi 1, secondsWithNoPing -1, socks 0/0 
----------------------------------------
WiFI_GetMacAddress
----------------------------------------
Info:NTP:NTP driver initialized with server=216.239.35.8, offset=0
Info:MAIN:Started NTP.
[WLIB_E]HwEr:EC = 16
[WLIB_E]rsp wait timeout, cfg_msg_id=(18), txmsg_id=(18)
[WLIB_E]HwEr:EC = 12


    If I remember it correctly, "WiFI_GetMacAddress" should also not be called here?!?

    Added after 5 [minutes]:

    Seems like "WiFI_GetMacAddress" is shown in the log, even if I start some other commands, but it will not "stop" the device


    Added after 2 [hours] 43 [minutes]:

    So, after some tests it seems like the problem only occurs with
    Code: text Expand Select all Copy to clipboard
    #define ENABLE_DRIVER_LED 1


    It was the first change from the three drivers enabled in this commit, so I built 516 with this line disabled: NTP works.

    To be sure I tested the other way round: Disabling both "ENABLE_DRIVER_WEMO" and "ENABLE_DRIVER_HUE" and enabling only "ENABLE_DRIVER_LED": NTP crashes the module.
  • #21 21017933
    silvestro_gatto
    Level 7  

    @max4elektroda I am glad you found the culprit ... please let me know if you want me to do some testing
  • #22 21018006
    divadiow
    Level 38  
    I have a few LN882H and can test too
  • #23 21018009
    p.kaczmarek2
    Moderator Smart Home  
    As far as I am aware there is no connection between ENABLE_DRIVER_LED and the NTP. Still, you can check it out yourself:
    https://github.com/search?q=repo%3Aopenshwpro...OpenBK7231T_App%20ENABLE_DRIVER_LED&type=code
    The ENABLE_DRIVER_LED define basically only enables LED driver entries in the drv_main.c array and also enables the color forwarding to "I2C" LED drivers.

    Does it mean that it's still just a flash size issue?
    Helpful post? Buy me a coffee.
  • #24 21018035
    max4elektroda
    Level 24  

    To be honest, I have no clue.
    But it should not be flash size:

    Working version with "ENABLE_DRIVER_WEMO" and "ENABLE_DRIVER_HUE" and disabling "ENABLE_DRIVER_LED" is 616.8 kB
    "Crashing" version with only "ENABLE_DRIVER_LED" (disabling "ENABLE_DRIVER_WEMO" and "ENABLE_DRIVER_HUE") is 615.5 kB
  • #25 21018057
    Raufaser
    Level 10  

    I am using this plug with LN882.
    It shows a similar behavior. It runs
    Code: text Expand Select all Copy to clipboard
    OpenLN882H_1.17.516_OTA.bin


    When I am starting up the device with an empty StartupCommand string it boots up normally and publishes values to MQTT.
    As soon as I start NTP the issues start. When NTP is started the device is sometimes still accessible via Webapp, but as soon as I access it via normal web interface it freezes and becomes unresponsive.

    Anything I can do to help fixing this issue?
  • ADVERTISEMENT
  • #26 21018147
    max4elektroda
    Level 24  
    It's getting strange:

    I tried to comment out line by line enabled with ENABLE_DRIVER_LED:

    If I comment out "DRV_IsRunning("BP5758D")" in " src/cmnds/cmd_newLEDDriver.c", it works ?!?

    Code: text Expand Select all Copy to clipboard
    
void LED_I2CDriver_WriteRGBCW(float* finalRGBCW) {
#ifdef ENABLE_DRIVER_LED
	if (CFG_HasFlag(OBK_FLAG_LED_EMULATE_COOL_WITH_RGB)) {
		if (g_lightMode == Light_Temperature) {
			// the format is RGBCW
			// Emulate C with RGB
			LED_CalculateEmulatedCool(finalRGBCW[3], finalRGBCW);
			// C is unused
			finalRGBCW[3] = 0;
			// keep W unchanged
		}
	}

	if (DRV_IsRunning("SM2135")) {
		SM2135_Write(finalRGBCW);
	}
/*
	if (DRV_IsRunning("BP5758D")) {
		BP5758D_Write(finalRGBCW);
	}
*/
	if (DRV_IsRunning("BP1658CJ")) {
		BP1658CJ_Write(finalRGBCW);
	}
	if (DRV_IsRunning("SM2235")) {
		SM2235_Write(finalRGBCW);
	}
	if (DRV_IsRunning("KP18058")) {
		KP18058_Write(finalRGBCW);
	}
#endif
}


    I'm lost ...

    Added after 12 [minutes]:

    Raufaser wrote:
    I am using this plug with LN882.
    It shows a similar behaviour. It runs
    Code: text Expand Select all Copy to clipboard
    OpenLN882H_1.17.516_OTA.bin


    When I am starting up the device with an empty StartupCommand string it boots up normally and publishes values to MQTT.
    As soon as I start NTP the issues start. When NTP is started the device is sometimes still accessible via Webapp, but as soon as I access it via normal web interface it freezes and becomes unresponsive.

    Anything I can do to help fixing this issue?


    You are right, it depends on the GUI, too:

    If I close all browser sessions to the device, and then start NTP with a "wget" (wget -q -O /dev/null "http://192.168.0.81/cmd_tool?cmd=startDriver+NTP"), it looks like this:
    Code: text Expand Select all Copy to clipboard
    
Info:MAIN:Time 10, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 11, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 12, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Error:CMD:cmd STATUS NOT found (args 8)
Info:MAIN:Time 13, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 14, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 15, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 16, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 17, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:MAIN:Time 18, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
TEMP: adc raw:  780, temp_IC:   28 Total:137280; Free:101424;
Info:MAIN:Time 19, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
+--------------- net device info ------------+
|netif type    : STA                         |
|netif hostname: ln_sta                      |
|netif ip      = 192.168.0.81                |
|netif mask    = 255.255.255.0               |
|netif gateway = 192.168.0.1                 |
|netif mac     : [00:50:C2:51:66:06]         |
+--------------------------------------------+
Info:MAIN:Time 20, idle 0/s, free 101424, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
----------------------------------------
WiFI_GetMacAddress
----------------------------------------
Info:NTP:NTP driver initialized with server=216.239.35.8, offset=0
Info:MAIN:Started NTP.
Info:MAIN:Time 21, idle 0/s, free 101128, MQTT 0(1), bWifi 1, secondsWithNoPing -1, socks 0/0 
Info:NTP:Seconds since Jan 1 1900 = 3920296516
Info:NTP:Unix time  : 1711307716
TEMP: adc raw:  787, temp_IC:   31 Total:137280; Free:101128;
TEMP: adc raw:  792, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  793, temp_IC:   34 Total:137280; Free:101128;
TEMP: adc raw:  792, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  789, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  784, temp_IC:   30 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;
TEMP: adc raw:  791, temp_IC:   33 Total:137280; Free:101128;
TEMP: adc raw:  787, temp_IC:   31 Total:137280; Free:101128;
TEMP: adc raw:  788, temp_IC:   32 Total:137280; Free:101128;


    NTP time is displayed, but then no more Info lines, but it is not totaly "dead", but still reporting TEMP ????!?
    And: I can still ping it in this state (when using webif for this command, it won't)
  • #27 21018190
    p.kaczmarek2
    Moderator Smart Home  
    That's very strange. Just to be sure - is LED_I2CDriver_WriteRGBCW actually called in your case?

    If it is, then maybe we're running out of stack size.

    I guess that function is called from apply_smart_light in cmd_newLEDDriver.c?

    Do you have smooth LED transitions on?

    Now the question is where are threads created....
    Hm, here are main threads created:
    https://github.com/openshwprojects/OpenLN882H/blob/master/project/OpenBeken/usr_app.c
    Maybe I need to try increasing USR_APP_TASK_STACK_SIZE

    But that's not the only place where threads are created.

    My HTTP server code is also using threads:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/httpserver/http_tcp_server.c
    Here is thread creation:
    Code: C / C++
    Log in, to see the code

    Hmm:
    Code: C / C++
    Log in, to see the code

    And rtos_create_thread is stubbed in main:
    Code: C / C++
    Log in, to see the code



    Well, let's try with increasing main thread stack first:
    https://github.com/openshwprojects/OpenLN882H/commit/9ec4fb9f8983f76a7e626c961add8a0797e30044
    Can you now try 1.17.517 build?
    Helpful post? Buy me a coffee.
  • #28 21018244
    Raufaser
    Level 10  

    Updated to 517. Still the same behavior. But I have a log now of the moment when the device becomes unresponsive:

    Code: text Expand Select all Copy to clipboard
    Info:MQTT:Publishing val 236.0 to smartsocket003/voltage/get retain=0
Info:MAIN:Time 173, idle 0/s, free 89368, MQTT 1(1), bWifi 1, secondsWithNoPing 108, socks 0/0 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/voltage/get
Debug:MQTT:channelSet topic 536967600 with arg 236.0
Info:MAIN:Time 174, idle 0/s, free 90912, MQTT 1(1), bWifi 1, secondsWithNoPing 109, socks 0/0 
Info:MAIN:Time 175, idle 0/s, free 90912, MQTT 1(1), bWifi 1, secondsWithNoPing 110, socks 0/0 
Info:MAIN:Time 176, idle 0/s, free 85456, MQTT 1(1), bWifi 1, secondsWithNoPing 111, socks 0/0 
Info:MAIN:Time 177, idle 0/s, free 90704, MQTT 1(1), bWifi 1, secondsWithNoPing 112, socks 0/0 
Info:NTP:Seconds since Jan 1 1900 = 3920298901
Info:NTP:Unix time  : 1711310101
Info:NTP:Local Time : 303272607/06/07 05:01:09
Info:MQTT:Publishing val 4.151 to smartsocket003/current/get retain=0
Info:MQTT:Publishing val 48777.61 to smartsocket003/power_apparent/get retain=0
Info:MQTT:Publishing val 48777.61 to smartsocket003/power_reactive/get retain=0
Info:MAIN:Time 178, idle 0/s, free 1200, MQTT 1(1), bWifi 1, secondsWithNoPing 113, 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
Debug:MQTT:channelSet topic 536967600 with arg 4.151
Debug:MQTT:channelSet topic 536967600 with arg 48777.61
Debug:MQTT:channelSet topic 536967600 with arg 48777.61
Info:MQTT:Publishing val 236.4 to smartsocket003/voltage/get retain=0
Info:MAIN:Time 179, idle 0/s, free 89368, MQTT 1(1), bWifi 1, secondsWithNoPing 114, socks 0/0 
Info:MQTT:MQTT client in mqtt_incoming_publish_cb topic smartsocket003/voltage/get
Debug:MQTT:channelSet topic 536967600 with arg 236.4
Info:MQTT:Publishing val 1.00 to smartsocket003/power_factor/get retain=0
Info:MAIN:Time 180, idle 0/s, free 87744, MQTT 1(1), bWifi 1, secondsWithNoPing 115, socks 0/0 


    After this NTP line it becomes unresponsive:
    Code: text Expand Select all Copy to clipboard
    Info:NTP:Local Time : 303272607/06/07 05:01:09


    Then it takes about a minute and then there is the next line in the log:
    Code: text Expand Select all Copy to clipboard
    Info:MQTT:Publishing val 4.151 to smartsocket003/current/get retain=0


    Interesting is the next MAIN log line:
    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 178, idle 0/s, free 1200, MQTT 1(1), bWifi 1, secondsWithNoPing 113, socks 0/0


    Only 1200 free ...

    Next MAIN log line it has more memory free:
    Code: text Expand Select all Copy to clipboard
    Info:MAIN:Time 179, idle 0/s, free 89368, MQTT 1(1), bWifi 1, secondsWithNoPing 114, socks 0/0 

  • #29 21018252
    silvestro_gatto
    Level 7  

    @p.kaczmarek2 1.17.517 build still not working for me.

    As before, module boots up and becomes unresponsive after 20/30 seconds.

    After upgrading release, serial log is showing errors again:

    Code: text Expand Select all Copy to clipboard
    
[WLIB_E]HwEr:EC = 16
[WLIB_E]rsp wait timeout, cfg_msg_id=(7), txmsg_id=(7)
[WLIB_E]HwEr:EC = 12
[WLIB_E]rsp wait timeout, cfg_msg_id=(8), txmsg_id=(8)
[WLIB_E]HwEr:EC = 12
Info:NTP:Local Time : 169476761/11/25 11:56:24
[WLIB_E]HwEr:EC = 12
[WLIB_I]W:F13=0x00004F6F, PA=0x87024C8D, RT=0x01510082

  • #30 21018282
    max4elektroda
    Level 24  
    >>21018190

    I added a LOG to LED_I2CDriver_WriteRGBCW(), and it's not even called...


    Code: text Expand Select all Copy to clipboard
    
void LED_I2CDriver_WriteRGBCW(float* finalRGBCW) {
#ifdef ENABLE_DRIVER_LED
addLogAdv(LOG_INFO, LOG_FEATURE_MAIN, "inside LED_I2CDriver_WriteRGBCW()!!\n");


    But then I remembered issue 1076.
    Seems, we are running into the same issue here, gmtime() seems to work different here, as on other devices.

    This "quick and dirty hack" will make ntp work in this case:

    Code: text Expand Select all Copy to clipboard
    -       ltm = gmtime((time_t*)&g_ntpTime);
+       time_t mytime=(time_t)g_ntpTime;
+       ltm = gmtime(&mytime);


    on every occurrence (see diff attached).

    Or maybe we can "tweak" gmtime to work like on other platforms?!?
    Attachments:
    • ntp_gmtime.diff.txt (2.65 KB) You must be logged in to download this attachment.
Reply | New topic
Report a violation of the law

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.
Generated by the language model.
Today's popular

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?

  1. Disconnect mains and attach a 3.3 V UART-to-TTL adapter to the WL2S module.
  2. Hold BOOT while powering the module, then flash a known-good .bin (e.g., 1.17.512) with obkflash.
  3. 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”].
Generated by the language model.
ADVERTISEMENT