SNTP sometimes setting wildly incorrect time - mDash 1.2.15 on ESP32

Here’s a log excerpt from the serial port. The first field is the timestamp returned by the system time() function, the other fields indicate a sensor label and value(s).

1657548001,AM-4,0.012
1657548001,WL-1,0.649098,0
279b0 2 mDash.c:10988:sntpcb            SNTP: setting time to 3985593123.385
-449836783,WL-1,0.649007,0
-449836782,AM-1,0.014

The device boots, connects to mDash, and sets its initial clock correctly. Apparently at random, after several minutes of normal operation, time is set to a nonsensical value, as reflected in the log message and subsequent timestamps returned by time().

In case it’s of any use, the initial clock-setting log messages are:

502 2 mDash.c:10988:sntpcb              SNTP: setting time to 3992585258.385
10bd 2 mDash.c:10920:dev_cb             connected to wss://mdash.net/api/v2/rpc
10c0 2 mDash.c:10347:info_cb            Setting up system time to UTC  Mon Jul 11 15:56:37 2022

but these are also weird because the timestamp reported in the first line is (as seconds relative to Jan 1, 1900) 2026-04-19 13:12:03 UTC, but the correct date/time appears in the third line.

1 Like

There doesn’t seem to be a relevant issue filed with the esp-idf repo on github so this would appear to be an mDash problem.

Debugging shows the problem is that mDash’s sntpcb() is misinterpreting the return value from mg_sntp_parse().
Please see these github tickets, one of which has a pull request that fixes a related SNTP problem:

@jbrzusto

Thanks for your detective work. This sounds suspiciously like the problem I reported last year in this thread and filed in issue #14.

Eager to see some movement on this one

@Autodog
Thanks! I had read your detailed reports but am not familiar enough with the platform to know whether they were describing the same problem. As a new mDash user, my first support issue was that the library would not link against the current Arduino + ESP32-IDF releases, and Cesanta were very prompt with an update to 1.2.15. Sergey is obviously a very busy person, but I hope he can find time to close this/these tickets soon, as they would seem to have a high reward to effort ratio.