As the title says... Chat on...

User avatar
By gws
#88145 I do not manually disconnect/reconnect to wifi. I initialize it at startup and assume that the network is always available. Thus, if there are any disruptions to the interface, I expect built-in services to be able to handle this gracefully - whatever that means. Returning error codes to callbacks, pausing timeouts while the interface is coming up, etc. Doing things like setting the rtc clock incorrectly by an hour or more is not acceptable or (afaik) documented behavior. :) (I could detect a large offset in the callback function and 'undo' it, but that's Such A Hack.)

In the 2nd day that three nodes have been running with power saving disabled, SNTP has continued to work as expected! I have seen some more of the type 4 sntp errors which don't really make sense (the network is stable and always available, and the NTP server is in the same subnet with no logged errors), but error codes to callbacks are fine with me because I can always re-trigger. If the nodes start to see the strange large offset problems again, I'll update this thread, but I am pretty sure they usually showed up within the first 24h. I'll add callbacks to the wifi interface soon to see if it's stable (in hopes that this explains the type 4 sntp errors), but that is not at all worrisome to me - as I said, errors are fine and can be handled. Unpredictably changing rtc is not!

marcelstoer wrote:
gws wrote:I had assumed that power saving was okay to leave on, but if the sntp.sync code does not leave time to spin up the radio, that's problematic


Not sure I fully understand why can't you trigger the sync manually every time you (re-)connect the WiFi?