ESP8266 hangs/stops responding when sent commands from different devices

[SeeJayDee]

Hi,
first off thanks for your amazing work on this library!

I'm having some teething issues - I loaded the ESP8266 example sketch and successfully switched an LED on/off via GPIO2.

The serial terminal (115200/NL&CR) reads:
r [unintelligible - couldn't copy using ctrl-c] üü‚n„bà...
WiFi connected
Server started
192.168.1.134

and http://192.168.1.134/...
...mode/2/o
...digital/2/0
...digital/2/1
...all work as expected

However, the device will stop responding if I send .../digital/2/0 from my computer, and then .../digital/2/1 from my phone.
I don't know if this is known behaviour, or if there is some problem handling connections from multiple devices?

I don't know how to output debugging information in browser or serial terminal either. I tried AT commands but I don't think they work.

Sorry to bother you with my noobness!

[marcoschwartz]

Hi! Not a problem, I love to answer questions & to hunt down bugs.

In this case, you found a bug indeed. It seems that phone's browsers tend to send a lot of additional data along with the request. For example:

User-Agent: Mozilla/
5.0 (iPhone; CPU iPhone OS 9_2 like Mac OS X) AppleWebKit/
601.1 (KHTML, like Gecko) CriOS/
47.0.2526.107 Mobile/
13C75 Safari/
601.1.46

Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

And this seems to mess with the library. Marking this as a bug :)

[SeeJayDee]

Hi again, I have tried this using only one device (my PC) this time, and I'm still getting hang events.

I reset the board, then (via WiFi + Chrome) send the pin mode, then every 5/10 seconds toggle the pin state. After 6 or 7 state changes it'll lock up and not respond until reset.

In both cases (this and the original report) the serial terminal was open. Don't know if that makes a difference or not.

Is it possible for aRest to receive commands from both serial and WiFi at the same time? Would be interesting to see if it can still respond to serial commands when this issue occurs.

[SeeJayDee]

Is there any way I can make it spit out some information you'll find useful?

[saliehendricks]

Hi @SeeJayDee

To print out debug data add #define DEBUG_MODE 1 at that top of your sketch. If that doesn't work, try changing that line in aRest.h.

I did have similar issues to you. After switching to a dedicated 3.3v power source capable of >=1A current, things got more stable.

You should be able to use the underlying handle(char* string) function to process serial instructions. You can see how it is used in the function:

void handle_callback(PubSubClient& client, char* topic, byte* payload, unsigned int length)
{
  // Process received message
  ...
}

Hope that helps

[SeeJayDee]

Ahh, rats!

I'll try that. Hoping it's not a supply issue, right now it's a zener diode

• npn which should be good for about 800mA at 3.25v. I only had 78L33 regs
  (<100mA) on hand. I'll also change to a dedicated 5V supply instead of USB
  port.

EDIT: Tested with a benchtop power supply. Still having the problem. Oddly it will stop responding even if left alone after switching the LED on and off once.

On 12 Jan 2016 5:00 am, "saliehendricks" notifications@github.com wrote:

Hi @SeeJayDee https://github.com/SeeJayDee

To print out debug data add #define DEBUG_MODE 1 at that top of your
sketch. If that doesn't work, try changing that line in aRest.h.

I did have similar issues to you. After switching to a dedicated 3.3v
power source capable of >=1A current, things got more stable.

You should be able to use the underlying handle(char* string) function to
process serial instructions. You can see how it is used in the function:

void handle_callback(PubSubClient& client, char* topic, byte* payload, unsigned int length)
{
// Process received message
...
}

Hope that helps

—
Reply to this email directly or view it on GitHub
#83 (comment).

[SeeJayDee]

Seems to be associated with the back/forward buttons in browser. Also, I noticed from the debug output that the browser would send a request as I was typing the URL (ie .../mode/2/o ) and then re-send it once I hit enter.
Holding down F5 in browser also crashed the board.

[pickeld]

same issue as @SeeJayDee described.
esp8266 loses connection after holding F5. it also loses connectivity in many other cases.
trying to change to MQTT to figure if a software issue.

hopefully someone could solve the problem.

[obzerving]

marcoschwartz has already identified the bug at the top of this thread. In my experience, I've found that when I try to access the ESP8266 with a browser, it hangs almost immediately. Yet, if I write programs only accessing it with calls to Curl, it never hangs. I'm attributing that to the fact that my calls to Curl use a very small number of headers. However, I'd really like to see this bug fixed, so I can access the ESP8266 with a browser.

[SeeJayDee]

I have found that when I create a simple on/off button using the aREST UI
library (to control a relay), the problem seems to go away.
This is in contrast to the previous method of controlling the I/O pins manually through the address bar.

In other words, it appears to be related to requesting new pages/urls from
the device, not by using forms/controls on an already-loaded page.
On 17 Feb 2016 1:37 am, "obzerving" notifications@github.com wrote:

marcoschwartz has already identified the bug at the top of this thread. In
my experience, I've found that when I try to access the ESP8266 with a
browser, it hangs almost immediately. Yet, if I write programs only
accessing it with calls to Curl, it never hangs. I'm attributing that to
the fact that my calls to Curl use a very small number of headers. However,
I'd really like to see this bug fixed, so I can access the ESP8266 with a
browser.

—
Reply to this email directly or view it on GitHub
#83 (comment).

[yomasa]

So do you think this is do to a memory leak in the arduino api? aRest offers very useful functionality.
Hope we can get this working soon...

[obzerving]

Although I hope it's not the case, it's possible that the problem is use of the String class. As pointed out in Dave Crocker's Solutions Blog (https://miscsolutions.wordpress.com/2011/10/16/five-things-i-never-use-in-arduino-projects/), "The problem is that String operations allocate memory dynamically... Dynamic memory allocation typically causes memory fragmentation. This means that your program may work correctly for some inputs or a short while, but crashes with other inputs or after a longer time, due to memory exhaustion. "

[SeeJayDee]

Maybe the debug mode could also print the output from freeMemory() in
MemoryFree.h (or the newer one in MemoryFree.cpp)...
I'll test it in my own time.

Further reading:
http://electronics.stackexchange.com/questions/66983/how-to-discover-memory-overflow-errors-in-the-arduino-c-code

http://stackoverflow.com/questions/8873998/string-array-not-deallocated-upon-scope-exit

On 20 March 2016 at 11:19, obzerving notifications@github.com wrote:

Although I hope it's not the case, it's possible that the problem is use
of the String class. As pointed out in Dave Crocker's Solutions Blog (
https://miscsolutions.wordpress.com/2011/10/16/five-things-i-never-use-in-arduino-projects/),
"The problem is that String operations allocate memory dynamically...
Dynamic memory allocation typically causes memory fragmentation. This means
that your program may work correctly for some inputs or a short while, but
crashes with other inputs or after a longer time, due to memory exhaustion.
"

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#83 (comment)

[SeeJayDee]

Also, this
https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/

On 22 March 2016 at 10:50, Christian D'Abrera chrisdabrera@gmail.com
wrote:

Maybe the debug mode could also print the output from freeMemory() in
MemoryFree.h (or the newer one in MemoryFree.cpp)...
I'll test it in my own time.

Further reading:

http://electronics.stackexchange.com/questions/66983/how-to-discover-memory-overflow-errors-in-the-arduino-c-code

http://stackoverflow.com/questions/8873998/string-array-not-deallocated-upon-scope-exit

On 20 March 2016 at 11:19, obzerving notifications@github.com wrote:

Although I hope it's not the case, it's possible that the problem is use
of the String class. As pointed out in Dave Crocker's Solutions Blog (
https://miscsolutions.wordpress.com/2011/10/16/five-things-i-never-use-in-arduino-projects/),
"The problem is that String operations allocate memory dynamically...
Dynamic memory allocation typically causes memory fragmentation. This means
that your program may work correctly for some inputs or a short while, but
crashes with other inputs or after a longer time, due to memory exhaustion.
"

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#83 (comment)

[yomasa]

Any new developments on this issue?

[yomasa]

@marcoschwartz Is this right? on the esp8266? Serial print will crash it, no if debug? also Serial and client code not the same hard coded id in one.

void publish_proto(T& client, String eventName, V value) {

// Format data
String data = "name=" + eventName + "&data=" + String(value);

Serial.println("POST /" + String(id) + "/events HTTP/1.1");
Serial.println("Host: " + String(remote_server) + ":" + String(port));
Serial.println(F("Content-Type: application/x-www-form-urlencoded"));
Serial.print(F("Content-Length: "));
Serial.println(data.length());
Serial.println();
Serial.print(data);

// Send request
client.println(F("POST /1/events HTTP/1.1"));
client.println("Host: " + String(remote_server) + ":" + String(port));
client.println(F("Content-Type: application/x-www-form-urlencoded"));
client.print(F("Content-Length: "));
client.println(data.length());
client.println();
client.print(data);

}

[SeeJayDee]

@yomasa Where is that code from?
When I have time I will test the aREST library with FreeMemory.h and post the results, although if you can do it sooner please go right ahead.

[marcoschwartz]

Not solved yet, but I am working on it. I am looking for memory leaks using the MemoryFree library, but there is still a little leak I can't fix so far.

[yomasa]

tried the mkr1000 also locks and hangs.

[reapingminer]

I tried to access the esp8266 using a python script calling the URL directly:
(e.g.: "http://192.168.0.10/analog/12/511") and the esp8266 hangs. If i only call the IP the esp8266 returns code 220, without any action (even if the command is sent as a message.). However, only if i add header data (faking a browser call) the esp8266 executes the command. (Using the full URL described above). Sounds like a related problem? Ofcourse, i have experienced the locking up behaviour of the esp8266 as well using just plain browser calls. But i have not yet tested sending different commands repeatedly using that python script.

[marcoschwartz]

After several test, I eliminated several memory leaks & found out that the remaining leak at each call is exactly 184 bytes. This is related to this issue:

esp8266/Arduino#1923

So it's not a bug from aREST, but some inherent from the TCP protocol in the ESP8266 library. I tested it with 'slow' requests every 10 seconds to the board, the memory indeed goes back to normal after a while. I will post an issue there to see how to solve it, in the meantime if somebody has a solution to solve this don't hesitate to post it :)

[dsacristan]

I had the same problem: 2 or 3 clients, even in the same pc with different browsers, hanged my device. I deleted the delay(1) and now it's been working for 4 days without hangs.
// Handle REST calls
WiFiClient client = server.available();
if (!client) {
return;
}
//while(!client.available()){
//delay(1);
//}
if (client.available()) rest.handle(client);
client.stop();

[vks007]

Guys, was anybody able to solve this issue. I have this same issue but with a variation. I am not using aREST and have tried this with the simple webserver example. At times making a call from a phone goes through while laptop browser does not although this is not consistent. Sometimes it keeps working for a day while sometimes it hangs within hours. To debug this, I am making calls to a website every 30 sec now to log if I loose connectivity or something like that to trigger this behavior but all that keeps working fine. I am able to make internet calls from the ESP but the webserver stops responding.
Another thing that I tried was recycling the webserver every 10 minutes. It still hangs. Not able to figure out what is the state of the webserver when this happens. Is there anything I can do to log the state of the server ? I dont see any useful things exposed in the ESP8266WebServer class for this.

[keepfishes]

I have a wemos mini and a hacked sonoff, both are using the esp8266, however both are crashing after about 24 hours of maintaining a http server with decreasing heap size. My code is written using Arduino IDE. I am currently trying to switch to UDP protocol and see if the issue surfaces after 24 hours testing . If it survives still, I will lengthen the test. I suppose that UDP being less of a memory hog should do better...

[tstepnia]

In my case, in order to prevent issues (and stop unwanted data flow), I am simply stopping WebServer after expected connection comes - then I am starting it once ready for the next one.

//we got new connection_
  server.stop();
//let's do the job here;
  delay(30000); // does your server really has to reply to each and every connection?
  server.begin(); // ready to resume.

[jeancode]

En realidad ya llevo dos dias con este tipo de problemas tengo con servidor escalable a que quiero enviar informacion por medio de tcp 100 / segundo

tiene una maxima direccion de 1 hora y el dispositivo se cuelga he corrido un monto de pruebas directamente escritas en c++ como todo un dios pero el problema persiste, montando un servir http simpe en el puerto 80 en el dispositivo esp8266 despues de1 hora el servidor se colgaba al cabo de dos minutos el dispositivo se reiniciaba son la saturacion de la memoria del wificlient, intente solucionar retornando al setup para no tener que reiniciar el chip al aparecer la solución es buena pues el reinicio del circuito de radio es inperceptibles pero auna si se sigue reiniciando me parece que hay un block que habla sobre un capasitor para reducir los bajones de voltaje que provoca la antena de radio.

[Spackstor]

I also am experiencing this issue. My router shows the esp8266 connection but after an indeterminate period of time it appears to lock up. I like the browser solution as it is device independent. Writing code that corresponds with a TCP client did not appear to have this issue. But writing apps in android and ios is a pain.
Stopping the server is not practical in my applications. Periodic reboots are not a sure fix. Besides, some of my applications have esp based timers.

I agree with SeeJayDee, this is an amazing library.

I also echo eks007, was anybody able to solve this issue? If not, guess I'm going back to writing apps. Egad.

[marcelstoer]

I experience freezes with an application on ESP8266 12-E that uses aREST 2.7.3 and tracked them down to a problem with aREST.

HTTP GET requests from Safari and cURL are fine, while the ones from Chrome & Firefox cause the device to freeze. It's still pingable in that state, though. cURL is fine even if I send the exact same headers as Chrome does.

The ESP8266 Arduino core version doesn't seem to affect this. Why? I first observed this behavior roughly two years ago. I'm now using the latest 2.5.2 core and the bug is still there.

Details: http://forum.switchdoc.com/post/5740/thread

[marcoschwartz]

This was fixed in the latest versions of the aREST cloud server by implementing a queue mechanism.

[mylinux909]

Why has this thread been closed as completed. I and many others are still having this problem where the ESP8266 stops responding to client requests.

I'm checking ESP.getFreeHeap() and have over 30000 free.
I'm checking ESP.getHeapFragmentation() and goes between 1 to 4.
So heap and fragmentation is not the problem in my situation.

As already stated above, HTTP GET requests from Safari and cURL are fine, while the ones from Chrome & Firefox cause the device to freeze. It's still pingable in that state.

I also installed, EspSaveCrash , GitHub - krzychb/EspSaveCrash: Save exception details and stack trace anytime and anywhere the ESP8266 crashes, https://github.com/krzychb/EspSaveCrash

But no crashes are being recorded.

To get my ESP8266 working after it freezes, I have to unplug the power cord and plug it back in again.