How often you may ask
The DHT22 answers once every two seconds and the DHT11 once a second — but Adafruit's library caches for two seconds either way, so a DHT11 read in a tight loop is quietly showing you a number from a moment ago, and a failed read stays failed until the cache expires.
Two floors, not one
Drag the slider to whatever delay your loop has in it.
There are two limits stacked on top of each other, and only one of them is the sensor.
The sensor's own floor. Aosong specifies "no less than 1 second" for the DHT11 and "greater than 2 seconds" for the DHT22. Go under it and the part either declines to answer or answers with a reading it has not finished taking.
The library's cache. MIN_INTERVAL in Adafruit's DHT.cpp is 2000
milliseconds, for every sensor type. A read inside that window never reaches the
wire at all: it returns the last result, decoded from the bytes already in
memory.
So the practical floor is two seconds on both boards, and a DHT11 cannot in fact be read once a second through this library however much its datasheet allows it.
What that buys you
The cache is not a nuisance. It is the reason this works:
float humidity = dht.readHumidity();
float celsius = dht.readTemperature();Two calls, one exchange. The first does the whole 24 or 6 millisecond conversation and stores all five bytes; the second finds the bytes still fresh and just decodes them again. Without the cache those two lines would be two separate readings, the second of which would fail because it came too soon.
What it costs you
It caches failures with the same enthusiasm. A read that timed out stores
"failed", and every call for the next two seconds returns nan without trying
again. One glitch therefore looks like a two-second outage, which is worth
knowing before you go looking for a wiring fault that is not there.
And it makes a stale reading indistinguishable from a fresh one. There is no timestamp, no flag, nothing to ask. If your display updates ten times a second it is showing the same number twenty times over and the reader has no way to tell.
What to do instead
Put the reading on a timer and leave the loop alone:
unsigned long last = 0;
void loop() {
if (millis() - last >= 2000) {
last = millis();
// one reading, here
}
// everything else keeps running
}Two seconds is the right number for both sensors. For a room, ten or thirty is better still — nothing indoors changes measurably in two seconds, and the sensor is slower to catch up than that anyway.
When it does not work
You are almost certainly reading faster than two seconds. Inside that window the library returns the value it already has without touching the wire, so the number is frozen by software rather than by the sensor. Put the read behind a millis() timer.
No — together they cost one. The first call does the exchange and stores all five bytes; the second finds the cache still warm and decodes the stored bytes. That is why the two numbers in a sketch always come from the same instant rather than from two readings two milliseconds apart.
The cache stores failures too. A read that timed out sets the cached result to false, and every call for the next two seconds returns nan without retrying. So a single glitch looks like a two-second outage. Nothing is wrong; wait for the next real attempt.
readTemperature and readHumidity both take a force argument — dht.readTemperature(false, true) skips the cache. Do not use it to poll faster than the sensor allows: the DHT22's own floor is two seconds and going under it gets you failed reads rather than fresh ones.
The sensor is a sponge, not a needle, and where you mount it matters more than how often you read it.
How slowly it catches up →Edit this page — content/books/dht22/how-often-you-may-ask.mdx
Questions about this product
See what other owners have asked, and read their solutions.
This page covers several products. Choose yours to see the right discussions.
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.