Just want to share an interesting observation of DHT22 behaviour. I am using it in a temperature monitoring project (with ESP8266, but this does not matter), it is constantly powered +3.3V and I am reading temperature once a minute. After roughly 1 day of uptime I noticed that sensor data became fuzzy, it returns values which differ by 1-2°C on each reading.
I unplugged the sensor from power and plugged it in again (without rebooting ESP8266) – and sensor readings became smooth again. As I am sending this data to a cloud, it could be easily seen on a picture:
Is this is a known behaviour of DHT22 and are there any ways to fix it? Probably I should avoid constant powering of the sensor and turn it on only for measurements?
Thats very strange.. Can the problem also be solved by rebooting the ESP8266? Although you would expect if its a communications error rather than a measurement error you would get completely random variations rather than almost right values.
When someone asks a question and tells that certain things can not be the cause... then that is the first subject to look at.
Is the ESP8266 requiring too much current, that makes the DHT22 reset ?
The temperature of the DHT22 should be stable, either when it is constantly powered, or only powered when measuring.
Did you know that the values returned by the DTH22, are the values that are sampled when the previous values were requested ?
Therefor, if you read the values once a minute, you get the temperature of 1 minute ago.
Perhaps the DHT22 is reset by the ESP8266 and the first delay is not enough. Or there is not enough delay anyway. I think when the DHT22 does not get enough delay, the values become inaccurate.
Which library do you use ?
Is the DHT22 near something that gets warm now and then, like the ESP8266 ?
Koepel:
When someone asks a question and tells that certain things can not be the cause... then that is the first subject to look at.
I knew someone would say this!
Is the ESP8266 requiring too much current, that makes the DHT22 reset ?
Well, this might be related to a current issues, but the strange thing is that this bug appears only after few days of operation.
Since my initial post I observed it a couple of times. One time I tried to reset the MCU (ESP8266), but both soft-reset and hard-reset did not help. But again, when I disconnected DHT22 and connected it again (without rebooting the whole set) – it started working properly.
Anyway, if it was a checksum problem, it is likely that higher bits would be "damaged" with same probability as lower bits, so the reading would be more random. In my case it just fluctuates around current temperature.
The DTH22 starts sending the highest bit first. The humidity first and then the temperature followed by checksum byte. If something is out of tune, then the lowest bits of the temperature could be wrong, and the checksum at the end is of course the most likely to go wrong.
An other option is that the data is requested to quick after the previous request.
The picture with the temperature might show wrong lower bits for the temperature (that is the feeling I get when looking at the picture).
Perhaps the checksum passes the test sometimes.
Could you make two variables, one increments for 'dht.OK' and the other counts the misses. What percentage of the requests do fail ? If it is 0...10%, that's fine.
How often is the data requested ? The "next_temp" is zero, but it should at least be 2 seconds. Start with 5 seconds interval.
The sensor could be broken: it happens, but not very likely.
You request the data too fast: that might be the problem.
The timing goes wrong and it passes the checksum test: possible.
Something wrong with decoupling or the voltage or ground current: maybe
Koepel:
The DTH22 starts sending the highest bit first. The humidity first and then the temperature followed by checksum byte. If something is out of tune, then the lowest bits of the temperature could be wrong, and the checksum at the end is of course the most likely to go wrong.
That is a great idea, thank you! I should have examined return codes thoroughly. I've added counters for correct readings and errors (consequent and total) and dump this values to ThingSpeak every 30 seconds.
Yesterday I noticed same issue again. It does not look like it is related to data transfer issues, because checksum is correct.
Here is a temperature chart from DHT22 and temperature readings from BMP180 (collected on the same device at the same time)
At the same time there were no single failure of a checksum for DHT22 (any failure would reset dht_oks counter to zero)
So I would assume it is a internal issue of DHT22, probably failure of my item. I have another DHT22 sensor from the same supplier, will try to swap it and look what happens.
MarkT:
You have a 100nF decoupling capacitor on the sensor power don't you?
No, I hadn't. Datasheet says it optional and I use stabilized power source, so I didn't bother. But thanks for the idea, I added 100nF decoupling capacitor. On the first try I powered it up with the capacitor, it started getting this semi-random values just in a few seconds. I restarted it once again, so far it forks well, will take a look during next few days.
MarkT:
You have a 100nF decoupling capacitor on the sensor power don't you?
I don't believe that the reason is a missing capacitor. Here we have a change in the behaviour. A missing capacitor will have disturbed all measures.
I don't have capacitor too and the measures are comparable to a DS18B20.
Not yet, because I was still observing this one. As expected, adding a capacitor did not help.
But more observation on the same sensor shows even more unexpected results. Periods of "strange behaviour" happens randomly in time . The duration of the "strange behaviour" varies from 1 hour to 5+ hours, after which data returns to normal reading. The deviation is usually ±1-4 Celsius and is always symmetrical – i.e. it returns random values, which are 1 to 4 degrees lower and higher than the real temperature.
The strangest thing: sometimes these "strange periods" coincides with checksum errors (when lot of readings end with checksum error), and sometimes not!
I'm having exactly the same behavior. Did you manage to find a solution?
I'm using a DHT22 connected to an esp-8266 through a 3m cable. Before that, I was using the same device with same cable on arduino and worked fine for months.
Since, I replaced the arduino by the esp-8266, I'm getting errors after a few hours.
I tried:
power the DHT22 with 5V instead of 3v3 -> no changes
adding a 100nF capacitor near device -> no changes
The soft reset doesn't solve the issue, I have to disconnect and reconnect the DHT22 to resume. Exactly what you describe.
I think that the DHT11 should not be connect on +5V in a permanent way. I had it connected on 5V in the past and had humidity data off (low) by about 10%.
Now I use one of the digital output of the Arduino to supply it with 5V for 1 or 2 seconds every 20 seconds. Results are now more constants and higher by 10% (for 2 units)!
Note: the resistor between pin 1 and 2 is also connect to the output.
duino_nano:
I think that the DHT11 should not be connect on +5V in a permanent way. I had it connected on 5V in the past and had humidity data off (low) by about 10%.
Now I use one of the digital output of the Arduino to supply it with 5V for 1 or 2 seconds every 20 seconds. Results are now more constants and higher by 10% (for 2 units)!
Note: the resistor between pin 1 and 2 is also connect to the output.
Maybe the problem is the same with DHT22
Maybe is a matter of cabling...I have a DHT11 (similar to DHT22) running in a protoboard for days and her readings are consistent with my shack weather station.
Check your cabling, be sure to keep distance to noise sources in your board or in nearby boards.
vazquezjm:
Were you able to solve the problem with another DHT22? I'm experiencing the same issues you mentioned.
Actually, no. I lazily tried swapping two DHT22's I have over these months, but both behave unreliable. Sometimes they just stop sending data, sometimes they give a huge error, sometimes they are pretty stable and exact.
I can conclude that it is typical for DHT sensors. At the same time, BMP180 that I use in the same setup and couple of DS18B20 show correct temperature and are reliable (they do not measure humidity, though). I also have an I2C humidity sensor SHT21, but I have not tried it yet.
