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 6087 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  
    Posts: 30
    Rate: 4
    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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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  
    Posts: 30
    Rate: 4

    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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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.
  • ADVERTISEMENT
  • #5 21017013
    max4elektroda
    Level 24  
    Posts: 754
    Help: 48
    Rate: 187

    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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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.
  • #7 21017173
    divadiow
    Level 38  
    Posts: 5020
    Help: 438
    Rate: 891
    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
  • ADVERTISEMENT
  • #8 21017278
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12596
    @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  
    Posts: 5020
    Help: 438
    Rate: 891
    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  
    Posts: 30
    Rate: 4
    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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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  
    Posts: 754
    Help: 48
    Rate: 187

    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  
    Posts: 30
    Rate: 4
    >>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  
    Posts: 5020
    Help: 438
    Rate: 891
    @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  
    Posts: 14573
    Help: 654
    Rate: 12596
    @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  
    Posts: 5020
    Help: 438
    Rate: 891
    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  
    Posts: 30
    Rate: 4
    >>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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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  
    Posts: 30
    Rate: 4
    >>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  
    Posts: 754
    Help: 48
    Rate: 187
    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  
    Posts: 30
    Rate: 4

    @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  
    Posts: 5020
    Help: 438
    Rate: 891
    I have a few LN882H and can test too
  • #23 21018009
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14573
    Help: 654
    Rate: 12596
    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  
    Posts: 754
    Help: 48
    Rate: 187

    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  
    Posts: 47
    Help: 3
    Rate: 15

    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?
  • #26 21018147
    max4elektroda
    Level 24  
    Posts: 754
    Help: 48
    Rate: 187
    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  
    Posts: 14573
    Help: 654
    Rate: 12596
    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  
    Posts: 47
    Help: 3
    Rate: 15

    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  
    Posts: 30
    Rate: 4

    @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  
    Posts: 754
    Help: 48
    Rate: 187
    >>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: 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.
ADVERTISEMENT