@ralphrmartin donāt use 9600 baud with ESPās.
Donāt use buttons in PUSH mode without checking pin status. When you press the button at the moment it will try to read the BME280 twice within a fraction of a second and send 12 virtualWrite()'s almost consecutively. In my copy of your project I have changed the button to SWITCH mode.
More feedback to follow.
Iām one of those. My āboiler monitorā based on ESP-01 is mostly Blynk based (recently added MQTT support), and working constantly for a year now. It never needed forced rebooting, but naturally has been rebooted few times (power failures, OTA reflashingā¦)
The other one (not last one) needed reboot because of DHT issue, as pointed earlier. It has not lost connection, but stopped sending data. Happened just once.
Are you using the latest release of this library (V2.3.0) or the master branch (V3.0.0)?
I would recommend 3.0.0.
I have tested your project on a NodeMCU v 1.0 and a WeMos D1 Mini and it seems to have been fine for the last few hours. Iāll leave it running through the night.
Yes, my NodeMCU (*2) have been running continuously updating DHT22 Humidity and Temperature, BME 280 Pressure, light intensity and rainfall to Blynk App and Thingspeak. They only stop when I stop them which is not often. They update to Blynk every 15 seconds or so and to Thingspeak every 10 minutes.
They also reconnect after rebooting my modem without any intervention from me
@ralphrmartin the BME280 is still happily sending data to the server.
In the 6 hour plot you can see where we switched from WeMos to NodeMCU.
Out setup is not exactly the same as yours but pretty close. I will try to tweak our system so the only difference will be that you are using NodeMCU 0.9 and we are using 1.0. Once I have done that I will let it run for a week or so connected up to the Serial Monitor of one of our spare PCās.
I thought I had a couple of spare BME sensors kicking around here, but it looks like my spares are in Spain. Iāve ordered a couple, which should be here later this week, when they arrive Iāll start testing. This will be on a NodeMCU v1.0 or Wemos D1 Mini as a donāt have a v0.9 and Iām not prepared to buy one just for this.
Pete.
Thanks everyone for comments.
(1) After rebooting, the project has now run for 12 hours (previously it was about 6 hours), and still going. It is thus behaving differently to its consistent failure time with the DHT22. It could still be memory corruption, of course, but it may also be that my NodeMCU hardware. is flaky and that the consistent failure times before were chance.
(2) Costas, the push button is basically never used. It is just there to reset the limits if for any reason the values get corrupted. I have not pushed it during the runs when failure occurred, I agree this could be coded better, and will change it to set a flag, triggering it to reset the values on the next normal read.
(3) Marvin, busa, thanks for your data points indicating that projects can run for a long time without issues. That is tipping the balance away from a memory leak.
(3) Costas, I am using v2.3.0 of the BME Library, and while 3.0.0 rc may well be better, it wonāt be responsible for the fault when using the DHT sensor, so is not really relevant to this discussion.
Costas, thank you for taking the time and trouble to replicate my setup. It seems to point to some hardware issue with my nodemcu v0.9 (either generically for such devices, or that just my device is bad).
Gunner: going back to an earlier point you made: the device is only 4m from the router, with only one pane of glass in between, so Wifi signal should be quite strong. Plus, the device appears connected even when I stop getting data. So I donāt think Wifi interference is the issue - surely in that case I would just lose a few readings. Anyway, the app shows connectivity is fine, and my LED is showing that the sensor is not returning values, which is why none are being sent to the server.
So going along the hardware line further:
- I believe my power supply is good. It is a genuine Samsung 2A power supply, so hopefully current draw will not be causing voltage drops.
- Whatever is causing the issue affects the NodeMCU irreversibly until the next reboot. I donāt just lose a few sensor values. Once the sensor stops sending values, I dont get any more. Something ālocks upā. Whatever is locked up is not just i2C, as it also happens for the DHT22, yet the device apparently remains connected.
- Do any of the other pins need to be tied up or down to help reject interference?
- If there is interference, how could it work in such a way as to not be transient, but to cause a lock up (for example, maybe receiving an interrupt on some pin at the wrong time could be an issue).
Anyway, the key thing now is to replace the NodeMCU hardware, and see if the code runs without locking up. Iāll do that as soon as the replacement arrives.
Any further insight welcomed. Thanks again to all who are helping to resolve this.
Tried using the BME280 3.0.0 Library with the BRZO I2C Library, but the supplied example has compilation errors. Iāll stick with the 3.0.0 default i2C.
Play Review revised to reflect help given here, which I appreciate.
Costas, your readings from that BME280 sensor are incredibly constant, for all 3 readings (apart from one glitch and the changeover). Iām amazed that your local air pressure isnāt going up and down. Is it in a sealed, heated container or something? If not, Iād suspect that thereās something peculiar about your hardware. Itās not a simulator, is it?
i run multiple DHT22 + BME280ās + DS18Bās on multiple ESP8266-12ās for months without my code āstopping workingā?
how many MCUās have you tried to troubleshoot with?
i buy ESP8266-12ās at ten a t a time, so a few bucks eachā¦ if one is troublesome (i have killed a few, but none have āfailedā) i just bin itā¦
oh, and none of my codes have anything like this, anywhere:
if (isnan(h) || isnan(t)) {
Serial.println("Failed to read from DHT sensor!");
return;
Neither do mine, none of my codes has isnan tests. They are not necessary and a possible code stopper. I have suggested to remove them because itās probably here the code stops sending data to the blynk server.
If my devices stops sending data to blynk for some reason, the rest of the program will not stop, relays will switch on and off as intended. Once the problem is over it will start sending again, as shown below (9 AM):
yeah, if sensor/s have issues, i have stuff like this to hopefully help!
if ((houseTemp <= 0) || (roofTemp <= 0) || (baseTemp <= 0))
{ //Auto drying mode - ERROR situation - possible sensor malfunction
digitalWrite(roofVent, LOW); // roof vent closed
digitalWrite(houseVent, LOW); // house vent closed
digitalWrite(ventFan, HIGH); // ventilation fan is OFF
fanTimerCancel = 1;
if (debug == 1)
{
Serial.println(F("Drying mode = ERROR - some/all temps are at/below 0 'C - CHECK SENSORS"));
Serial.println(F("------------"));
terminal.print(currentTime);
terminal.println(": Drying mode = ERROR - some/all temps are at/below 0 'C - CHECK SENSORS");
terminal.flush();
}
Blynk.virtualWrite(V10, 0); //fan LED
Blynk.virtualWrite(V7, 0); //hse LED on Blynk app
Blynk.virtualWrite(V8, 0); //rof LED on Blynk app
Blynk.virtualWrite(V9, 0); //bse LED on Blynk app
Blynk.virtualWrite(V1, 255); //ERR. LED on Blynk app
Blynk.notify(String("WARNING basement plenum sensor <0'c error..."));
}
else if (isnan(medianRoofDewPoint) || isnan(medianHouseDewPoint) || isnan(medianBaseDewPoint))
{ //Auto drying mode - ERROR situation - possible sensor malfunction
digitalWrite(roofVent, LOW); // roof vent closed
digitalWrite(houseVent, LOW); // house vent closed
digitalWrite(ventFan, HIGH); // ventilation fan is OFF
fanTimerCancel = 1;
if (debug == 1)
{
Serial.println(F("Drying mode = ERROR - some/all temps are NaN - CHECK SENSORS"));
Serial.println(F("------------"));
terminal.print(currentTime);
terminal.println(": Drying mode = ERROR - some/all temps are NaN - CHECK SENSORS");
terminal.flush();
}
Blynk.virtualWrite(V10, 0); //fan LED
Blynk.virtualWrite(V7, 100); //hse LED on Blynk app
Blynk.virtualWrite(V8, 100); //rof LED on Blynk app
Blynk.virtualWrite(V9, 100); //bse LED on Blynk app
Blynk.virtualWrite(V1, 255); //ERR. LED on Blynk app
Blynk.notify(String("WARNING basement plenum sensor NaN error..."));
}
No itās not a simulator but we do a lot of simulation work for our clients.
We moved the project to a spare PC earlier today, switched to Blynkās cloud server and a few other tweaks to make it as close to your system as possible.
Look for scale @Costas had choosen 
Small atm pressure variations will not be reflected on chart, but sensor fault would be visible for sure.
@ralphrmartin: Do you have a scope at hand? Or logic analyzer? I wonder if sensor was still queried, when failed (I mean DHT). Regarding BME - it is even more confusing, as I never had a single issue among all 3 Iām usingā¦ Might be some wiring/hardware error. Anyway, good luck!
I didnāt select any scale I am simply using the OPās QR code.
Ok, then it ādefaultedā at full scale. Anyway when air press is displayed from 0 up to >1000 it will be hard to observe few hPa change, that is why it is flat. (Not because of sim)