温湿度センサDHT22の出力NaNエラーへの対応。
opened 08:32PM - 01 Dec 15 UTC
closed 06:00PM - 14 Feb 19 UTC
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
opened 03:00AM - 26 Nov 17 UTC
closed 03:46PM - 28 Nov 18 UTC
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 9d7a9da8ae6cc5f6b6dd5be62d787f779e640a2a (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
DHT-sensor-libraryのDHT.h line156-160の箇所を以下のように修正します。
// End the start signal by setting data line high for 40 microseconds.
//digitalWrite(_pin, HIGH);
//delayMicroseconds(40);
// Now start reading the data line to get the value from the DHT sensor.
pinMode(_pin, INPUT_PULLUP);
delayMicroseconds(10); // Delay a bit to let sensor pull data line low.ここは任意10-50。
センサの動作電圧：3.3-6.0Vであり、3.3V未満になると出力が不安定になります。