Incorrect update time, time not set from network

[lyssy2000]

When weather station updates information, it sometimes processes the data before local time becomes set from network by NTP. In effect, DST correction is calculated wrong and all times shown on display are also wrong. It is partially related to issue #15.

Current code snippet "waiting until time is set":

unsigned timeout = 3000;
  unsigned start = millis();
  while (millis() - start < timeout) {
    time_t now = time(nullptr);
    if (now) {
      break;
    }
    Serial.println(".");
    delay(100);
}

The problem is that time() returns non-zero value immediately, but returned value is not necessarily correct timestamp - time() can return value 28800 meaning "time not set"! So above code should wait for "reasonable" value, like 1514764800 (2018-01-01 00:00:00). Furthermore, setting time from network can take longer than 3 seconds (I'm experiencing consistent 6-7 seconds delays), but this is secondary issue.

Regards, Marcin D.

[Marcel Stör]

The problem is that time() returns non-zero value immediately, but returned value is not necessarily correct timestamp

https://github.com/ThingPulse/espaper-weatherstation/blob/master/espaper-weatherstation.ino#L223 is not ideal, true. I know that we already corrected other sketches exactly the way you proposed.

setting time from network can take longer than 3 seconds (I'm experiencing consistent 6-7 seconds delays)

Oh, that's real bad if you power the device from battery. Have you tried configuring NTP servers closer to your location? Maybe pick one from https://www.ntppool.org/en/ for https://github.com/ThingPulse/espaper-weatherstation/blob/master/settings.h#L74.

[lyssy2000]

In fact I use local time server (tempus1.gum.gov.pl - I'm from Poland, Warsaw to be precise, so this server is "right next to me"). Anyway, it seems that nearly half of time updates requires several (5...7) seconds to complete, but others complete immediately with correct time - so it seems that if first NTP answer is lost, there is kind of timeout within time library.

I'm aware that additional several seconds under "full power" waiting for NTP retry drains battery. If only internal RTC could retain time between resets... Unfortunately, RTC timer is reset after EXT_RST - but RTC memory is not, so maybe you can think of some "RTC time estimation" like saving last time (just before deep-sleep) in non-volatile RTC memory and then calculate "estimated" time from saved + update interval? That way, you can use estimated time if NTP does not respond immediately - I think it is not critical to have EXACT time of update, but having ROUGH time to indicate that update happened is vital.

Regards, MD

[Marcel Stör]

maybe you can think of some "RTC time estimation" like saving last time (just before deep-sleep) in non-volatile RTC memory and then calculate "estimated" time from saved + update interval?

Dani and I were discussing exactly that just last week as a means to offer really long deep sleep periods (e.g. nights, weekends): #16

[TD-er]

Isn't there some time code in the returned data with the weather info?

[Marcel Stör]

@TD-er yes, the HTTP Date response header 😜

The date and time that the message was sent (in "HTTP-date" format as defined by RFC 7231)

[Marcel Stör]

Fixed in #23