ESP8266 (NODEMCU 2.0) - interruptions in data transmission to thingspeak server

Hello everyone.
I have an unusual problem. Well, I have two (bought from different sources) NODEMCU 2.0 boards, or ESP8266, with which I send data to the thingspeak server. Unfortunately, I have noticed that several times a day there are "gaps" in transmission, the ESP does not send data. The LED on the board then lights up (not the LED from the ESP module, but the other LED, which lights up as soon as it is switched on).

I have tried to look for the cause by the method of elimination, here is what I have accomplished so far:

1. Initially, data was being sent from the DS18B20 sensors. I thought a communication error might be short-circuiting the circuit. NO - I removed the parts responsible for the thermometer from the code and gave a simple sum of i=i+1, it still hangs.

2. I thought serial port communication was to blame - unfortunately, disabling it didn't help.

3. Faulty power supply? Two modules powered from two different USB chargers (700mA), doesn't help.

4. A problem with the router? I ran a hot-spot on my mobile phone, didn't help.


The most interesting thing is that WATCHDOG doesn't reset the board - that is, as if it was doing something "meaningful" all the time, but to no avail.

I've included the program code below - I'd appreciate any help or tips on how to investigate the problem further.

connect it to your computer and let it log the information - is nodemcu resetting by any chance?

Sometimes they don't, because some 'jams' manifest themselves as a lack of any activity, with the LEDs flashing after a reset

I'm digging up the topic, has anyone encountered a similar problem? ESP hangs up at the simplest action

if you have a flashing diode after a reset, it is probably init.lua generating an error and a reboot is happening
another possibility is that you have ground on some GPIO where it shouldn't be, as far as I remember one of the GPIOs adjacent to GPIO0 causes the diode to flash
and finally another is that ESP is in boot mode

Have you connected it to the PC? What is coming out on your serial?
Hanging up is a software bug - I recently noticed that e.g. trying to force gpio1 to go to state 0 causes it to hang up.
You will need to painstakingly debug the whole program by commenting out sections and it will tell you which part of the software is causing the error.

Added after 11 [minutes]:

wait a minute... your program seems to operate the pin for the blinking diode.... then something is happening there

I have one DS18B20 sensor plugged in and nothing else. I have now even unplugged the sensor. Sometimes the hang-up was manifested by the lack of illumination of anything (no flashing of the red LED in the loop, no flashing of the blue one from ESP).
This is interesting because, as the Fellow himself can see, there are no quirks in the program, just connecting to WIFI and sending data. I am uploading a screen shot: a moment after switching on, one of the modules "crashed" and after some time it embraced, the other crashed completely (time on the X-axis - stuck on the last point). Analysis by serial I have not tried, what would a colleague suggest more precisely? E.g. "report" successive code fragments after the serial?


Added after 1 [hour] 4 [minutes]:

Added after 35 [seconds]:

A while ago I commented out the parts concerning the diode (pinmode, digitalwrite), to no avail, nada I have several minutes of "clipping" :/

well, that's no way to debug it.... you have to hook up the computer, put some prints in the code and watch what it spits out, you will see where it wedges

i'm guessing from my experience it's the connection to the host - it can't establish a connection and creates new connection objects reserving memory until eventually when 5-6 are created, it runs out of resources
Additionally, repetitive actions are done on timers and not in a loop. Find an example of a DS that operates on timers.

Colleague lukaszrzepinski it is possible that it crashes when trying to connect, and would you have any idea how to detect this/force a reboot after several attempts?

If I have a moment, I'll try to debug it - I've done it before, but to no avail.

Fellow Peterus, this is an introduction to a larger project

tell it to print the http response and keep an eye on it
if there is no response for a while despite the requests, or they are rare and the node restarts, it could be this

Thanks for the hints, when I have some time I'll get down to testing further

And another question - why is handling the DS18B20 in interrupts better than using the standard library?

Something strange has just happened to me. Well, again no data was appearing on thingspeak, but interestingly enough a response from the server was coming normally on the serial, the loop wasn't hanging up - everything was seemingly working OK except that there was a hole on Thingspeak:





Added after 3 [hours] 29 [minutes]:

One thing I've noticed: the server responses are identical, but when it's not logging, the last digit is "0" (before the "End of response" I added. If the server is logging the data, this digit is probably the measurement point number, lu something like that (a number increasing by 2 with successive measurements). What could the lack of data registration be due to?

Problem probably solved. It turned out that the two boards I was using were synchronising and sending data one after the other every so often, whereas TS requires a minimum of 15 seconds between data updates on a given channel.

and congratulations

thanks I've wasted a lot of time and probably a couple dozen attempts For the past two days both ESPs have been working without a stutter, sending data to two different channels, so it was probably that