Espruino Pico webserver

[espruino-discuss]

Posted at 2016-02-26 by ert4

Hello i was wonder if there any why to make the pico a server to host a local webpage. I want to host a webpage to control the light on the pico itself but i don't know how to set it up on the pico or where to start.
------------------------------------HTML

<title>Untitled Document</title>

<script>
    var light = function() {
        var p = document.getElementById("lightnumber").value;
        var q = document.getElementById("number");
        q.innerHTML = "Light: " + p + "%";
    }
</script>
<p>light intensity?<input  name="lightsorce" id="lightnumber" type="text"/>Percent<input type="submit" onclick="light()"/></p>
<p id="number">Light:</p>

--------------------------------------

[espruino-discuss]

Posted at 2016-02-26 by DrAzzy

1. Use the correct section for your question next time, you say you have a Pico, but you posted in the section for Espruino on ESP8266 (this section, per the sticky thread at the top "what goes here" is for discussion of the ESP8266 port of Espruino, not use of an ESP8266 to provide internet access to another board running Espruino). @gordon, can you move this when you see it?

2. Have you read http://espruino.com/Internet and http://www.espruino.com/ESP8266 ? They contain a lot of information about how to set something like this up, with example code and all.

[gfwilliams]

Posted at 2016-02-27 by @gfwilliams

Just moved... as @drazzy says, there's a bunch of info on the website.

You might want to look at http://www.espruino.com/Interactive+Web+UI which shows you how to use Pico + ESP8266 as a webserver that serves up a webpage with a control on it.

[espruino-discuss]

Posted at 2016-10-05 by samppa

Hi @gordon, I was able to make a simple web server on Espruino Wifi board, but it stops responding http requests after awhile. It seems to depend on the http request frequency (overload); if there are several parallel requests coming the server stops output after awhile. I can still see requests coming in and handled by the web server on console window, but the response dot not go to network looking at Wireshark. And ping still goes through during the "outage". Sometimes it recovers after several minutes if the request frequency dropped.
What might cause this weird behavior? And how to make it fail gracefully without jamming totally?

[gfwilliams]

Posted at 2016-10-06 by @gfwilliams

So you're saying that the requests are actually being seen by the Espruino board and handled, just not being replied to over the network?

Roughly how many requests per second are you sending when this becomes a problem?

Could you run E.getErrorFlags() when it happens to see if Espruino's input buffer has ever got full and dropped characters? It should return [] if all is well.

You could also try wifi.at.debug() to start dumping the communications to the ESP8266, to see if it's a problem with Espruino not sending the responses, or if it's the ESP8266 itself getting swamped.

My guess is it might be the ESP8266 itself though - in that case I'm not really sure what to suggest... I guess if you see some error message from the ESP8266 after doing at.debug then we could handle that and use it to do something - I'm not sure what would be appropriate though.

Is it possible that the computer sending the requests has just left a bunch of connections open? In that case the ESP8266 would have to wait until they timed out before it was able to open more.

[espruino-discuss]

Posted at 2016-10-06 by samppa

Before the hand E.getErrorFlags() returned LOW_MEMORY once.
The max frequency it still works is about 5 to 10 times per second.
Also the open connection might be one cause, but how to force them to close?

wifi.at.debug() provided this lead:

["AT+CIPSERVER==1,80\r\n"
>Uncaught Error: CIPSERVER failed (Timeout)
 at line 1 col 53
throw Error("CIPSERVER failed ("+(a?a:"Timeout")+")");
                                                    ^
in function called from system

[espruino-discuss]

Posted at 2016-10-06 by ClearMemory041063

Have you installed the capacitor on the shim?

[gfwilliams]

Posted at 2016-10-06 by @gfwilliams

I think he's using the Espruino WiFi in which case it's already got something on there.

CIPSERVER failed (Timeout) is actually when it fails to create a webserver - which should only happen at the start (you should only ever be creating one server). Do you get that error when things start breaking? Could you post up your code?

I wouldn't worry too much about LOW_MEMORY - it means it had to force a garbage collect, but nothing went wrong and no data was lost.

5-10 requests a second is relatively high for it though - I wouldn't expect the ESP8266 to handle much more than that. It's just how long it takes it recover after you stop hitting it with that many requests.

[espruino-discuss]

Posted at 2016-10-06 by samppa

Yes its Espruino Wifi with embedded ESP8266.
The previous with wifi.at.debug() capture was indeed wrong and from the startup.

Here is better one from the failure case:

["AT+CIPSEND=3,339\r\n"
] "2," <--- "2,"
] "2,CLOSED\r\n" <--- "CLOSED\r\n"
] "2,CONNECT\r\n\r\n+IPD,2,367:GET /rand?c" <--- "2,CONNECT\r\n\r\n+IPD,2,367:GET /rand?c"
] "+IPD,2,356:allback=sensors&_=1475779474639 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW" <--- "allback=sensors&_=1475779474639 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW"
] "+IPD,2,222:64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept" <--- "64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept"
] "+IPD,2,76:-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n" <--- "-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n"
["AT+CIPSEND=2,339\r\n"
] "4,CL" <--- "4,CL"
] "4,CLOSED\r\n0,CLOSED\r\n" <--- "OSED\r\n0,CLOSED\r\n"
] "0,CON" <--- "0,CON"
] "0,CONNECT\r\n\r\n+IPD,0,367:GET /rand?callback=sensors&_=147" <--- "NECT\r\n\r\n+IPD,0,367:GET /rand?callback=sensors&_=147"
] "+IPD,0,335:5779474640 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36" <--- "5779474640 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36"
] "+IPD,0,200: (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflat" <--- " (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflat"
] "+IPD,0,53:e, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n4,CONNECT\r\n\r\n+IPD,4,367:GET /rand?callback=sensors&_=1475779456262 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection" <--- "e, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n4,CONNECT\r\n\r\n+IPD,4,367:GET /rand?callback=sensors&_=1475779456262 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection"
] "+IPD,4,281:: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n" <--- ": keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n"
["AT+CIPSEND=0,340\\r\n"
] "1,CLOSED\r\n" <--- "1,CLOSED\r\n"
] "1,CONNECT\r\n\r\n+IPD,1,367:GET /rand?callback=sensors&_=1475779474641 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (K" <--- "1,CONNECT\r\n\r\n+IPD,1,367:GET /rand?callback=sensors&_=1475779474641 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (K"
["AT+CIPSEND=4,339\r\n"
] "+IPD,1,197:HTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n" <--- "HTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n"
] "3,CL" <--- "3,CL"
] "3,CLOSED\r\n" <--- "OSED\r\n"
] "3,CONNECT\r\n\r\n+IPD,3,367:GET /rand?callback=sensors&_=1475779447035 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari" <--- "3,CONNECT\r\n\r\n+IPD,3,367:GET /rand?callback=sensors&_=1475779447035 HTTP/1.1\r\nHost: 192.168.100.184\r\nConnection: keep-alive\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari"
["AT+CIPSEND=1,339\r\n"
] "+IPD,3,152:/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n" <--- "/537.36\r\nAccept: */*\r\nReferer: http://192.168.100.97:8081/gauge.html\r\nAccept-Encoding: gzip, deflate, sdch\r\nAccept-Language: en-US,en;q=0.8,fi;q=0.6\r\n\r\n"
["AT+CIPSEND=3,339\r\n"
>

The issue is that since I cannot control the requests the server should fail gracefully, restart and not jam.

[espruino-discuss]

Posted at 2016-10-06 by samppa

During the capture above the clients timed out and did not receive anything although some requests came through and were "handled" by the Espruino but not sent to network. Or then the client timed out before the reply was ready and sent too late. So it seems there is some request queue that is longer than client side timeout.

[espruino-discuss]

Posted at 2016-10-06 by samppa

Here is my code:

function getA(pin, randomize) {
  if (randomize) return Math.round(100*Math.random());
  else return Math.round(100*analogRead(pin));
}

function returnJsonStr(res, json) {
  res.writeHead(200, {'Content-Type': 'application/json',
                      'Connection' : 'close',
                      'Content-Length': json.length});
  res.write(json);
  //console.log("Returned JSON: " + json);
}

function returnError(res, msg) {
  res.writeHead(400, {'Content-Type': 'text/plain',
                      'Connection' : 'close',
                      'Content-Length': msg.length});
  res.write(msg);
  //console.log("Returned error: " + msg);
}

var next_state = 1;
function swap() {
  LED1.write(next_state);
  next_state = !next_state;
}

function pageHandler(req, res) {
  //console.log("Client request: " + JSON.stringify(req));
  if (req.url == "/favicon.ico") {
    res.writeHead(200, {'Content-Type': 'image/x-icon'});
    res.write(favicon);
    //console.log("Client served with favicon.ico");
  } else if (req.url == "/led") {
    swap();
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.write("Led toggled.");
    console.log("Client toggled LED");
  } else {
    var r = false;
    if (req.url.substring(0, 5) == "/rand") r = true;
    var content = "sensors(" + 
        JSON.stringify([
          { 
            sensor : "A0", 
            value : getA(A0, r) },
          { 
            sensor : "A1", 
            value : getA(A1, r) },
          { 
            sensor : "A2", 
            value : getA(B0, r) },
          { 
            sensor : "A3", 
            value : getA(B1, r) },
          { 
            sensor : "A4", 
            value : getA(A4, r) },
          { 
            sensor : "A5", 
            value : getA(A5, r) },
          { 
            sensor : "A6", 
            value : getA(A6, r) },
          { 
            sensor : "A7", 
            value : getA(A7, r) }
        ]) + ")";
    returnJsonStr(res, content);
    // console.log("Client served. (rand:"+r+") E.getErrorFlags: " + E.getErrorFlags());
  }
  res.end();
}

function reboot() {
  console.log("Restarting to recover error..");
  E.enableWatchdog(1);
  while(1);
}

var favicon = "\0\0\x01\0\x01\0\x10\x10\x10\0\x01\0\x04\x00\xf0\0\0\0\x16\0\0\x00\x89PNG\x0d\x0a\x1a\x0a\0\0\0\x0dIHDR\0\0\0\x10\0\0\0\x10\x08\x06\0\0\0\x1f\xf3\xffa\0\0\x00\xb7IDAT8\x8d\xa5S\xc1\x0d\x03!\x0csN\xb7\x91w\xcaP\xde)3\xd1G\x09\x0a\x85\xab\xa8\xea\x0f\x02\x82c\x1b0\x92x\x82\xbb\xb7:\x8f\x08D\x84\xd5\xb5\x1b\x00H\xb6>N\x04uN\x12\x92\x10\x11S\xcd]\x0b\xbf\xa9\xe9\x8a\x00\xa0I\x1a*\x06A\x97\xb7\x90\xd4\x8e$A\x12\xee\xde\xb2vR\x90$\xc8q\xf6\x03\xbc\x15Ldw]\x88zpc\xab*\x8c\x08H\xb2A\x90\x1e\x97\xce\x1bd3\x00\xb8v\x9b\xa7p\xf7\xb6\x10\x9cb\xc9\xe0Wd\x06\x17\x80v\xe2\xfb\x09\x17\x00H\xfa\x8b\xc0\xba\x9c\xe3CU\xf1\xc8@\xd2\x08fW\xf8i3?U\x12\x18z\x16\xf5A\x9ddc_\xee\xbd~e{*z\x01|\xcdnfT\x03\x0an\0\0\0\x00IEND\xaeB`\x82";

var WIFI_NAME = "xxx";
var WIFI_OPTIONS = { password : "xxx" };

function onInit() {
  console.log("Connecting to WiFi");
  var wifi = require("EspruinoWiFi");
  wifi.connect(WIFI_NAME, WIFI_OPTIONS, function(err) {
    if (err) {
      console.log("ERROR connect():"); 
      console.log(err);
      setTimeout(function() {reboot();}, 5000);
      return;
    } else {
      console.log("Connected");
      wifi.getIP(function (err, ip) {
        if (err) {
          console.log("ERROR getIP():"); 
          console.log(err); 
          setTimeout(function() {reboot();}, 5000);
          return; 
        }
        wifi.at.debug();
        console.log("Web server at: " + JSON.stringify(ip));
        var http = require("http");
//        E.enableWatchdog(2);
        http.createServer(pageHandler).listen(80);
      });
    }
  });
}
save();

[espruino-discuss]

Posted at 2016-10-06 by @allObjects

The code - assuming it supposed to run on EspruinoWifi board - messes with the pins that are used for communication of Espruino with ESP8266. Do not use any pin marked with purple box in EspruinoWifi board reference.

I see that in getA(...) you have an emulation of reading from pins when uri begins with /rand. (I assume /rand is detected and works). This would mean that something else goes high wire.

Doing any read on a pin auto-configs the pin to input an then Espruino is / cannot properly write to ESP8266 anymore (on pin A2, for example). For ADC, use only from pin set B0, B1, A0, A1, A4, A5, A6, A7. A good practice is to config the pins with pinMode(...).

[espruino-discuss]

Posted at 2016-10-06 by samppa

If you look closely I am actually using B0 and B1 to replace A2 and A3 in the code so that is not the culprit.
And yes you are right hat the "rand" is for faking the actual analog readings with random number for testing client side views. That part works and I get good readings before it jams when overloaded by multiple clients. Client is a web page with jQuery ajax calls rendering values with highcharts to gauges and charts. The situation is easily reproduced by having several web pages requesting the Espruino simultaneously.

What should be the timeout on the client side? I use 5 seconds. And 500 ms repeat interval.
After the Espruino server is flooded and stops responding in timely fashion, all the clients start to time out and they all have to be removed until it recovers. Still some requests go through slowly every now and then (the capture above). Those requests are seen in wireshark, but no reply.

[espruino-discuss]

Posted at 2016-10-07 by @allObjects

...my bad not noticing the replacement / mapping. I assumed you had used the sensor faking to isolate the issues.

Your test proves that being swamped is not well handled yet. From what you notice is that requests still enter Espruino, but responses don't make it out anymore.

Could you verify that the requests made it completely - uncorrupted - into Espruino? I have kind of the feeling that requests - respective their responses - get mingled within Espruino's async handling code. It - packet / request sequencing issues - could already have its roots within ESP8266... even though I would expect the code to be mature enough by now to handle sequencing.

The next isolation level of issues is to make a test with just one way traffic - just requests and no responses - and figure out the tanking point.

[espruino-discuss]

Posted at 2016-10-07 by ClearMemory041063

I've had a similar issue using two Picos one Posting data and one acting as a server. Client posts data (80 characters), server receives and echos data over and over and finally it crashes with the CIPSERVER fail message. I think it has to do with the number (5) of sockets. I though it might be the capacitor on the shim but haven't had time to install them for a test. Wifi.debug() displays the socket information.

[gfwilliams]

Posted at 2016-10-07 by @gfwilliams

@ClearMemory041063 it'd be good if you could find a way to reproduce this?

Since there can only be 5 sockets (#0..#4), Espruino's driver uses socket #5 to represent the server. It might be that the 0.60 firmware supports more sockets and so hits #5, which makes Espruino try and do server-related stuff?

@samppa so that dump was during the point at which it wasn't responding? It looks like Espruino is working perfectly, so it's on the ESP8266 side.

Could you try:

// connected
wifi.at.cmd("AT+CIPSTO=2\r\n",1000,function(d) {
  print(d);
  // start server, do other stuff here
});

That sets the server timeout. It's never been an issue before, but it might allow the server to drop connections where nothing happens for 2 seconds, which should hopefully aid speedy recovery.

[gfwilliams]

Posted at 2016-10-07 by @gfwilliams

So there's no difference at all? I'd expected that the server might go offline, but now would recover after 2 seconds?

Also, I imagine the 60 second timeout in httpGetAsync won't be helping matters for recovery? It'd be better to set that to 2 seconds as well.

If your webpage is actually just creating loads of connections and not closing them, I'm not sure what can be done. It's like you're making you own mini denial of service attack on the Espruino board.

Maybe the server can respond with a Connection:close header - not sure if that helps? As Espruino seems ok, you could just reset the ESP8266 if that was easier... a disconnect from the wifi and reconnect a second later should do it.

How often are you expecting to be polling from each webpage that views the Espruino Wifi? If it's more than every few seconds them IMO you should really be using WebSockets - which will keep one connection open and allow you to update as many times as you want.

[espruino-discuss]

Posted at 2016-10-07 by samppa

@gordon Unfortunately no help or different behavior in this case.
The 60 second timeout helps to give Espruino time to answer if several requests are buffered to be handled. The server already responds with Connection:close header, but that does not help when the request is not completed properly.

Yes indeed the situation is like a DOS attack, but it should recover after the spam is over and that is not the case at the moment.

Next I will try the wifi disconnect trick. But how the server knows when to do that since everything seems fine on that side?

[gfwilliams]

Posted at 2016-10-07 by @gfwilliams

So did you actually try it with the 2 second timeout in the ajax request? My guess is there are a whole bunch sockets being held open by the PC, and it's those open sockets that are blocking everything else until they finally time out.

If the ESP8266 gets overwhelmed, you want the AJAX request to fail as soon as possible - then you can just try again later (you could even detect it and decrease the speed at which you issue requests). It might even be worth setting the timeout even lower than 2s.

If you close all the webpages and restart them, does the server spring back into life faster? That would help to narrow it down.

Also, what about the WebSocket suggestion?

But how the server knows when to do that since everything seems fine on that side?

Yeah, I have no idea - short of just seeing if you have no requests for a while. If you do find a way, you might find that closing the server and re-opening it solves everything, and is much faster than restarting the ESP8266.

[espruino-discuss]

Posted at 2016-10-07 by samppa

@gordon Faster timeout on client side makes the situation worse since the request that has gone out from client cannot be aborted in a way that it would go away from the buffers on network or sever side. Therefore issuing new request after timeout just adds to the pile. The request can be aborted on the client side ajax but I think that has no effect on server side.

Of course after timeout I could wait longer before issuing next request, but that is handled kind of automatically by waiting the timeout longer.

Using WebSockets is a bit more complicated (not done that before and I like the idea of stateless and client agnostic server) so I would not like to go there now that the requests actually work :-)

How should I close and reopen the server in a sound way (code example)?

By the way, thank you so much for helping me out!

[espruino-discuss]

Posted at 2016-10-07 by samppa

@gordon : Closing and creating the server does not seem to resolve the jam.
I made the inactivity checker like this:

function checkInactivity() {
  if (Date.now() - lastPageHandled > 20000) {
    clearInterval(checkInactivityIntervalId);
    lastPageHandled = Date.now();
    console.log("Inactivity detected restarting webserver..."); 
    if (server) {
      server.close();
    }
    server = http.createServer(pageHandler);
    if (server) {
      console.log("Webserver restarted.");
      checkInactivityIntervalId = setInterval(checkInactivity, 2000);
      server.listen(80);
    } else {
      console.log("ERROR createServer() returned false."); 
      console.log(err); 
      setTimeout(function() { reboot(); }, 5000);
      return;
    }
  }
}

Should I do some deeper cleanup/reset/disconnection than just recreating the http server?

Also I get these errors during the restart:

>Uncaught Error: CIPSERVER failed (Timeout)
 at line 1 col 53
throw Error("CIPSERVER failed ("+(a?a:"Timeout")+")");
                                                    ^
in function called from system

[gfwilliams]

Posted at 2016-10-10 by @gfwilliams

The error during restart is because the server won't have been able to close instantly, but you are trying to recreate it on basically the next line. It's also possible the ESP8266 is taking a while to try and close all the active connections to the server...

You could try:

if (server) server.close();
server=undefined;
setTimeout(function() {
    server = http.createServer(pageHandler);
    ....
}, 1000);

[espruino-discuss]

Posted at 2016-10-13 by samppa

@gordon Thanks for the tip, but it did not help.

I still get this at server startup:

Inactivity detected restarting webserver...
Webserver restarted.
>Uncaught Error: CIPSERVER failed (Timeout)
 at line 1 col 53
throw Error("CIPSERVER failed ("+(a?a:"Timeout")+")");
                                                    ^
in function called from system

Here is the inactivity checker with 2 sec delay for server start:

function checkInactivity() {
  if (Date.now() - lastPageHandled > 60000) {
    clearInterval(checkInactivityIntervalId);
    lastPageHandled = Date.now();
    // Close server and reopen it.
    console.log("Inactivity detected restarting webserver..."); 
    if (server) {
      server.close();
    }
    server=undefined;
    setTimeout(function() {
      server = http.createServer(pageHandler);
      if (server) {
        console.log("Webserver restarted.");
        checkInactivityIntervalId = setInterval(checkInactivity, 2000);
        server.listen(80);
      } else {
        console.log("ERROR createServer() returned false."); 
        console.log(err); 
        setTimeout(function() { reboot(); }, 5000);
        return;
      }
    }, 2000);
  }
}

[espruino-discuss]

Posted at 2016-10-13 by samppa

At each code upload from IDE to EspruinoWifi I get this error:

ERROR: Prompt not detected - upload failed. Trying to recover...

By the way is there any way to reset or cleanup the Wifi? Would that help?

[gfwilliams]

Posted at 2016-10-13 by @gfwilliams

Hmm, it looks like the ESP8266 is just too busy to respond - probably a reboot of the ESP8266 is required (server.close() followed by wifi.reset()).

By the way: The ESP8266 is never contacted until .listen - so createServer will probably always be successful.

It's a bit of a hack but you could use the uncaughtException event if you can't find another way of detecting issues : http://www.espruino.com/Reference#l_process_uncaughtException

[espruino-discuss]

Posted at 2016-10-13 by samppa

@gordon

Uncaught Error: Function "reset" not found!
 at line 176 col 10
    wifi.reset();

[espruino-discuss]

Posted at 2016-10-13 by samppa

same for wifi.close()..

wifi.disconnect() worked. Let's see if that helps..

[espruino-discuss]

Posted at 2016-10-13 by samppa

What happens if wifi.listen fails?

[gfwilliams]

Posted at 2016-10-13 by @gfwilliams

Ok, just do:

server.close();
wifi.disconnect();
setTimeout(function() {
  wifi.connect(..., function() {
   // ...
  });
}, 200);

That'll actually power cycle the WiFi

[espruino-discuss]

Posted at 2016-10-13 by samppa

@gordon Now it recovers! Great! Thanks!

Of course that does not resolve the root cause..

[gfwilliams]

Posted at 2016-10-13 by @gfwilliams

I'm actually having a lot of trouble reproducing this with your code. I uploaded it to the board and added the 'Access-Control-Allow-Origin': '*' header so I could access it from another file.

Then I stuck your polling code in a html file set to call 5 times a second. Any more and it refused to work:

<html>
<body>
<script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
<script>
var xhr;
function httpGetAsync(theUrl, jsonpcb, ok, err) {
    if (xhr && xhr.readyState != 4) {
        xhr.abort();
       }
    xhr = jQuery.ajax({
       type:'GET',
       url:theUrl,
       cache:false,
       timeout: (60000),
       crossDomain: true,
       error: err,
       success: ok
    });
}

setInterval(function() {
  httpGetAsync("http://192.168.1.164/", function(c) {
    console.log("JSON",c);
  }, function(c) {
    console.log("OK",c);
  }, function(c) {
    console.log("ERR",c);
  });
}, 200);
</script>
</body>
</html>

And then loaded it in 4 windows - so that's 20 requests per second.

After a bit I started getting the following:

ERR Object {readyState: 0, status: 0, statusText: "abort"}

But interspersed with the correctly returned page. After closing the extra windows the board immediately returned to working correctly. So I'd say the behaviour was perfect.

So I'm thinking this is probably the computer(s) that are requesting data that are still keeping connections open. Which web browser are you using on them?

When you have problems, could you run:

global["\xff"].HttpSC.forEach(function(s,i) {var x=s.svr;s.svr=0;print(i,s);s.svr=x;})

and post the result? It's possible that connections are open and the HTTP header hasn't got through, so Espruino is just leaving sockets open waiting for a response. If so, it might be possible to add a timeout on Espruino's side that would close the connections if the header wasn't received within the first second.

You could also try:

global["\xff"].HttpSC.forEach(function(s) {s.closeNow=true});

That should force Espruino to close all server connections immediately.