[configTime()]: Change of Server in not working!

[hasenradball]

Hi,

I tried many examples the last month about the getting the time with the ESP8266.
I tried how fast are the timeservers switches to the next given one when the first is not accessible.

configTime(0,0, server1, server2, server3);

configTime() does not work correctely from my point of view, because if I do set the server1 to a value with is not available, I expected that the code would switch to the second and then to the third server.
But This does not happen!
Or does anyone know it better?

#######

### --- ESP-Status ---###
reset reason: External System
free heap: 49008
chip ID: 10947453
coreVersion: 2_4_2
SDK-Version: 2.2.1(cfd48f3)
CPU Frequency: 80
sketch Size: 271360
sketch Space: 753664
sketch MD5:
Flash ChipID: 1335429
Flash ChipSize: 1048576
Flash ChipRealSize: 1048576
Flash Chip Speed: 40000000
cycle count: 2582941658
WIFI Diag: Mode: STA
PHY mode: N
Channel: 1
AP id: 0
Status: 0
Auto connect: 0
SSID (13):
Passphrase (25):
BSSID set: 0
### --- ESP-Status End---###

[devyte]

@d-a-v I explained over gitter that our configTime is a paper-thin wrapper around the sdk api for sntp. If something doesn't work, it's likely in the sdk and not in our core. Could you please confirm?

[hasenradball]

Hi, what I have checked is that it is only possible to use one server. If you set the first server as non accessible (by a wrong ip or else) it will not work.
You have to ensure thar the server1 entry works.

[devyte]

After discussing with @d-a-v , and some investigation, it seems that the sntp api provided by Espressif, which is documented in their 2C NONOS API reference pdf, is not really theirs, but is rather directly a part of lwip that is exposed through the sdk headers.
Given that we don't use the sdk's lwip, but rather have our own integration with our own lwip2, the issue could be in our own glue code, or even in lwip itself. Either way, it's on us to figure it out.

[hasenradball]

If I can support in a way let me know.

[hasenradball]

Hi, I have build a solution for me which could be a possible bugfix. Are you interested in ? Mit freundlichen Grüßen Frank Häfele

…

Am 20.11.2018 um 02:27 schrieb Develo ***@***.***>: After discussing with @d-a-v , and some investigation, it seems that the sntp api provided by Espressif, which is documented in their 2C NONOS API reference pdf, is not really theirs, but is rather directly a part of lwip that is exposed through the sdk headers. Given that we don't use the sdk's lwip, but rather have our own integration with our own lwip2, the issue could be in our own glue code, or even in lwip itself. Either way, it's on us to figure it out. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[devyte]

@hasenradball Contributions are always welcome. Please explain and/or make a PR with your proposal.

[hasenradball]

Hi, a direct pr I dont have because I actually don‘t know the root cause file. But a proposal how the solution could be ... Mit freundlichen Grüßen Frank Häfele

…

Am 28.11.2018 um 21:05 schrieb Develo ***@***.***>: @hasenradball Contributions are always welcome. Please explain and/or make a PR with your proposal. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hasenradball]

Let us have a look onto my a part of my solution:
The constructor of the class MESZ (mean european summer time) looks like that.
The three timeservers are copied into an array....

MESZ::MESZ(const char *TimeServer1, const char *TimeServer2, const char *TimeServer3) {
  NTPServer[0] = TimeServer1;
  NTPServer[1] = TimeServer2;
  NTPServer[2] = TimeServer3;
  ti = 0;
  clear_tm();
  // init is ok
  initOK = false;
  // Init();
}

Then the init of the clock is called:

bool MESZ::Init(void) {
  // configTime(0,0, server1, server2, server3);
  Serial.printf("Timeserver1: %s\n", NTPServer[0]);
  Serial.printf("Timeserver2: %s\n", NTPServer[1]);
  Serial.printf("Timeserver3: %s\n", NTPServer[2]);
  for(byte i = 0; (i < 3) && (time(NULL) <= 1.5E9); i++) {
    int MaxSec = 60;
    configTime(0, 0, NTPServer[i]);
    Serial.print("\nWaiting for time of NTPServer ");
    Serial.println(NTPServer[i]);
    while ((time(NULL) <= 1.5E9) && MaxSec) {
        Serial.print(".");
        delay(1000);
        MaxSec--;
    }
  }
  ti = time(NULL);
  if (ti > 1.5E9) {
    Serial.println("\n### --- INFO: time synchronisation sucessfully finished ---###");
    initOK = true;
    UpdateTime();
  }
  else {
    Serial.println("\n### --- ERROR: time synchronisation failed ---###");
    ti = 0;
    clear_tm();
    initOK = false;
  }
  delay(100);
  return initOK;
}

Here you will find a log which shows, if the first server is not available the second is called

If we know the file in which the of the root cause is located that the configTime does not wopple through thr 3 servers, I could prepare an PR.

[devyte]

@hasenradball Thank you!
This implements logic over the current api to avoid the issue, and is therefore a workaround, not a solution. It certainly could help anyone who encounters the issue. Also, it could be implemented if it is found that we can't fix the issue on our side of the code for whatever reason.
Before that is pursued, the underlying issue needs to be investigated. The relevant code is either the lwip glue or the lwip sntp code. If you want to pursue this, to see the lwip glue and lwip sources you need to start by uninstalling core 2.4.2 release (from the IDE) and installing latest git core (instructions are in readthedocs).

[d-a-v]

I went into lwIP-v2 sources, and sadly, the fact is: currently, only one server is supported, that, per configuration file.
With lwIP-1.4 it is 3, but this is hardcoded in sources (so hidden at time when lwIP-v2 came), not in its configuration file, so the default is only one, and this is probably the reason of the workaround above.

@hasenradball thanks for pointing us into that issue!
You can check whether normal use of configTime() is working when selecting lwIP-1.4 in menus, until configuration is fixed with lwIP-v2.