DHT-22 Humidity value stability over time

Hi everybody, I'm testing a DHT-22 connected to an ESP-01.

I was testing booth wifi connection (from the basement where is located the pellet burning central) and battery duration (the circuit was powered by 3xAA Ni-MH via 3.3v voltage regulator).

According the follow chart the humidity value (the bottom yellow line) appear to be wrong over time going to 100%, changing the batteries the value come to a "real" value as you can see in the follow little dot)

(the battery life was the contiguous line between 2016-01-13 08:00 to 2016-01-15 14:00 when the stopped to be sent)
Has anyone the same impression?
Is there a way to reset the DHT-22 without shut down the circuit?

Thanks

The long-term stability properties of DHT22 are very good, and most likely have nothing to do with the erratic behavior you are experiencing.

Off the cuff, I'd guess you have a problem in the power supply. First, what exactly is your 3.3V regulator? You do realize that ESP takes a LOT of current when it is transmitting? This might cause a voltage drop if the reg is not beefy enough, which could F up the DHT. Furthermore, DHT is essentially a 5V device. Some specs say that the absolute minimum Vcc is 3.5V, while others state 3.3V. Ergo, try feeding the DHT with a 5V supply (remember to level-shift the data line!) or a 3.3/3.5V reg that can put out like 800mA or something. And wait at least a second after the power-up before you start bothering the DHT.

Also, it would help the debugging to know what and when you are transmitting with the ESP. And what exactly are the red, green, and blue curves in your graph?

And could you please translate this "the battery life was the contiguous line between 2016-01-13 08:00 to 2016-01-15 14:00 when the stopped to be sent" to any language spoken on this planet? Feel free to use Italian (or whatever your native tongue is), Google translate handles the common languages reasonably well nowadays. If I had to venture a guess, I'd reckon you meant that the green line shows the battery voltage, but this does not make any sense, assuming the batteries are not being charged every 12 hours.

Furthermore, the battery regulator output voltage would be more interesting to see than the battery voltage. After all, a normal reg requires the input voltage to be 1-2V higher than the generated output. And what is the scale of the battery 'life' (voltage?) curve? Surely it is not 10...24.

Anyway, my experience is that the temperature sensor of DHT22 is less sensitive to Vcc droop than the humidity part.

First of all thank you for your answer and sorry for my english, I'm just an italian.

As you write the problem is the battery power source, the 3xAA NiMH battery are just enough for some hours after charge, after that time the voltage drop and reading become unstable until the ESP stop sending data.
I made other tests with the same scheme (i just add the resistor between vcc and data pin of the DHT as suggested by other circuits around) and with charged batteries the readings appear to be right (I haven't other instruments to check the values), but while the voltage drop the reading have some peaks up and down more frequently as the voltage decrease.

Regarding the charts: top chart is for temperature and lower for humidity (as you could imagine) the green temperature line come from the DHT-22 sensor like the humidity in lower chart. other temperature lines come from other circuits and sensors (cyan and yellow from two DS18B20 connected to a raspberry and the red from another DS18B20 via ESP-01)

Written like this: "the battery life was the length of contiguous line between 2016-01-13 08:00 to 2016-01-15 14:00 when the data stopped to be sent" is more readable? (sorry )
I'd like tell about the battery life of the ESP-01 powered by that batteries, the ESP was located two floors bottom the access point.

Finally, the program is very basic (:

OK, now I understand a little bit more. But again, what is your 3.3V voltage regulator chip? If, for example, it is the widely used AMS1117, the voltage drop from input to output is typically 1.1V, and 1.3V max. Assuming the worst case scenario, your 3xAA gives 3x1.5=4.5V, but the regulator outputs only 4.5-1.3=3.2V. Ergo, since the minimum Vcc of the DHT is 3.3V, you will not get any meaningful readings AT ALL! Even with a 1.1V voltage drop, you would start with only a 0.1V safety margin even with fresh batteries.

I don't recall what the minimum Vcc of ESP8266 is, but I reckon it is well below 3.3V since it is a real 3.3V device. In any case, your system simply cannot work with a Vcc below 3.3V. If you cannot, or are not willing to measure the battery voltage and the reg output, I recommend you just stack four AA batteries in series to get six Volts to start with (obviously, providing that your reg can handle that).

Some comments about the code:
- You have no extra delays, nor yield(); anywhere. Remember that ESP has to run all the WiFi stuff on the same processor, and problems can arise if you hog all the processor cycles for long periods of time. I personally haven't really pushed the limits, and thus do not know how much and what kind of operations you'd have to use to cause issues. But better safe than sorry, eh?

delta = m_hum - oldHum;
if (abs(delta) > 0.01 ...
sendHumidity(...
- This does not make any sense. The temp resolution is 0.1'C, accuracy +-0.5-1'C, and repeatability +-0.2'C, while the humidity specs are 0.1%RH, +-2%RH, and +-0.3%RH. Ergo, you will send the temp and hum values ALWAYS. I personally do a running average on both, and use 0.2 and 0.5 'delta' values for temp and hum, respectively.

delay(dht.getMinimumSamplingPeriod());
- This should not change. No need to read it more than once. Just use 2000ms or more (DHT22).

Yes, the regulator is the classic AMS1117, and now I put the fourth battery.
While the batteries ara NiMH, at full charge the voltage is 5.66V and after the regulator: 3.29V.
Everything seems work ok from yesterday in the evening, you can view the result here:
http://theit.it/TEST/iot/rawdata.html

I don't knew the yield() command before read it from your comment (thanks again, another time ) so I search it around and, it remember me the DoEvents command of VisualBasic
Anyway my sketch is all you can see in the loop() except the function to send data or setup(), and the loop, while is about 60 seconds, is just a long empty delay.
As I can see in the ESP8266/Arduino code of the delay() implementation there is an esp_yield() call inside.

You are correct (again) about the delta, is useless in this case, is just a piece of code of other test I made before with the same sketch: I tried made multiple (five) reading inside the loop, remove minimum and maximum and take the average, this is why r_temp is copied pointless to m_temp.
I don't paste all the commented lines here, just the one I leave active in the sketch.
I change the DHT library from this:
github.com/markruys/arduino-DHT
to this:
github.com/adafruit/DHT-sensor-library
and now there isn't any dht.getMinimumSamplingPeriod() function available, but this step too is useless, all the loop is just a long delay bigger than the two seconds needed by the DHT.
There is a lot of optimization I can do in it but, at this time I'm a newbie in Arduino and ESP8266 programming, I'm just testing something like a child.

Hello, guys. Thanks for your such nice post to teach us more about that topic.