NTP-based WIFI time for v1 clocks

More
2 months 2 weeks ago #10525 by jjansen

Ian wrote: 2) There's a problem with the flash memory interface for some flash chips, notably those from Puya: you need to make a change to the source of the ESP code, as detailed in lines 19-32

Thanks, this fixed the rebooting of the ESP

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #10526 by Froula
One more observation...

I did notice that the WifiTimeProviderESP8266.ino currently in the official v2 repository does not work quite right with the current revision 56 v1 clock firmware.

The NTP settings are accepted, stored in the SPIFFS filesystem and successfully retrieved, at least according to the debug monitor.

However, although the parameters are retrieved from SPIFFS exactly as originally written, the clock does not use the correct timezone although it appears to be using the NTP time source. Re-saving the parameters from the web monitor, the correct timezone immediately takes effect. However, a reboot of the WiFi module results in the same error. The correct UTC time is shown but not the correct time zone correction.

Also, the WLAN tab does not work, as mentioned previously.

I did try to use the older Beta version contributor Mike made available in another thread:

WifiTime-v355-mjs.beta

This version supports the same protocol Rev (54) used by v1 clock firmware version 56. It works perfectly with the v1 revision 56 clock code. The NTP time zone settings are successfully saved and restored. Also, the WIFI tab is fully functionals.

It appears there are some incompatibilities in the current v2 WifiTimeProviderESP8266.ino that cause it not to work correctly with v1 firmware.

Best,

Don

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #10527 by jjansen

Froula wrote:
However, although the parameters are retrieved from SPIFFS exactly as originally written, the clock does not use the correct timezone although it appears to be using the NTP time source. Re-saving the parameters from the web monitor, the correct timezone immediately takes effect. However, a reboot of the WiFi module results in the same error. The correct UTC time is shown but not the correct time zone correction.

I had the same problem. This parameter is not retrieved during boot.
I fixed it by adding
myTz.setPosix(ntpTZ);

after
if(getConfigfromSpiffs()) {
    debugMsg("Recovered Config from SPIFFS");
  } else {
    debugMsg("Setting default configs");
    resetConfigs();
  }
(about line 250)

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #10528 by Phil_Mod3
Hi,

to my understanding, the problem is in lines 224-230 of the code:
if(getConfigfromSpiffs()) {
    debugMsg("Recovered Config from SPIFFS");
  } else {
    debugMsg("Setting default tzs");
    timeServerURL = DEFAULT_TIME_SERVER_URL_1;
    saveConfigToSpiffs();
  }
This part effectively causes that lines 245-248
else {
    debugMsg("Setting default configs");
    resetConfigs();
  }
will never be called.
Effectively, if the clock could not recover the config from SPIFFS, the first saveConfigToSpiffs() in line 229 removes the Timezone entered previously or given in the code, since ntpTz is not assigned any value at that point yet. If you remove tlines 224-230, it should behave as intended.

However, I have no idea why it does not recover the SPIFFS anyways.

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #10529 by Froula
Hmmm..

I seems odd that the current code attempts to read the SPIFFS parameters twice, once at line 224 and then again immediately after at line 243, with different error handling for each. I can see in the debug log the data is being retrieved twice. I think this is a bug and probable oversight.

I agree that if the SPIFFS read failed on the first access, the Timezone will be erased...IF the read fails.

However, in my case, the debug messages indicate a successful read and still the Timezone does not get properly set.

I think jjansen's fix should properly go in the getConfigfromSpiffs() function after line 2105 where the Posix-formatted Timezone is retrieved from the JSON-formatted parameters in SPIFFS. The Timezone is retrieved and parsed here, but the ezTime library is not notified of the retrieved Timezone. Adding:

myTz.setPosix(ntpTZ);

...would fix that.

In the properly-functioning Beta code from Mike, I don't see that SPIFFS or JSON is used at all. Parameters are stored individually in EEPROM.

Don

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #10530 by Froula
I tested this by commenting-out the following lines near 225:
/*
  if(getConfigfromSpiffs()) {
    debugMsg("Recovered Config from SPIFFS");
  } else {
    debugMsg("Setting default tzs");
    timeServerURL = DEFAULT_TIME_SERVER_URL_1;
    saveConfigToSpiffs();
  }

  */

and adding "myTz.setPosix(ntpTZ);" to the getConfigfromSpiffs() function.
ntpTZ = json["ntp_tz"].as<String>();
          debugMsg("Loaded NTP timezone: " + ntpTZ);
          myTz.setPosix(ntpTZ);

Parameters are now read just once and the timezone is read and applied correctly after a reboot.

I noticed that "myTz.setPosix(ntpTZ);" is called after a manual Parameters update from the web page, which explains why the Timezone is applied correctly after refreshing the parameters there.

Thanks for the pointers, Gentlemen!

The WLAN tab still returns an error for v1, but that is a different issue.

Regards,

Don

Please Log in or Create an account to join the conversation.

Moderators: AccutronTy_EeberfestIan
Time to create page: 0.201 seconds

Search

Tube Suppliers

Go to top
JSN Boot template designed by JoomlaShine.com