Espruino Pico webserver

Posted on
Page
of 2
/ 2
Next
  • 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­

    <meta charset="UTF-8">
    <title>Untitled Document</title>
    


    <script>
        var light = function() {
            var p = document.getElementById("lightnumber").v­alue;
            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>
    

    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.

  • 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.

  • 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?

  • 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.

  • 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
    
  • Have you installed the capacitor on the shim?

  • 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.

  • 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&_=1475779474­639 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.

  • 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.

  • 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\x0­4\x00\xf0\0\0\0\x16\0\0\x00\x89PNG\x0d\x­0a\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\xa­8\xea\x0f\x02\x82c\x1b0\x92x\x82\xbb\xb7­:\x8f\x08D\x84\xd5\xb5\x1b\x00H\xb6>N\x0­4uN\x12\x92\x10\x11S\xcd]\x0b\xbf\xa9\xe­9\x8a\x00\xa0I\x1a*\x06A\x97\xb7\x90\xd4­\x8e$A\x12\xee\xde\xb2vR\x90$\xc8q\xf6\x­03\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\x9­c\xe3CU\xf1\xc8@\xd2\x08fW\xf8i3?U\x12\x­18z\x16\xf5A\x9ddc_\xee\xbd~e{*z\x01|\xc­dnfT\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();
    
  • 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(...).

  • 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.

  • ...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.

  • 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.

  • @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,funct­ion(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.

  • @Gordon Yes during the dump the clients failed to receive anything and wireshark showed only HTTP requests but not replies. I can reproduce the situation by first adding clients and in a few seconds it jams so that I can remove all the clients but one (once a second) and still it does not recover.

    Now while testing I got E.getErrorFlags: BUFFER_FULL before it got stuck
    And at restart of the Espruino I got FIFO_FULL, but then it recovered.

    In any error scenario I would like the node to restart, clear and continue to operate. How that could be done?

    There are also many situations where the requests are not coming into the page handler at all. The EspruinoWifi server just sits there and does nothing while all the requests fail with timeout. It recovers when I upload the code and reset with the Web IDE when it is stuck it recovers.

  • To be honest, with at.debug() the overflows aren't unexpected since it's pushing all that data over USB. Try it without at.debug() and see if you still get the buffer full warnings?

    Have you tried the AT+CIPSTO command yet?

  • Yes @Gordon I removed the at.debug() and added the AT.CIPSTO like this:

     console.log("Web server at: " + JSON.stringify(ip));
            var http = require("http");
    //        E.enableWatchdog(2);
            wifi.at.cmd("AT+CIPSTO=2\r\n",1000,funct­ion(d) {
              print(d);
              var server = http.createServer(pageHandler);
              if (server) {
                server.listen(80)
              } else {
                console.log("ERROR createServer() returned false."); 
                console.log(err); 
                setTimeout(function() {reboot();}, 5000);
                return;           
              }
            }
    

    But it made no difference..

  • One difficulty is that on client side ajax I cannot make HTTP request with "Connection:Close" headers since they are forced to keep-alive.

    Here is my client side request function:

    var xhr;
    function httpGetAsync(theUrl, jsonpcb, ok, err) {
    	if (xhr && xhr.readyState != 4) {
    		xhr.abort();
           }
    	xhr = jQuery.ajax({
           type:'GET',
    	   headers: {Connection: close}, // No effect
           url:theUrl,
           cache:false,
    	   timeout: (60000),
    	   jsonpCallback: jsonpcb,
    	   crossDomain: true,
    	   dataType: 'jsonp',
           error: err,
           success: ok,
    	   beforeSend: function( xhr, settings ) {
             xhr.setRequestHeader( "Connection", "close" ); // No effect
    		 settings.headers = {Connection: close}; // No effect
           }
        });
    }
    

    But still in wireshark I can see the request has "Connection : Keep-alive" in HTTP headers.

  • 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.

  • @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?

  • 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.

  • @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!

  • @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
    
  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Espruino Pico webserver

Posted by Avatar for ert4 @ert4

Actions