Difficulty starting up due to HTTPRequest::begin loop about esp8266-iot-framework HOT 6 CLOSED

The reasoning behind the fetch.begin() function is to read the time from a server, since this is required to validate HTTPS requests.

This blocking loop is waiting until the time is obtained. As long as the ESP is running a captive portal and server connection can not be made, this will prevent the application from running. And this should indeed not be the case.

Doing some further testing I found to my surprise that even when I am not explicitly requesting the time from the server, the ESP8266 will still fetch the time when connected to WiFi. This is probably part of the ESP SDK which is used at the lowest level. Even though I did not find explicit documentation on this, I found this topic where the same behavior is observed and attributed to the SDK.

Because of this I have completely removed the fetch.begin() function, and with that the issue you encountered in commit a9b93f9.

from esp8266-iot-framework.

Good to know, thanks. It's pretty surprising that the SDK will make network activity without explicitly opting in, though.

from esp8266-iot-framework.

Agreed, that is also why I am still looking for a better source/confirmation on this.

from esp8266-iot-framework.

I just pulled in that commit, and now https requests don't work. I think that the NTP sync may actually be required (I wonder if this is something that can differ between hardware). If I check gmtime_r without configTime first, I get Thu Jan 1 00:00:07 1970. It seems like the safest option might be to restore configTime in some form to guarantee the device time is up to date.

from esp8266-iot-framework.

Yes, I figured the same, which is why I re-opened the ticket. I have reverted to a basic non-blocking NTP request in commit e9cafb4.

I was a bit too quick committing (and should start using branches).

I found that if I connect to my home WiFi it pulls the time automatically, but not when I connect to a hotspot on my phone. Currently investigating if it could fetch the time from the access point itself somehow for some access points and not for others...

from esp8266-iot-framework.

Alright sweet. I think that your latest update here should work okay as long as an https request isn't attempted before the clock sync is completed, and as long as it's able to complete after connecting to wifi but before the first https request. I have an idea about how this could be done.

One more question on configTime itself, should the first parameter be 0 for UTC?

from esp8266-iot-framework.