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

Heh… Believe it or not, there is a madness to my method :stuck_out_tongue: I purposely stir some topics up because that brings in more attention and ultimately ideas and resolutions trickle in. Sure, I get flack, but I found it often works… assuming the issue is not completely bonkers in the first place :crazy_face:

I wasn’t criticising your approach @Gunner, it was @ralphrmartin’s somewhat aggressive approach to this “Blynk Bug” that I don’t think helps the situation and doesn’t encourage others to chip-in with ideas.

Pete.

1 Like

@marvin7

Yes, the isnan test is probably where the code stops, but why would the sensor crash after 4,5 days, and run as normal again after a restart? That does’t sound like a faulty sensor to me.

It’s easy to test this, comment out

if (isnan(h) || isnan(t)) {
Serial.println(“Failed to read from DHT sensor!”);
return;

And see what the device sends to the Blynk app after 4,5 days.

don’t ask me! But it happened… And I had an indication of NaN occurrence, so it was exactly what happened. And sending ESP.restart() not helped…

So you had excactly the same problem, a sensor crashing after 4,5 days, again and again?

Not really the same, as mine crashed ONCE, and only once… How many days it run before? I don’t remember, but up to a week. But you can help me to understand, WHY THOSE SENSORS are unable to send reliable data from time to time? (And sometime ANY reliable data until reset…) A sensor issue? A library issue??

Pete, you have a very strange understanding of the law. If I sell something, I can’t just say “the code is open source, so you can fix it yourself”. Blynk are selling a service, built on their code. I can thus have a reasonable expectation for it to work. If this were an entirely community project it would be a different matter. If the error is in the DHT library - it’s not their fault, I agree. If the error is in their code, or code they call, that’s another matter.

Anyway, to all others - I have added a virtual LED to the code instead of ignoring NaNs, and and removed the daily reset. As soon as I can get to the sensor to update it, I’ll see what the LED tells me if and when the sensor nest stops sending data.

@ralphrmartin, I believe Guys from Blynk would react quite fast, and fix the reported issue (as it happened in the past) IF ONLY they would have enough indication that the issue came from their part of work. It never happened they refused to admit - YES, WE HAVE A PROBLEM. At most they were asking to wait for a fix. But when only one user reports specific problem, then there need to be some confirmation, and help to pinpoint the issue.
I get your point: “I pay, I demand”. But as we are with cars: You can’t expect manufacturer to fix the radio, which you have installed on your own! And here we are building project from "LEGO: blocks… Some blocks came from Blynk, some from other professionalist, many (most) from Arduino enthusiasts. There is also Your part of code. Then which block failed??

Sure you can… since it is not being “sold” to you… it is freely available… you do NOT have to purchase additional energy, you do not even have to use their Cloud Server and can install your own (also provided freely by Blynk) and manage your own energy.

You are not gaining any ground here trying to pass the buck. Do some actual troubleshooting, and as you probably require of your students… Show Your Work :stuck_out_tongue:

Try some stuff…e.g. serial prints to record timing, SuperChart to also track data, Add in extra data flow to see if it is just the DHT reading or other Blynk.virtualWrite() commands (UpTime, etc.) that get blanked out, even a button in the App to toggle the device LED to confirm App to device communication or not… does it still work when the rest doesn’t, etc…

Then if you find a “bug” as opposed to “user error”, return, present case, and respectfully, patiently, wait resolution.

Or you can take it to court… see how far that gets you :rofl:

1 Like

I know lots of users that have had problems with DHT and ask @ralphrmartin to concentrate on removing this from the equation before spouting the law.

1 Like

Further data. I have now replaced the DHT sensor with a BME280 sensor (and now send the pressure as well).

I have also included a virtual LED to show whether the sensor is getting valid data.

This time, the code ran for about 6 hours before failing to send data. The LED is indicating that the sensor is failing to return valid values.

I’ve restarted it and am waiting to see how long it runs for now.

It seems rather unlikely that 2 different sensors of 2 different types are both faulty, and in the same way that they work for a while then stop sending data. (I’m not exposing them to any harsh environment etc.)

As the DHT and BME devices don’t work in the same way (one is I2C based, the other is not), it seems rather unlikely that their respective libraries are in each case the cause of the problem, and more likely that something unchanged as at the base of this.

That leaves us with several possibilities
(1) fault in my code - it is given above and is very simple, and if anyone can see a problem with it, I will gladly be enlightened and apologise
(2) faulty ESP8266 board - if all else fails, I have another on order and will try that
(3) problem in ESP8266 Arduino core
(4) problem in Blynk routines

If anyone can see other possibilities to 1-4 above, please chip in.

In fact, Googling a bit shows that quite a few people have problems with their ESPs losing network connectivity after a while, but that does not seem to be the same issue. I am not losing network connectivity - my Blynk app on my phone shows the ESP as connected all the time.

If the sensors are not faulty, I suspect what I am seeing is faulty program behaviour, due to either memory corruption or resource exhaustion, in either ESP core or Blynk libraries. (This may or may not be triggered or exacerbated by a similar cause to whatever is causing other people to lose net connectivity with their ESP 8266s.)

My previous suggestion of overflow due to it being 4.5 days can now obviously be ruled out, as the error occurred after just a few hours in the new code.

To try to constructively take this further, and try to track down where the issue might lie:
(1) Is there anyone on here who has successfully run an ESP8266 continuously with ongoing network activity, without issue over several weeks or more?
(2) and was it using Blynk?

Gunner, your app ran for 5341 minutes, but it was only sending data once every 5 minutes.That’s 1000 or so updates.
I’m sending data once every 10 secs, so if I got an error after 6 hours, that’s over 2000 updates before failure.
It would be very interesting to see how long your app ran for if you made it update more frequently.
I see you were also using an ESP8266…

Can you post your latest code (with the BME sensor changes), details of exactly which non-Blynk libraries you are using (with hyperlinks so that we can download exactly the same ones), and details of the hardware you’re using and how you’ve connected your sensor?

Details of the widgets you have set-up in your app, and whether you’re using IOS or Android would also be handy.

Pete.

No, that was sending just the DHT22 Temperature and Humidity data every 5 minutes… it is ALSO sending current and voltage updates every second… (and I forgot until I looked… two Blynk bridge updates to another project with the Temp and Hum data every 14 seconds)… all while also running a loop demo sequence of RGB strip LEDs in the background (using FastLED). The little Wemos D1 Mini that could :steam_locomotive: :smiley: (let me know if you want the code)

I also have a ESP-01 running both DHT11 (yes the really bad one) and a DS18B20 that has been running on my bench for weeks…

I would love to show screenshots, but I had to reset my D-Link router this morning, so that triggered my reset algorithms and has restarted all my up-time counters.

If anything that router is my weak link in my whole network as it sometimes tends to require a reboot every few months. I have had it for years but I have yet to email them with a complaint :wink:

Thanks, then that is evidence against it being libraries. Anyway, I’ll do as Pete suggested and post code etc. I’m afraid my replcement hardware is on its way from China so may be a few days yet :slight_smile:

@ralphrmartin in addition to the code and you providing details of your smartphone we are going to need the QR code image for a clone of the project. You have not been consistent with the details you have provided. You started by saying:

You then went on to say you were not updating every second but after 10 seconds. This is confirmed by your rather odd timer frequency of 10L * 1000L, rather than 10000L.

There are also other inconsistencies so we will need to replicate your faulty system exactly to see if we can find any problems.

My current code is


#define BLYNK_PRINT Serial

#define RED   "#FF0000"
#define GREEN "#00FF00"
#define BLUE  "#0000FF"

#include <ESP8266WiFi.h>
#include <BlynkSimpleEsp8266.h>
#include <BME280I2C.h>
#include <Wire.h>

// You should get Auth Token in the Blynk App.
// Go to the Project Settings (nut icon).
char auth[] = "secret";

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

BME280I2C bme;    // Default : forced mode, standby time = 1000 ms
                  // Oversampling = pressure ×1, temperature ×1, humidity ×1, filter off,

BME280::TempUnit tempUnit(BME280::TempUnit_Celsius);
BME280::PresUnit presUnit(BME280::PresUnit_Pa);

BlynkTimer timer;
WidgetLED led(V10);
float t, tmin, tmax, h, hmin, hmax, p;

BLYNK_WRITE(V0) // Button to reset limits
{
  bme.read(p, t, h, tempUnit, presUnit);
  
  if (isnan(p) || isnan(t) || isnan(h)) {
    Serial.println("Failed to read from  sensor!");
    led.setColor(RED);
    return;
  }
  led.setColor(GREEN);
  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()
{
  bme.read(p, t, h, tempUnit, presUnit);
  
  if (isnan(p) || isnan(t) ||isnan(h)) {
    Serial.println("Failed to read from  sensor!");
    led.setColor(RED);
    return;
  }
  led.setColor(GREEN);
  Blynk.virtualWrite(V5, h);
  Blynk.virtualWrite(V6, t);
  Blynk.virtualWrite(V9, p/100);

  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()
{
  // Debug console
  Serial.begin(9600);

  Serial.println("Restarted");

   Blynk.begin(auth, ssid, pass);

  led.on();
  led.setColor(BLUE);

  Wire.begin(4, 5);                       //  sda = 4 = D2, scl= 5 = D1
  while(!bme.begin())
  {
    Serial.println("Could not find BME280 sensor!");
    delay(1000);
  }
  switch(bme.chipModel())
  {
     case BME280::ChipModel_BME280:
       Serial.println("Found BME280 sensor! Success.");
       led.setColor(GREEN);
       break;
     case BME280::ChipModel_BMP280:
       Serial.println("Found BMP280 sensor! No Humidity available.");
       break;
     default:
       Serial.println("Found UNKNOWN sensor! Error!");
       led.setColor(RED);
  }

  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();
}

The BME Library I am using is this one:
https://github.com/finitespace/BME280

The Wire library is the standard Arduino one.

I am using Android.

The widget is set up so that the following show
values: V1 to V6, v9
led: v10
button: v0
superchart v5, v6, v9

Hardware is
nodemcu v 0.9
Generic I2C BME280 board from Aliexpress

Connections are
Nodemcu BME
3.3V Vin
GND GND
D1 SCL
D2 SDA

Unformatted.

Saying once a second was a slip on my part, for which I apologise. It should have said once every 10 seconds (as others have pointed out, a DHT22 cannot fetch data as quickly as once a second).

It is expressed as 10L * 1000L to make it clearer to read that it is 10 units, where 1000 converts to units of seconds from ms.

The smartphone is a OnePlus 5, running Android Oreo.

Please explain how to provide the necessary QR Code.

However, I must say that given that Gunner has managed to run for longer with an ESP8266 / DHT22, this points more towards there being something wrong with my NodeMCU hardware, rather than the libraries. If so, I apologise for too hastily assuming it to be a software fault.

What did you mean by “other inconsistencies”?

Stop the app, go into the settings, scroll down and you will see a clone facility.