DHT sensors/The three limits/07. How often you may ask
The three limits · 07 of 12

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.

How often you may ask
every 500 ms
delay() in your loop500 ms
Which sensor
Real readings
30/min
Calls that did nothing
18
Oldest value shown
1.5 s
Asking faster does not get you a newer number. Inside 2 seconds the library never touches the wire at all — it hands back whatever it got last time, including the last failure. Your loop spins, the sensor sleeps, and the reading on screen can be up to 1.5 seconds old with nothing saying so.

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

The reading never changes

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.

readHumidity and readTemperature both cost a reading, don't they?

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.

Once it fails it keeps failing for a while

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.

Can I force a reading sooner?

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.

Where this goes next

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

Community

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.

Browse Modules and blocks on the forum