Which platform do you use ?
This bug influence quality of reading ,?
You speak about last build ?

Sent from my iPhone

On 01 dic 2015, at 21:32, W-E notifications@github.com wrote:

Dear all,
there is an mistake in your DHT11 init sequence. Admittedly, the DHT11 datasheet is not very clear here. Anyhow, after you pulled the data line low for the at least 18 milliseconds to signal the DHT11 a start, you should NOT actively pull it up. As soon as the DHT does see the low-high transition on the data line ( Well "as soon is around 12 usec later ) it tries to pull it down. If the data line is still held "high" by the uC at that time, you have more or less a short circuit on the data line with the uC pulling up and the DHT pulling down.
This can clearly be seen on an oscilloscope if your lib is used "as is".

You need to change the uC pin state to "INPUT" after the initial >18 msec LOW phase right away, without actively pulling up before.

Luckily this bugfix is as easy as commenting out two lines, see below:

// End the start signal by setting data line high for 40 microseconds.
// digitalWrite(_pin, HIGH);
// delayMicroseconds(40);
// WEB: This is an error. DHT tries to pull the line low as soon as it came back to high.
// therefore the low-high transition after the start signal "low" needs to be realised by
// the pullup resistor only, uC pin must already be in INPUT mode.

See attached before-after scope screenshots

before: (your lib as-is )

after, with fixed startup sequence:

With best regards,
Wolfgang Ebersbach

—
Reply to this email directly or view it on GitHub.

Hi asetyde,
I do use ESP8266 with the arduino ESP package, Arduino V1.6.5 but that does not matter. The code is just wrong. DHT11 tries to pull the data line low as soon as it went up after the >18msec LOW phase. This is not uC related but DHT11 related. The issue likely came from the unclear wording in the DHT11 datasheet.
Anyhow, as soon as you end the >18msec LOW phase, the uC pin has to go to INPUT or HIGH-Z (high-z does not exist in Arduino).
Wolfgang

Oh, and yes, it DOES influence the quality of the readings. At least if connected to the ESP8266 GPIO #2, the original lib returned "NAN" about every 10th read. The modified lib now performed around 50.000 reads with zero errors ( I added success/fail counters to the code ).
Even if it would not change the readings: Do not drive one physical line with two output drivers at the same time. You just don't.
Wolfgang

I ask to you because my nodemcu sometime it block itself and I don't know why , I try to restore library to 1.1.1 but i don't know how can I do .. I can not records with ide many hours of serial .. But block it showed in MySQL table .. Often after 3h or 7h many times, tomorrow I try to cut sensor and isolate issue , but if it dht ? I change many sensor but it mustn't block device !

Sent from my iPhone

On 04 dic 2015, at 22:29, W-E notifications@github.com wrote:

Oh, and yes, it DOES influence the quality of the readings. At least if connected to the ESP8266 GPIO #2, the original lib returned "NAN" about every 10th read. The modified lib now performed around 50.000 reads with zero errors ( I added success/fail counters to the code ).
Even if it would not change the readings: Do not drive one physical line with two output drivers at the same time. You just don't.
Wolfgang

—
Reply to this email directly or view it on GitHub.

Hi Wolfgang,

Thank you for posting this fix together with detailed test results including sexy waveforms 😄 👍

I am writing a tutorial on automatic humidity control using ESP8266 and after longer testing discovered similar issue. I like to use adafruit library as it is slick and mature, very well commented in code and available for installation right out of Arduino IDE. For these reasons I was reluctant to replace it and started searching for issue reports and luckily found your post!

I was observing random DHT22 / AM2302 read failures using this library together with Arduino Due and now with ESP8266. I do not observe so big failure rate like you, but still see one nan / Failed to read from DHT sensor! per couple of dozen measurements. I guess the actual failure rate may depend on value of pull up resistor, power supply quality or on particular sensors itself that I am using.

Anyway, after applying your fix the issue vanished 💨

Thank you again for contribution of this fix 👍

Krzysztof

Dear Krzysztof,

welcome.
I use Arduino if I have a small non-professional project that I need to slap together in no time. This is because I discovered that many Arduino libraries have a poor quality, including the "official integrated" ones like the LCD lib.
The Arduino IDE / toolchain also is not super reliable. E.g. the LCD lib does output different bitstreams to the connected LCD depending on if it is compiled with the OSX version of the toolchain or the windows version. I did not take the time to track down if it's the compiler or some compiler options or the library itself.
Many libs have poor or no error checking, are not protected against buffer overflows and so on.

Just as a rule of thumb: If you do something that later "goes public as a product" either do not use Arduino or check any used library for mistakes.

To bring that above complaining to the right perspective: I think the Arduino project is GREAT. They found the right balance between hiding hardware ( register ) complexitivity and making things too simplified ( and therefor to much constrained ). I also like the business model of financing this entire thing with sold hardware. So, yes I like Arduino. No, I do not recommend it for professional product development. I mostly like that there is plenty of overall good documentation.

Regards,
Wolfgang

Am 20.12.2015 um 12:07 schrieb krzychb:

Hi Wolfgang,

Thank you for posting this fix together with detailed test results including sexy waveforms

I am writing a tutorial on automatic humidity control using ESP8266 and after longer testing discovered similar issue. I like to use adafruit library as it is slick and mature, very well commented in code and available for installation right out of Arduino IDE. For these reasons I was reluctant to replace it and started searching for issue reports and luckily found your post!

I was observing random DHT22 / AM2302 read failures using this library together with Arduino Due and now with ESP8266. I do not observe so big failure rate like you, but still see one nan / Failed to read from DHT sensor! per couple of dozen measurements. I guess the actual failure rate may depend on value of pull up resistor, power supply quality or on particular sensors itself that I am using.

Anyway, after applying your fix the issue vanished

Thank you again for contribution of this fix

Krzysztof

�
Reply to this email directly or view it on GitHub.

I agree with W-E, the MCU should never make the pin output and high. After investigating most known DHT datasheets, I think it is obvious that it will cause a "more or less" shortcut between the MCU and the microcontroller inside the DHT. Thank you for the pictures of that shortcut W-E.
At this moment a forum topic is about that : http://forum.arduino.cc/index.php?topic=377413.0

Thank you Wolfgang for posting this fix. After following your advice to add the pull up resistor and comment out the 2 lines, I am getting much cleaner reads from the DHT-11.

I was able to reproduce your before and after scope screenshots with my ESP8266 and DHT-11. This really needs to get into the main library. In the mean time I have made the changes in my fork.

Thanks again,
Gregg

Thanx @W-E , before this modification I couldn't get good reading most of the time. After fix it works noticeable better but sill get Failed to read from DHT sensor! every 5-10 readings.

What pull up resistor do you use? Do you use third parameter in DHT dht(DHTPIN, DHTTYPE);

Hi Renno,

I did use 4k7 pullup. I believe ( I do not have the code here now ) that
the DHT lib documentation says there are three parameters: DHTPIN,
DHTTYPE , TIMING where Timing is a value that influences the DHT bus
timing and should be set to 11 at the ESP.
At the other hand, if you look into the lib, it seems the lib now
calculates it's own timing, so this third parameter seems to be obsolete.

Oh, I just looked at Github and now the example is adapted:

// Initialize DHT sensor.
// Note that older versions of this library took an optional third
parameter to
// tweak the timings for faster processors. This parameter is no longer
needed
// as the current DHT reading algorithm adjusts itself to work on faster
procs.
DHT dht(DHTPIN, DHTTYPE);

So, no, no additional parameter.

Regards,
Wolfgang

Am 16.02.2016 um 14:05 schrieb renno-bih:

Thanx @W-E https://github.com/W-E , before this modification I
couldn't get good reading most of the time. After fix it works
noticeable better but sill get |Failed to read from DHT sensor!| every
5-10 readings.

What pull up resistor do you use? Do you use third parameter in |DHT
dht(DHTPIN, DHTTYPE);|

—
Reply to this email directly or view it on GitHub
#48 (comment).

I tried with 4k3 resistor and without third parameter but still can see lot of bad readings. ( I read 2147483647 value every 5-10 readings.)
Only way to deal with this is to reject all readings that contain that value.

Also tried another DHT11 sensor and DHT22 sensor, both give some false readings.
It only happens with my ESP12-E module, with Arduino Uno it always show good values.
If sensor is not faulty there must be something to do with ESP8266.

@renno-bih,
Do you see false readings on bare example sketch?
Krzysztof

Yes, here are some readings:

Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 37.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 22.32 *C 72.18 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 23.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.96 *C 71.52 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 34.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 22.24 *C 72.04 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 18.00 %   Temperature: 29.00 *C 84.20 *F  Heat index: 27.42 *C 81.35 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Failed to read from DHT sensor!
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F
Humidity: 21.00 %   Temperature: 23.00 *C 73.40 *F  Heat index: 21.90 *C 71.43 *F

Hi renno-bih,
This looks like h/w issue with your ESP module, weak power supply, long wires, loose connections, etc.
Here is a project with ESP12-E and DHT-22 / AM2302 that works without any issues.
Do you use exactly the same sensor as presented on this project?
Krzysztof

Looks like I found solution.
I was using esp8266 core version: 1.6.5-947-g39819f0...
After upgrading to 2.0.0 I cannot see false readings anymore.

2.1.0 best choice in staging

ElectricLabs

Develop & Research
Alexandro Todeschini
+393351881688
alexandro.todeschini@electriclabs.it mailto:alexcandro.todeschini@electriclabs.it

alexandro.todeschini87@gmail.com

Verona (Italy)
Skype : ElectricLabs
www.electriclabs.it http://www.electriclabs.it/

INFORMAZIONE RISERVATA - Le informazioni contenute in questo messaggio e in qualsiasi documento a esso allegato sono confidenziali, potrebbero essere riservate e possono essere utilizzate solo dal destinatario designato. Se Lei non è il destinatario qualsiasi copia, trasmissione, divulgazione o azione basata su tali informazioni è assolutamente vietata ed è proibita sia ai sensi dell'art. 616 c.p. sia ai sensi della vigente Legge sulla privacy dei dati. Se questo messaggio è stato ricevuto per errore, La preghiamo cortesemente di darcene comunicazione via e-mail e quindi di procedere alla cancellazione di questo messaggio e all'eliminazione di ogni sua copia.
WARNING NOTICE - The information contained in this communication and any documents transmitted with it are confidential, may be privileged and are intended solely for the use of the intended recipient. If you are not the addressee any copying, retransmission, distribution, action taken, or omitted to be taken in reliance upon it is strictly prohibited and is forbidden according to article 616 c.p. Italian Law and to current Italian Privacy Law. If you have received this communication in error please notify us immediately by e-mail and delete it from your system and destroy any copies of it.

Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
Please respect Nature, not print this email .

On 17 feb 2016, at 11:58, renno-bih notifications@github.com wrote:

Looks like I found solution.
I was using esp8266 core version: 1.6.5-947-g39819f0...
After upgrading to 2.0.0 I cannot see false readings anymore.

—
Reply to this email directly or view it on GitHub #48 (comment).

2.1.0 work flawlessly.

2.0.0 has memory leak memory bug . i’m using 2.1.0 rc1 work good

On 17 feb 2016, at 12:29, renno-bih notifications@github.com wrote:

2.1.0 work flawlessly.

—
Reply to this email directly or view it on GitHub #48 (comment).

Hello everybody, I think that the initial solution is probably not fully correct. The original waveforms indicate that the timing is the same, so besides commenting out the first two lines, we should also increase the second delay after pull-up to 50 us:

    //digitalWrite(_pin, HIGH);
    //delayMicroseconds(40);
    // Now start reading the data line to get the value from the DHT sensor.
    pinMode(_pin, INPUT_PULLUP);
    delayMicroseconds(50);  // Delay a bit to let sensor pull data line low. - adjusted from 10 us

In this code, the expectPulse will take care of this in most cases, however some timeouts may occur because of this (maybe it is the problem @renno-bih mentions) and when modifying the derived code (NodeMCU, ESP Easy) the unadjusted timing leads to reading of incorrect values.

With 50us delay I couldn't get any data from DHT11

@W-E Thanks a lot your fix worked really well for DHT11.
However I've just tested your fix with a DHT22 and I'm facing the same constant failures when reading.

Do have any ideas why that happens?

Thanks.

A native chinese speaker read the datasheets : http://forum.arduino.cc/index.php?topic=377413.msg2699553#msg2699553
In the past the DTH11 datasheet says that is was also possible to set the bus high. But that was only for the DHT11, and it was only in an old datasheet. Perhaps it was possible for the DHT11 in the past, perhaps it was a mistake in the datasheet.

I was having fits with an AM2302and the ESP8266; I implemented the changes by pm-cz abd everything is working great. I think it worked for AVR chips more or less by accident, because the protocol is quite clear and the library code does not implement it correctly. Surprised Adafruit hasn't fixed it.

I've been trying to get this library to work for weeks without success. This fix worked for me. I figured using the latest library provided by the Library Manager in the Arduino IDE was a safe bet. Lesson learned! Why on earth hasn't this fix been applied? It was suggested over 12 months ago! So frustrating!

I also had invalid readings and thought it was a problem of my sensor. I agree it should have been fixed, a lot of people trust Adafruit with their hardware/software and the solution is over a year old. Please Adafruit, implement the changes suggested by W-E and pm-cz!

with W-E 's solution, I never met any reading errors any more.

WOW this works, I have been dealing with this for a long time, trying to figure out where this noise is coming from, neopixels seems to exacerbate the problem, but this fixed it, makes no sense, no scope here to test.

The recent version of the library 1.3.0 (available through Library Manager in Arduino IDE) still has no fix for this issue...
Any chances the fix will soon be applied to the master branch?

My case

I had occasional problems with reading data from DHT (DHT11 or DHT22) which IMO were somehow related to using PubSubClient or ESP8266HTTPClient on NodeMCU V3 or WeMos D1 R2.
With the fix like removing (or commenting) out two mentioned lines DHT.cpp inside boolean DHT::read(bool force) the rate of NAN-readings has dropped almost to zero :)

Thank you @W-E - I thought I had a bad sensor, but your work has fixed this. I hope Adafruit integrate this fix soon.

Been fighting with read errors for two days... @pm-cz suggested change seems to have eliminated every read error I was getting...

Before the "fix" I was getting a 20-25% error rate on my readings when running pubsubclient "client.publish" commands...

Now I'm getting 0% error rates running at full tilt...

Thanks @W-E and @pm-cz !! :)

Since this issue seems to have been around for two years now, i'm not really holding my breath on an official fix any time soon.

Yeah, had a same issue, but the fix worked by @W-E and @pm-cz, anyway I think Adafruit just don't care, they are to bussy whit those 3D printers! :D

Hi,
I would like to thank @W-E very much for his solution! My DHT22s recently arrived and, eager to see how easy it is to use them, I set up a simple data logging to a web page with WeMos D1 mini and noticed the "nan" error occuring once to thrice every twenty reads. Google pointed me here and in a blink of an eye, the problem has been solved by commenting out the two mentioned lines in a library. Now I have over a thousand of flawless readings. :-)

Thank You! :-)

Try newest library - reopen if still an issue.

@W-E what sensors do you use now?

use sht21 or sht2x family