Firstly huge kudos to the developers of Espruino; it's fairly mind blowing being to able to easily and quickly prototype systems on fast hardware with such a simple and well thought development process.
I have come across issues trying to get a reliable send / receive system using MQTT. The problems do not come from the MQTT libraries themselves and I think I have tracked the issues to the EspruinoWifi module which is causing the socket to close during a 'send' cycle.
The following code
send : function(sckt, data) {
if (at.isBusy() || socks[sckt]=="Wait") return 0;
if (socks[sckt]<0) return socks[sckt]; // report an error
if (!socks[sckt]) return -1; // close it
//console.log("Send",sckt,data);
var cmd = 'AT+CIPSEND='+sckt+','+data.length+'\r\n';
at.cmd(cmd, 10000, function cb(d) {
if (d=="OK") {
at.register('> ', function() {
at.unregister('> ');
at.write(data);
return "";
});
return cb;
} else if (d=="Recv "+data.length+" bytes") {
// all good, we expect this
return cb;
} else if (d=="SEND OK") {
// we're ready for more data now
if (socks[sckt]=="WaitClose") netCallbacks.close(sckt);
socks[sckt]=true;
} else {
socks[sckt]=undefined; // uh-oh. Error.
at.unregister('> ');
}
});
// if we obey the above, we shouldn't get the 'busy p...' prompt
socks[sckt]="Wait"; // wait for data to be sent
return data.length;
}
};
attempts to send data using the well known CIPSEND, OK>, sendMyData, SEND OK pattern of the ESP8266 and if there is no incoming data during the send period then everything works fine.
The issue comes in that the callback data will sometimes contain other incoming data (say from an +IPD call) from the RX buffer in which case the final else clause (line 24) determines there has been an error.
I have tried various attempts to better synchronize calls to the SEND function and 'lock' any receive events but haven't been successful.
What does anyone think about simply returning the callback in any situation that is outside the normal flow ?
and it allows the socket to stay running but it still doesn't feel quite right. With a more explicit error clause (not sure what that looks like from the ESP2866 when it fails to send) it seems a workable solution and has allowed me to send and receive asynchronous (publish and subscribe independently) with decent size messages at upwards to 10Hz.
Any thoughts on whether it's a valid fix or whether there are better solutions ??
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Firstly huge kudos to the developers of Espruino; it's fairly mind blowing being to able to easily and quickly prototype systems on fast hardware with such a simple and well thought development process.
I have come across issues trying to get a reliable send / receive system using MQTT. The problems do not come from the MQTT libraries themselves and I think I have tracked the issues to the EspruinoWifi module which is causing the socket to close during a 'send' cycle.
The following code
attempts to send data using the well known CIPSEND, OK>, sendMyData, SEND OK pattern of the ESP8266 and if there is no incoming data during the send period then everything works fine.
The issue comes in that the callback data will sometimes contain other incoming data (say from an +IPD call) from the RX buffer in which case the final else clause (line 24) determines there has been an error.
I have tried various attempts to better synchronize calls to the SEND function and 'lock' any receive events but haven't been successful.
What does anyone think about simply returning the callback in any situation that is outside the normal flow ?
I have tried it as follows
and it allows the socket to stay running but it still doesn't feel quite right. With a more explicit error clause (not sure what that looks like from the ESP2866 when it fails to send) it seems a workable solution and has allowed me to send and receive asynchronous (publish and subscribe independently) with decent size messages at upwards to 10Hz.
Any thoughts on whether it's a valid fix or whether there are better solutions ??
Thanks and regards,
Steve