http server crashing

[Sparkxxx]

Hi Sticilface,

Nice work with the application, it looks promissing. I have tested it and I have found some issues with the web server.

1. If you make fast refreshes the http server crashes (timed out) but the app on the esp continues to run with a heap of 19064 in my case (serilal debug). Do you know anything about this behavior?

2. I couldn't find a way to disable the web interface (I would like to do this especially that the authentification is not implemented yet). Could you help with disabling the web interface after config is done?

Thank you.

[sticilface]

thanks.

the answer to 1 is yes kind of. The ESP has really limited resources, it can only handle 5 connections. I suspect that it leaves open connections from the previous refresh, which are held open for the max timeout as the page was refreshed. Each time you load my manager page, it puts out a request for data as a post. I'm not sure there is any way around it except to not do that! :)

2) This is an interesting point. How would you propose to re configure it? You would essentially be locked out. In some of my own deployments, I use GPIO 0 as a switch, if you hold it down for 10 seconds you get a factory reset. this would be one way, but I can't build this into the ESPmanager.

what are your thoughts?

[Sparkxxx]

1. Isn't there a way to detect the stalled web server and restart/disable/enable it? Unless there is a way to do this the esp becomes useless anyway and has to be manualy rebooted which is not what we expect, especially if it's been deployed in the atic.
2. As I've seen the implementation of mqtt is already done (I am using websockets https://github.com/Links2004/arduinoWebSockets - also async and this is why I gave EspManager a try) so the esp would do what it has to do trough commands received/sent from remote. I imagine a way in which you would use a websockets connection to carry the json between esp and client on browser (a websockets server would handle it) and the webserver would only serve as the way to provide the support for this, send the js and don't load it again. The web pages content/json updates need to be pulled from browsers and this is what wreaks the http server, which brings me to the other sugestions:
3. make the project a little bit more modular (with some defines maybe) so that you would be easyley able to choose what features you would like to implement in the new sketch and expose these methods to the main sketch. Now it's a monolith take it or leave it kind of thing. For example I would like to configure the webserver firmware update from page but call it from sketch when I decide, same with the ota, udp discovery, logs, tasker, etc.
4. the behavior without wifi at the restart of the module should have a definable period for which the module would wait for a known ssid before spawning an AP and since there is no limitation (using spiffs not eeprom) a backup set of credentials would be wellcomed.
5. Tasker should have an interface that would allow the management of it and the action should be user definable if possible.

Thanks.

[sticilface]

Sorry for the delay

1. The only way for the web server to become stalled would be if the ESP itself was crashed. There is no loop with the async method, so as soon as it gets requests the callback is handed down trough lwip->asyncTCP->asyncserver->handle. so there is no stalling.
   2) not quite sure what u mean here... the http request is crashing the server. This is by far the most stable of HTTP implementations that i've used. on possibility is that ur using blocking commands within the Cb which will crash the ESP.

3) Is is fairly modular. the includes are in the espmanager.h

4) This tasker is meant to be behind the scenes. you can just spawn your own. check the header for taster it has some cool stuff, including a process dump.