Open Ing-Med opened 4 years ago
I guess my thinking was that most people will run something that simply makes no sense until there is a correct time. Blocking things until there is makes sure no log entries from 1970 are created, it keeps wrong things from being displayed, it keeps https certificates from showing up as invalid, etc etc. I guess I can put in an option to set the NTP_RETRY
value. What do you set it to, just out of curiosity...
Yeah like I said, my problem probably does not fit the agenda of your library and hence is more or less a luxurious one.
I actually reduced it to 1 second and it works without any problem. The fact that the query sometimes does not work on the first try bothers me a bit, but I guess I have to live with that. I am using the ntp server from my router in order to save time, which would otherwise be spent on the DNS request. Although the DNS request is usually cached, I currently have a problem with minor DNS outages while using my own DNS resolving service via pihole. I wanted to mitigate that by using the ntp server of the router.
As to why the router sometimes fails to get the ntp request done, I have no idea. But like I said, a literal second after the first request, the second request gets the job done.
Thanks!
After some debugging, i found out that my NTP Server sometimes fails to respond and hence due to my program design, ezTime blocks my EPS8266 for 20 seconds according to NTP_RETRY.
Heres my outline: i am trying to run a small battery and time efficient program on my EPS8266 but i need a time to work with and i found myself to be too lazy to use smaller libraries or use RTCs :) So this problem is more of a luxurious one. After i had the program running for a few hours i encountered that the runtimes are about 20sec higher than usual. It took a while to figure out, but it's due to the fact that ezTime will retry getting to the server 20 sec later. However, since i do not really use to update time in the future (as the program only runs 4 seconds) i only ever want to initialize and get the time once and do not rely on maintaining the library via events() (it simply would not be called upon. The only wait loop in existance is waiting for Wifi to be live)
For my specific use case, changing the NTP_RETRY time gets rid of my problem, as the ESP won't be blocked* too long by the library and just tries again in a bit. Unfortunately, i found nowhere to change the static value. For my usecase, it would be nice if i were able to, but i'll admit, thats probably not the main audience for this library.
*I initialize my time with waitforsync() which apparently by design blocks the program. If the NTP server fails to send the time, an event will be set for 20 seconds in the future and then it will be stuck in this loop https://github.com/ropg/ezTime/blob/master/src/ezTime.cpp#L531 for 20 seconds until the next NTP call.
Rather than having periodically checking events() and then trying again when the time is right, it stays in waitforsync() for these 20 seconds. I am not sure if that is by your design. (since you implemented a Timeout. The if function actually correctly does an "ERROR: Timeout" but continues with the loop.
Using updateNTP() instead of waitforsync() would work i suppose, but it doesn't reliably get the time, if there was a connection error to the NTP server. But this is due to my constricting program design.
Best,
Heres some Code:
Output:
another test within the library where i printed the variables in the loop: