ESP07, NTP - Time only synchronises correctly the first time.

The situation is as follows. When the module is started, the time is downloaded from the NTP server. After midnight winter time, each day an attempt is made to synchronise the time. I seemingly get the time, but it is always incorrect. After the first change of the day, the supposed synchronisation time is a few, several seconds later than the time of the first synchronisation (performed at module start-up).
Between synchronisations I increment the time every 10 s.
Example:
I start the module, I get the time e.g. 2020-05-09 20:15:10 (this time is correct).
After midnight in winter time, the time is synchronised again and I get the time 2020-05-09 20:15:13 (this time is already incorrect).
The next time I synchronise again, it's already a cosmos.
I am running out of ideas as to what is wrong.

Code:
main.cpp


.

.

.

.

.

Code that reads wrong is probably wrong. I have had this maxim for years, and it has always worked.

One du...ny five-hundred-line main without any modularisation, dozens of global variables, not even uniformly created, seventeen headers is an indicator of pathology.
#define, const, sometimes PROGMEM (in the sense of why not more often), char * and char[] ....
A chaotic conglomeration of paste-ups from various sources

I suggest starting by checking that the getTime () function itself is correctly retrieving the current time, by printing to the console the variable NTPTime . If there are no problems here, it will be known that the error occurs further down the program, during further transformations.

JacekCz wrote:

Code that reads badly

.
I had no problem reading this code.

khoam wrote:

I suggest starting by checking that the getTime () function itself is correctly retrieving the current time, by printing to the console the variable NTPTime . If there are no problems here, it will be known that the error occurs further down the programme, during further transformations.

JacekCz wrote:

Code that reads badly

.
I had no problem reading this code.

I understand that e.g. the fate of global variables is readable to you? Is it functionally readable?
The first statement rather contradicts this?

The tfurca of the NTP "library" came up with yet another function, which is rather not used in this code.

I will omit that it also rides on global variables. Even the 40-year-old word "static" is unfamiliar.
Incidentally, with such a cool base as C++ in the ecosystem, how the community could screw up the libraries like this is beyond me.

khoam wrote:

I suggest you start by checking that the getTime() function itself is retrieving the current time correctly, by printing the NTPTime variable to the console. If there are no problems here, it will be clear that the error is occurring further down the program, during further transformations.

.
Ok, I will check this. I already checked earlier that there is an invalid time in this code fragment (variable timeUNIX ):
.
To me it looks like it's not working:
.
The code is what it is. I've glued it together from two programs, but I hate how everything is in one bag, so I've started taking it out to separate files. This is such a transitional stage.

sq9etc wrote:

I have already verified that there is an invalid time (timeUNIX variable) in this code fragment:

.
The value of this variable follows directly from the variable NTPTime .

The function UDP.read (NTPBuffer, NTP_PACKET_SIZE) should return the value NTP_PACKET_SIZE . However, in special cases it may also return the value 0 when there is not enough space in the receive buffer (the one in the WiFi stack) - this is an error and needs to be handled (the contents of the NTPBuffer remain unchanged).

These results differing by 3 seconds give food for thought, and enlightened me.

You 'order' NTP time twice, but read it once.
The second result sent back is cached in the network stack until 'next time', you read it a few hours later. Then the problem gets worse.

Added after 42 [minutes]: .

sq9etc wrote:

Code is what it is. I've glued it together from two programs, but I hate how everything is in one bag, so I've started taking it out to separate files. It's kind of a transitional stage.

I thought this was exclusive to Mr Santos .

As you rework, encapsulate functionality into classes. Some "less bad" arduino libraries sometimes have them there. NTP issue in yours, webserver in yours, etc.
Use data as private fields, you will see which data is whose (and will be inaccessible e.g. as if a popular name is repeated).

Even amateur classes (i.e. object-oriented programming orthodoxies will cling) are better than such strings.

This is a conglomeration of the two programmes:
ESP8266 DHT11/DHT22 Temperature and Humidity Web Server with Arduino IDE .
Network Time Protocol .

I test send twice:
.
because in the second article it is:

Quote:

As you can see, the ESP never received a response to the second NTP request. That's not really an issue, as long as at least some packets make it through.

.
I sent once before, but the effect was the same.

JacekCz wrote:

Two times you "order" NTP time, but you read it once.

.
There is no significance to this. UDP communication is connection-less, so the client does not need to receive every response from the server.

JacekCz wrote:

The second result sent back is cached in the network stack until "next time", you read it a few hours later. Then the problem gets worse.

.
Nothing of the sort. The UDP response from the server is buffered for as long as the size of the input buffer and the need to receive the next network packets will allow. Priority is given to TCP packets.
Stop trolling this thread mate, because you haven't the faintest idea what you're writing about.

Added after 6 [hours]: .

@sq9etc You need to listen for NTP packets coming in more often than you send requests to the NTP server. At the moment you have so that you send a request and virtually immediately expect a response from the NTP server. The yield() command won't do much good if there are no other threads being served at the time.