ESP8266 and DHT22: NAN errors using libraries >= 1.2.0

[robcazzaro]

I'm using a few Wemos D1 and generic ESP8266-12 as temperature/humidity sensors feeding data to a service. All the ESP8266 devices are plain vanilla, and I use default settings when compiling.The DHT22 is connected to GPIO12, and I invoke the DHT library with

#define DHTPIN 12
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE, 15); //15 critical to stable readings

I have been using them for at least 2 years, using the original 1.0.0 DHT library, with no problems at all. I read the temperature/humidity every 10 seconds

I recently updated my devices with a newer version of my code, and I used Arduino 1.8.5 with newer libraries to ensure I have the latest and best. Same devices, same code. I immediately started getting a lot of NAN returned by the DHT library, and my devices skip roughly 15-20% of the reading cycles as a result.

After a long troubleshooting sessions, I narrowed the problem down to the DHT library version. With any version older than 1.2.0, everything works just fine. As soon as I use a newer library, I get the NAN errors. It looks as if the timing optimization in 9d7a9da (the one that deprecated the parameter count, 15 in my case) doesn't work properly with the DHT22 and ESP8266 I'm using. There is a subtle timing error that at least in my case throws off some readings

I searched online for a similar issue, and found a lot of people with DHT22 and NAN issues, but none seemed to truly apply

It's hard to believe this issue was not discovered in ~2 years, but I have a solid repro in 4 devices at least, and I discovered it only because my code logs NAN results, while most people tend to write code that in case of a NAN repeats the DHT read right away, so might be masked

[khjoen]

it seems this is starting of death or end of life for this lib. Not much support for fundamental problems Happy to help if anyone is ready to fork.

…

On 25 November 2017 at 22:00, robcazzaro ***@***.***> wrote: I'm using a few Wemos D1 and generic ESP8266-12 as temperature/humidity sensors feeding data to a service. All the ESP8266 devices are plain vanilla, and I use default settings when compiling.The DHT22 is connected to GPIO12, and I invoke the DHT library with #define DHTPIN 12 #define DHTTYPE DHT22 DHT dht(DHTPIN, DHTTYPE, 15); //15 critical to stable readings I have been using them for at least 2 years, using the original 1.0.0 DHT library, with no problems at all. I read the temperature/humidity every 10 seconds I recently updated my devices with a newer version of my code, and I used Arduino 1.8.5 with newer libraries to ensure I have the latest and best. Same devices, same code. I immediately started getting a lot of NAN returned by the DHT library, and my devices skip roughly 15-20% of the reading cycles as a result. After a long troubleshooting sessions, I narrowed the problem down to the DHT library version. With any version older than 1.2.0, everything works just fine. As soon as I use a newer library, I get the NAN errors. It looks as if the timing optimization in 9d7a9da <9d7a9da> (the one that deprecated the parameter count, 15 in my case) doesn't work properly with the DHT22 and ESP8266 I'm using. There is a subtle timing error that at least in my case throws off some readings I searched online for a similar issue, and found a lot of people with DHT22 and NAN issues, but none seemed to truly apply It's hard to believe this issue was not discovered in ~2 years, but I have a solid repro in 4 devices at least, and I discovered it only because my code logs NAN results, while most people tend to write code that in case of a NAN repeats the DHT read right away, so might be masked — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#94>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALSrTQ0REpdy4RqdwlPjPDRL6D7mbuJKks5s6NRjgaJpZM4Qqo1J> .

[robcazzaro]

It turns out I did not discover something new: as I suspected, this is a well known and already reported issue (in many forums), one that has already been discussed and a solution is available. What is puzzling, is why this has not been addressed yet, at least for the ESP8266 platform. Even the frequency of the problem as previously reported matches mine

Here's the best link to explain the problem: #48

And the solution is as simple as commenting out two lines (line 155 and 156 of the current library), and avoiding having the processor force the data line high on the DHT22:

// End the start signal by setting data line high for 40 microseconds.

 // digitalWrite(_pin, HIGH);
 // delayMicroseconds(40);

I have made that change in my local copy of the library, and so far have been reading hundreds of samples on 4 boards, not a single error. It's not what I would consider a solid proof yet, but with the un-modified 1.3.0 version I would never have been able to read this many samples without problems

I strongly recommend checking in the fix, if needed in a conditional block for the ESP8266 only (I cannot test on other processors, but I'm sure it's required for the ESP8266... and, based on the original description and the DHT22 datasheet, a required fix for all)

[beicnet]

@robcazzaro Yeah, same issue with me yesterday, but don't forget to change bellow that code:

pinMode(_pin, INPUT_PULLUP);
delayMicroseconds(10);

change delay to from 10 to 50

[robcazzaro]

In my case the change from 10 to 50 doesn't seem necessary, works both way, but I changed it anyway to 50. Thanks for the suggestion, @beicnet

At this point I have ~10k readings, not a single NAN... Pretty confident that this change is needed and much safer than the code currently in the library

I'm leaving this issue open (even if I have a fix now), for future consideration

[beicnet]

@robcazzaro I did the same thing by others proposition, so, I think it will not hurt anyway! Kappa

[ronalLeiva]

@robcazzaro Thanks I had the same problem

[captainju]

I had the same problem and I switched to another lib
https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTstable

[Salty-Doug]

I am new to Arduino and microcontrollers. I had the nan problem with an ESP32 & DHT22 in Arduino IDE. I commented out the two lines above in DHT.cpp but when I downloaded the code I only saw "nan". Any ideas?

[robcazzaro]

Methinks that the timing of the much faster ESP32 does not work well with the DHT22 timing. I have really grown to dislike the DHT22, too sensitive to even small changes, and the protocol requires precise bitbanging

You could use the newer AM2320, which works with I2C protocols instead, and costs even less than a DHT22. I2C is much more reliable on all processors

[Salty-Doug]

Thanks captainju, I used the DHTstable library on my ESP32 and I am not seeing anymore "nan" readings.

[VikIborra]

I think that the problem is in the Chip.
Last days I've received from China models of DHT22 with Chip ASAIR and is not 100% compatible. AOSONG is very good but ASAIR has problems.

[robcazzaro]

Try a different library, and you'll see it works. This library has a known bug and it's too timing dependent for modern IoT boards with different processors. It worked fine as long as everyone used the slow, original Arduino. You might also have a bad chip, but in my case (and many others) using a different library or patching the code bug solved the problem easily. It's not a chip problem

[VikIborra]

With Wemos D1 Mini (v2.0, 2.2, 2.3, 3.0) doesn't work.
I've tried with diferent resistors, voltage (3.3/5), shield pro (dht22), ... only when I use AOSONG in same PCB Shield Pro received with ASAIR, works. I desolder ASAIR and I put AOSONG.
I have tried all libraries in platformio.
Same PCB with Arduino UNO, works but not in Wemos D1 Mini.
70% of ASAIR, fails by time out.
I have changed "const int DHTLIB_TIMEOUT" in dht.h but nothing result.
Thanks in advance.

[robcazzaro]

Have you tried commenting out the two lines 155-6 (and recompiling the library), as explained above in this thread? And possibly changing the delay from 10 to 50.

Without those changes, not even a DHT22 worked for me

In any case, the newer AM2320 is a much better choice these days :) or for overkill, a BME20, which also measures pressure