ESP8266 Community Forum

- Fri Nov 10, 2017 4:03 am #71728 I am trying to use an ESP8266 module to talk to an MQTT server and Google Sheets. I have experienced some flakiness, but I'm not sure why. The MQTT stuff I've had running (use PubSub library) for months, and it seems rock solid. The Google Sheets stuff(using the HTTPSRedirect library) seems fairly solid, but only if the debugging is enabled, which causes a bunch of stuff to be printed on the serial terminal(I'm assuming the extra delays this incurs "fix" some problem?) . So is there any reason why the PubSub client and the HTTPSRedirect client could or should not co-exist? Apparently the HTTPSRedirect libray uses the WiFiClientSecure lib, whereas the PuSub does not(as far as I know).

Maybe I should investigat using the latest HTTPSRedirect library, but I wanted to check that I'm not trying to do something monumentally stupid before throwing more effort at this(the main effort is endless testing for reliablity).

- Fri Nov 10, 2017 11:10 am #71743

<...>
seems fairly solid, but only if the debugging is enabled, which causes a bunch of stuff to be printed on the serial terminal(I'm assuming the extra delays this incurs "fix" some problem?) .
<...>

If extra delays, code based or I/O based, then the issue could be that the task switcher non-OS is not being serviced within the max recommended timeframe, 50mS. You can force Arduino to release to the native RF section using yield(), delay(0), or delay(1) ... note that users have reported that delay(0) and delay(1) do not have the same entry point and some folk swear by one or the other... personally, I think yield() is more appropriate.

Point is, if the Arduino loop() function is not automatically repeated in 50mS you must make some provision via your code to switch to the RF side for servicing the protocol stack, etc.

Ray

- Fri Nov 10, 2017 12:38 pm #71747 Thanks, but not sure if I made myself clear. I'm not adding any extra delays, as such, but speculating that the delays introduced by enabling the debugging, which prints out loads of stuff to the serial port, are what makes the code work reliably, as opposed to having debugging turned off, when the code seems flakey.

My main loop has no delays in it, but obviously I don't know exactly waht is going on in the functions I'm calling in the HTTPSRedirect library.

On the other hand, it could just be sod's law, in that it won't malfunction when debugging is enabled, as that would help me to understand where the problem is..

- Fri Nov 10, 2017 7:29 pm #71759 Thanks for the reply. By "some flakiness", I'm talking about hanging. No resets, no diagnostic messages. But very intermiitent.