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 3630 66
ADVERTISEMENT
Reply | New topic
  • #31 21018300
    p.kaczmarek2
    Moderator Smart Home  
    That's interesting, can you open a pull request with your changes?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 21018347
    max4elektroda
    Level 20  
    I feared that question, I never managed to get further with git than doing a git clone and work on this copy.

    Hope I did it right: #1141
  • ADVERTISEMENT
  • #33 21018361
    p.kaczmarek2
    Moderator Smart Home  
    Pull requests are easy with Github GUI. You did well.
    I've accepted the run, binaries should be available soon...
    Helpful post? Buy me a coffee.
  • #34 21018404
    Raufaser
    Level 10  
    What I can see in the PR, the build seems to have been successfull. But were is the release?

    Added after 6 [minutes]:

    Hey, that fix seems to help :)

    Code: text Expand Select all Copy to clipboard
    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 


    It got the right time. And it didn't freeze! Good job!
  • #35 21018432
    silvestro_gatto
    Level 7  

    >>21018361

    I tested PR OpenLN882H_1141_merge_73f141c57851 build and it is working fine with me: module does not become unresponsive and all the settings are correctly restored from previous release. Thank you @max4elektroda and @p.kaczmarek2 !!!

    @p.kaczmarek2 should I click on Button with the text Solved - close topic. to close the topic?
  • #36 21018487
    max4elektroda
    Level 20  

    I think there are some other code parts with the same function, which should be addressed, too. Namely in ntp_events.c and the json code in the httpserver directory (as stated in the "issue"). I think I won't be able to look into this today cause I'm quite busy today.
    And we need to get straight, why this fails here: was the code not totally correct or is there an issue with LN882H implementation of gmtime or casting of addresses...
  • #37 21018509
    p.kaczmarek2
    Moderator Smart Home  
    It's not fully solved yet.

    What is the sizeof(g_ntpTime) and the sizeof(time_t)? Maybe those other platforms are using 64-bit time_t while g_ntpTime is 32-bit?
    Helpful post? Buy me a coffee.
  • #39 21019175
    p.kaczmarek2
    Moderator Smart Home  
    Why do you think that adding "static" changes anything?

    Adding "static" will makes this array live only in this file.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #40 21019188
    miegapele
    Level 15  

    Fixes the time bug for me on bl602, not very familiar with c, still should be static, as others, does not used anywhere else
  • ADVERTISEMENT
  • #41 21019519
    p.kaczmarek2
    Moderator Smart Home  
    This only hides the issue by changing the order stuff is allocated in RAM. I think the sizeof(time_t) is different than sizeof(int).

    Can anyone with BL602 or LN882H update to latest public release and run TimeSize command?
    See my results on Windows:
    Screenshot of the command line tool named WinTest_3145CAFF displaying the result of the TimeSize command.
    Helpful post? Buy me a coffee.
  • #43 21019532
    p.kaczmarek2
    Moderator Smart Home  
    And this is the solution, just as I said. The time_t is 64 bit on that platform, so using a global integer (32 bit) pointer as time_t pointer results in using time_t with half of bits unspecified (depending on the content of RAM).

    This is not a perfect solution:
    Code comment fragment about changing the use of the time_t structure in programming.
    I need to change the type of g_ntpTime to time_t, just I hope it won't break anything else
    Helpful post? Buy me a coffee.
  • #45 21019555
    p.kaczmarek2
    Moderator Smart Home  
    Again 64-bit? So two platforms were affected! Good job finding that, thanks to all people who reported issues. Now, well, what does the same command say on Beken?
    Helpful post? Buy me a coffee.
  • #47 21019583
    p.kaczmarek2
    Moderator Smart Home  
    So this explain why it was working on the initial version for Beken. So, to sum up, time_t is 32-bit size on Beken but it's already 64-bit on LN882H and BL602. Futhermore, on Windows, I can control the size of time_t by using _USE_32BIT_TIME_T define.

    Here is a correct fix:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1146
    Can you check this on devices with:
    - BK7231
    - LN882H
    - BL602
    while making sure that in worst case scenario you can recover via UART?
    Still, it should be good, as I already got report from @DeDaMrAz saying that it works for him...
    Helpful post? Buy me a coffee.
  • #48 21019595
    miegapele
    Level 15  

    Tested both bl602 and bk7231n, works fine with bl0937, ntp, ssdp drivers
  • #49 21019604
    DeDaMrAz
    Level 19  
    Both N and BL modules OTA flashed without problems, startDriver NTP works on both, so far no hangs no errors - version fix OTA files used.
  • #50 21019619
    p.kaczmarek2
    Moderator Smart Home  
    So I guess this testing-only fork is also no longer needed?
    Screenshot of a GitHub pull request for an open-source project showing changes in a configuration file.
    I will close the PR above and I will merge my proposed fix tomorrow if no issues arise.
    Helpful post? Buy me a coffee.
  • #51 21019625
    max4elektroda
    Level 20  

    p.kaczmarek2 wrote:

    This is not a perfect solution:

    No, it's not.

    Changing g_ntpTime to time_t is probably the best to do, for if it's 4 bytes, nothing should change, and for 8 bytes it should work now.

    On the other hand: converting a uint64_t time_t to a uint32_t shouldn't cause any problem this century, but in 2106:
    Code: text Expand Select all Copy to clipboard
    
max@max-PC:~$ date -d "@$((0xFFFFFFFF))"
So 7. Feb 07:28:15 CET 2106
max@max-PC:~$ 

  • #52 21019631
    p.kaczmarek2
    Moderator Smart Home  
    I still haven't done the full migration because there are also "Get time with offset" functions which are not yet changed to time_t, but that's lower priority, we have time until like... idk, 2038?

    @ElektrodaBot when will time_t overflow? What are the time_t types?
    Helpful post? Buy me a coffee.
  • #53 21019647
    ElektrodaBot
    AI OpenAI ChatGPT4  
    p.kaczmarek2 wrote:
    when will time_t overflow? What are the time_t types?
    Hello! It's a great question you've brought up, especially considering how crucial understanding the `time_t` data type is for many applications.

    ### What is `time_t`?

    `time_t` is a data type used in C and C++ programming languages to represent time. It generally counts the number of seconds elapsed since the Unix epoch, which began at 00:00:00 UTC on 1 January 1970.

    ### When will `time_t` overflow?

    The overflow issue of `time_t` depends on how it is implemented on a particular system, specifically whether it is a 32-bit or 64-bit type.

    - 32-bit `time_t`: On systems where `time_t` is a 32-bit signed integer, it can represent dates and times up to approximately 03:14:07 UTC on 19 January 2038. This is known as the Year 2038 problem or the Y2K38 problem. After this time, the representation will overflow and can wrap around, potentially causing software that is not prepared for this to fail or behave unpredictably.

    - 64-bit `time_t`: Many modern systems have moved to using a 64-bit `time_t`, which significantly pushes the overflow issue far into the future, roughly 292 billion years from now. Specifically, it will overflow around the year 292,277,026,596 CE, which is not a concern for current applications.

    ### Types of `time_t`

    Primarily, `time_t` is considered as an integer or a real-floating point type depending on the implementation, but its essence is that it represents time in seconds. The standard doesn't explicitly define `time_t` as 32-bit or 64-bit; it is up to the implementation. However, the common practice is to use:

    - 32-bit `time_t` on older or embedded systems.
    - 64-bit `time_t` on modern systems for a broader range and to avoid the Year 2038 problem.

    ### Follow-up Questions

    - Are you currently working on a project that involves handling time and dates, and are you concerned about the potential overflow?
    - Is there a specific system or environment you're working with (e.g., a particular operating system or hardware platform)? Knowing this could help provide more targeted advice.

    Understanding your context a bit more would enable me to give you the most relevant information or suggestions.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • #54 21019651
    max4elektroda
    Level 20  
    We also run in the same issue in "src/httpserver/json_interface.c" (issue #1076), where it's "even worse ;-)", for there we are using no unsigned, but signed int!

    Added after 21 [minutes]:

    I like it ;-)
    Screenshot of device firmware showing version LN882H_1.17.519.
    But maybe we should drop prepending "LN882H_" like in the other versions?
    I just added it, for it was there with the "LN882H_Test", too...
  • #56 21019723
    p.kaczmarek2
    Moderator Smart Home  
    Sure, here it is:
    https://github.com/openshwprojects/OpenLN882H/commit/1fade8a410cfaa6d64a0b70f2df459ba1b992a91
    Let me update the submodules of the main repo and we should get a correct version string.
    Helpful post? Buy me a coffee.
  • #57 21019882
    silvestro_gatto
    Level 7  
    >>21019583

    Tested on my LN882H bench module and OpenLN882H_1146_merge_64f6c6101544 is working fine: no more errors in serial log and module is stable and reliable with NTP driver.
  • #58 21020171
    p.kaczmarek2
    Moderator Smart Home  
    So I decided to merge the time_t fix:
    https://github.com/openshwprojects/OpenBK7231...mmit/c07f66f3818c7067e60acbf27cb1a5d86f77e692
    Can you confirm whether the issue is solved now?
    Helpful post? Buy me a coffee.
  • #59 21020355
    silvestro_gatto
    Level 7  
    I tested OpenLN882H_1.17.521 release for a few minutes now and everything seems to be fine: no more errors in serial log, module is stable and fully functional and settings are consistent with the template previously loaded.

    Once again thank you @p.kaczmarek2 and @max4elektroda for the excellent work in solving this issue.

    I can also confirm that now the correct version is showed on the footer of each web page:

    Screenshot of an interface showing software version details.
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.
Summary generated by the language model.
Popular Topics
ADVERTISEMENT