(Display Widget's output of DHT22 data ) Stops working after a few days

Using an ESP8266 (nodemcu hardware, running as ESP8266 standalone)) connected by Wifi, with just a DHT22 temperature probe connected. Blynk library version 0.5.0. Adafruit DHT Library 1.5.0. Blynk App 2.18.1 running on Android. Connected to Blynk’s servers.

My program simply sends temperature and humidity values to the server once a second, together with any newly reached maxima and minima in those values.

The problem is that the code runs fine for a few days, and then I stop receiving any data updates on my phone - even though it shows the sensor/ESP8266 are still connected. This is repeatable, and happens after the same length of time each time.

I suspect a memory leak or a counter overflowing inside the library, or similar issue, as my own code is simple. See below.

#define BLYNK_PRINT Serial

#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <DHT.h>

char auth[] = "<secret>";

char ssid[] = "<secret>";
char pass[] = "<secret>";

#define DHTPIN D4          // What digital pin DHT22 is connected to
#define DHTTYPE DHT22   // DHT 22, AM2302, AM2321

DHT dht(DHTPIN, DHTTYPE);
BlynkTimer timer;
static float t, tmin, tmax, h, hmin, hmax;

BLYNK_WRITE(V0) // Button to reset limits
{
  h = dht.readHumidity();
  t = dht.readTemperature();
  
  if (isnan(h) || isnan(t)) {
    Serial.println("Failed to read from DHT sensor!");
    return;
  }
  hmin = h; Blynk.virtualWrite(V1, h); // hmin
  hmax = h; Blynk.virtualWrite(V2, h); // hmax
  tmin = t; Blynk.virtualWrite(V3, t); // tmin
  tmax = t; Blynk.virtualWrite(V4, t); // tmax
                                       // Also update current value
  Blynk.virtualWrite(V5, h);           // h
  Blynk.virtualWrite(V6, t);           // t  
} 

BLYNK_WRITE(V1) {  hmin = param.asFloat(); } // For data coming from server
BLYNK_WRITE(V2) {  hmax = param.asFloat(); }
BLYNK_WRITE(V3) {  tmin = param.asFloat(); }
BLYNK_WRITE(V4) {  tmax = param.asFloat(); }

void sendSensor()
{
  h = dht.readHumidity();
  t = dht.readTemperature(); // or dht.readTemperature(true) for Fahrenheit
  
  if (isnan(h) || isnan(t)) {
    Serial.println("Failed to read from DHT sensor!");
    return;
  }
  Blynk.virtualWrite(V5, h);
  Blynk.virtualWrite(V6, t);

  if(h<hmin || isnan(hmin)) {hmin=h; Blynk.virtualWrite(V1, h);}
  if(h>hmax || isnan(hmax)) {hmax=h; Blynk.virtualWrite(V2, h);}
  if(t<tmin || isnan(tmin)) {tmin=t; Blynk.virtualWrite(V3, t);}
  if(t>tmax || isnan(tmax)) {tmax=t; Blynk.virtualWrite(V4, t);}
}

void setup()
{
  Serial.begin(9600);

  Blynk.begin(auth, ssid, pass);

  dht.begin();

  Blynk.syncVirtual(V1,V2,V3,V4);            // Get old limits from server
  
  timer.setInterval(10L * 1000L, sendSensor); // Set timer to send data every 10 s
}

void loop()
{
  Blynk.run();
  timer.run();
}

What version of the ESP Core are you using?
There was certainly a memory leak with static float variables in an earlier version.

Out of interest, why are your float variables declared as static?

Pete.

You mean as shown by the boards manager? Version 2.4.0, the latest version.

The static part is a hangover from having the variables inside the function in an earlier version of the code, where I wanted to preserve the values between calls. Anyway, it should not in principle matter,

I don’t want to assume for sure, but I have noticed some instability with 0.5.0 with very busy projects… and have been comparing runtime longevity between library versions. However, in my case while the projects stop, they do restart and carry on automatically until next time… but then I have made use of Blynk’s Connection Management so that is to be expected.

One way for you to eliminate it as an issue, would be to fall back to 0.4.8 (last real solid version prior to current) and wait it out… if your project runs longer without issue… well then we all know :wink:

While waiting for an official fix, as a workaround, I count how long the program has been running for, and reboot it after it has been running for 24 hours, using ESP.restart().

However, it would be nice to get some official response to this bug - is it in the Blynk libraries, or the underlying ESP32 Arduino core, for example?

You need to track down the issue and in case this is Blynk issue - we will fix it. Right now there is not enough info to make any conclusions and especially wait for “official fix” :wink:.

1 Like

I have to fix Blynk bugs after paying you guys? :frowning:

It might help you or worry you, but I’m 99% sure it is NOT Blynk issue! You see what is happening in this place of code, right? Then I’m hurry to inform You, that those DHT’s are prone to hangs, especially when queried too fast. And 1sec is a bit fast to them…

To check if I’m right, You can disconnect the DHT after it stops sending data, and reconnect again. This way you gonna reset DHT but not MCU.

No, but you do have to convince, with repeatable and clear datum, that there is a “bug” and not a localized issue at your end… code, network, hardware, etc.

Basicly do what all of us need to do before we can expect anyone, other forum members or the developers, to drop everything and hold our hand through our issues.

If there is a bug, they will fix it, but so far there is no evidence of any bug :wink:

Did you do any quantitative comparison between differing libraries?

Can you test any other long running projects? Confirm power, network, environment, etc?

@Gunner, DHT’s are just piece of crap. At least those “white” AOSONGS (or whatever).

If you look at the code you will see I am querying it very 10 s, not very second.

Also, it repeatably fails after the same time of about 4.5 days, which is indicative of exhaustion of some resource, most likely memory, or overflow of some internal variable used for counting.

You tried what I have suggested to You? (Resetting the DHT)
I’ve been through it, so it’s based on my experience. And I’m querying the DHT every 30sec. It happened just once, but it happened. And it was the DHT.

And Yes, still using it, but I won’t change my mind regarding their reliability…

I dont know how to convince you.

The fact that it fails after the same time each time indicates it is not likely to be a network error, power failure, etc.

The code is simple, and you can see by looking at it for 5 minutes that I am not intrinsically doing anything to run out of resources or cause overflow.

Furthermore, my phone shows the device is connected the whole time, despite data not arriving. If there were network or power failures, the device would show as not being connected.

I hardly need my hand holding. I have been teaching computer science for 35 years. :slight_smile:

Oh, and removing the DHT and reinserting it without rebooting does NOT fix the problem.

Thank heavens… then I don’t need to explain how to setup a serial monitor, run debugging routines, checks of memory, RSSI, reset reasons, or any of that… you have it covered :slight_smile:

PS, I’m not the one you need to convince…

I admit the bug could also lie in the DHT library. But I have had a look at that code, and there is no obvious memory leak / overflow issue in that.

It could also be in the ESP core…

change to:

if (isnan(h) || isnan(t)) {
    Serial.println("Failed to read from DHT sensor!");
    h=0.0;
    t=0.0;
  }

and report… Then we will be sure it is not DHT’s fault… (what I’m betting on)
Still I may be wrong…

I remember a troubleshooting story wherein a restaurants WiFi based POS system (that is Point of Sale, not Piece of S… :stuck_out_tongue: ) always failed at the same time of day… nightmare for days until an onsite tech noticed that ever same time of day the stage lighting was turned on for the nightly entertainment. High frequency lights causing WiFi issue… absolutely nothing to do with the POS system being faulty.

I do not want to set h and t to zero, as incorrect data are not acceptable in my application. I want exactly what I have written - no data if I cannot get a reliable reading.

Sure… I understand You, but at first You gonna debug the setup, right? You can change it for whatever you want: previous data, dummy data, whatever. After debugging it, you can leave it as Your needs are!

I’m just pointing You the possible error, or weak point. You can do it, or not. It is up to You…

1 Like