I have found at least two major problems and a mystery :-)
First problem is related to issue #595 which states that there is no network error handling at the ESP8266 level. In English this means that if the ESP8266 detects a network error, it silently ignores this. When working with Thing Speak, we need to assume that Thing Speak may ignore our HTTP GET request ... when that happens, the lack of the ability to form a connection is not handled by the ESP8266 and it keeps the socket open. This means that we start to leak sockets and quickly die. The solution is to detect the failure to form the connection and shutdown the socket.
The second problem is related to the logic of the sample application. It's logic says "Every period, make a GET request to thing speak" ... however that logic doesn't say "At the end of the PREVIOUS GET request, schedule another request to Thingspeak". What this means is that if a request to connect to Thingspeak takes a while, more and more parallel requests could be made until we run out of resources. The solution is to change the logic to use setTimeout at the completion of the last GET request instead of setInterval which keeps sending new GET requests irrespective of whether previous ones completed.
The last note is still a mystery. When we use the Espruino "http.get()" method ... that is an asynchronous call ... it takes a callback function to be invoked when the response from the get request is available ... however ... we have a problem. In ESP8266, all network calls are asynchronous and this includes the formation of the connection request in the first place. What should happen when the "http.get()" request connection fails ... because it will be an asynchronous connection and happen later in the story ... this is going to be tricky.
Again ... I believe that http.get() assumes a synchronous call while ESP8266 network connections are asynchronous. We may be plain stuck here for a while.
© Espruino, powered by microcosm.
Report a problem