ESP watchdog resets in http client

[X3Cutor]

Hi

I really like the idea of not having hard-coded SSL fingerprints in my little ESP8266 application that aims to control the house heating depending on electricity prices. To do this, the EPS needs to connect to two separate HTTPS APIs, one for the utility company and one for my solar panel output.

I have had severe issues with memory-related crashes during callouts. I now have ~36kb heap space left before doing a callout and 8-9kb left after (but before cleanup). Combining this with the dashboard very frequently generates crashes (when a client is connected).

These last 12h or so I have also noticed a frequent occurrence of watchdog-related crashes (like once every hour or so). These happen within the library code but I cannot pinpoint where. Example of something that crashes:

Serial.println("This gets printed")
yield(); // To reset WDT and provide a best-case scenario
int httpCode = fetch.GET(); // Crash happens within
yield();
Serial.println("This won't always get printed because the ESP resets. It works sometimes, but not consistently");

The endpoints I call are HTTPs as I mentioned and out of my control. They are sometime slow to respond, sometime quicker. I have tested calling a service that is slow on purpose and realized that timeout works with the 5s default set in ESP8266HTTPClient. Page useful to debug timeout-behavior: http://slowwly.robertomurray.co.uk/

I'd be happy to help trying to resolve this as best I can but I'm not a master C/C++ coder (I normally code Java).

Potentially separate issue but I don't want to create issues needlessly. It would be great if the "fetch" class implemented the streaming interfaces required by some libraries, for example: https://github.com/bblanchon/ArduinoStreamUtils. I wrote my own "proxy" for the fetch class to be able to peek() and read() etc. (Not relevant for the watchdog timer issue, it resets before that part is reached).

[maakbaas]

While this library enables full HTTPS on the ESP8266, it is still What is the frequency with which you are updating the dashboard? What is the frequency with which you are doing the HTTPS requests? Are the issues with a specific request target, or with different targets? Do you only have resets when a client is connected to the dashboard? Or is the second case with your code example a separate issue?

Do you think you could provide a minimal code example with a reproduceable issue? Without it it will be hard for me to look into it.

With regards to the streaming interfaces. Feel free to propose this in a pull request if you already did some work on this. It would be appreciated!

[X3Cutor]

Hi I call one API once per hour. The other API I call 4 times per hour. In the last 24h I have had 3 crashes at fetch.GET() or fetch.POST() (I use both, one for each API). This has been without any dashboard clients connected at all during the last few days. I can't find ways to reduce memory usage without scrapping functional code so memory wise my code is about as lean as it can be give or take a few bytes. I suspect certain external (server side) factors may contribute to the frequency or infrequency of watchdog related crashes but I have no knowledge how to debug this and this is just speculation on my part seeing as how the frequency of the crashes varies over time. Both API's generate crashes though and they are completely independent services run by different companies in different parts of the world so there is bound to be a weak spot somewhere in the ESP https stack.

Both API's are non-public so even if I were to share my code I you couldn't connect and test it without credentials, none of which would be easy to come by.

Reg. the streaming part, I haven't modified the library at all so I don't have anything pull request compatible, I just use it as an imported dependency. Here's the class I hacked together to make a stream out of it. Again, I'm not a C/C++ coder so there's probably lots of room for improvement. Feel free to draw inspiration from it or discard.

streamify.txt

[maakbaas]

Hi,

Sorry for the delayed response. It could very well be that there is an issue somewhere within the stack, causing these unpredictable resets. Right now, I don't see anything I can do about this issue with regards to this repository. Therefore I will close this issue.

If other people run into the same situation, or if you have more updates or information that could help looking into this, feel free to let me know of course!

Sorry I can't be of more help right now.