When you say "printing to USB" would "console.log" be included? Not that I'm printing much, just error messages.
Yes, it would - but if you're only printing errors then the error has already happened when it's printing, so that won't be it :)
Is there a maximum length on MQTT topic and message lengths?
I could be wrong, but maybe 126 chars I think? I doubt you'd be hitting it.
Is it OK to put stringified JSON in an MQTT message on Espruino?
Yes, totally - that should be fine.
Also, I was wondering about using "tinyMQTT". Is there any advantage in using this over the native "mqtt"? I notice in the docs that this does have a "127 byte publishing length limit" though. Is this topic and/or message?
I'm not sure about the limit - it could be both. I think tinyMQTT was started because some people wanted something that would fit inside the ESP8266 when the port was very limited, but it could be worth a try. If it does work correctly it'd narrow the problem down a lot!
I'll keep exploring. It's not causing me major problems. Currently my Espruino has been up for 21 hours, processed 841 packets and only had 6 bad packets. It would be nice to get to the bottom of it though!
Ok, that's not so bad - and it recovers ok? I'd assumed it stayed totally broken when you got the error.
The latest travis builds (http://www.espruino.com/binaries/travis/master/) now check specifically for a UART overflow - so if you get a chance that could be interesting I guess, as it'd tell you if data was getting lost at a lower level or not.
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.
Yes, it would - but if you're only printing errors then the error has already happened when it's printing, so that won't be it :)
I could be wrong, but maybe 126 chars I think? I doubt you'd be hitting it.
Yes, totally - that should be fine.
I'm not sure about the limit - it could be both. I think tinyMQTT was started because some people wanted something that would fit inside the ESP8266 when the port was very limited, but it could be worth a try. If it does work correctly it'd narrow the problem down a lot!
Ok, that's not so bad - and it recovers ok? I'd assumed it stayed totally broken when you got the error.
The latest travis builds (http://www.espruino.com/binaries/travis/master/) now check specifically for a UART overflow - so if you get a chance that could be interesting I guess, as it'd tell you if data was getting lost at a lower level or not.