DHT11 or DHT22 returns NaN: wiring, pull-up and read interval

NaN means the library could not read a valid reading from the sensor. Check the wiring and pull-up first, then do not read too often.

What the message means

The DHT sensors use one data wire and need a pull-up resistor. The library times short pulses; if the signal is missing or noisy, it returns NaN. The sensors also need time between readings.

Fix it in this order

1. Check power, ground and data. Many bare sensors need a 4.7 to 10 kohm pull-up on the data pin; modules often have one.
2. Use the pin number you pass to the library, and the right type (DHT11 or DHT22).
3. Wait between reads: about 1 second for DHT11 and 2 seconds for DHT22.
4. On an ESP32 avoid reading in a time-critical interrupt or while heavy tasks run.
5. Use short wires. Long cables add noise and need a stronger pull-up.
6. Try a second sensor. A damaged sensor reads NaN forever.

Why it happens

The sensor sends its reading as a train of very short pulses, and the library measures their timing. If a pulse is missing or late, because of wiring, a missing pull-up, noise or a busy processor, the library cannot complete the read and reports NaN.

The sensor also needs time between reads. Spec listings give a sampling period of one second for the DHT11 and two seconds for the DHT22, and Adafruit’s DHT22 example waits 2000 ms in its loop. These listings come from tutorial and vendor pages rather than the official datasheets, so check the datasheet for your part. If an older DHT library is installed next to the Adafruit one, the IDE can pick the wrong header, so keep one library.

If you see this, do this

Related

DS18B20 reads -127, IR sensor with Arduino.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

The DHT sensors use one wire for a timed exchange. The controller pulls the line low for at least 18 ms to say start, releases it, and the sensor replies with a short acknowledge followed by 40 bits. Each bit is a pulse whose length encodes 0 or 1: a high of about 26 to 28 microseconds is a 0 and about 70 is a 1. The library measures those pulses, rebuilds five bytes and checks the last byte, the checksum.

If a pulse is lost, late or distorted by noise, a busy interrupt, or a missing pull-up, the checksum fails or the timing times out, and the library returns NaN. The sensor also needs rest between readings; asking again too soon gives the same failure.

How to confirm the cause

• Check the wiring: supply, data and ground in the right order for your module, with a pull-up on the data line for a bare sensor.
• Print the result of both readHumidity() and readTemperature(), and test with isnan(). If only one fails, check the library version.
• Add a delay of at least two seconds between reads and see if the failures stop.
• Check the sensor type in the DHT constructor. DHT11 and DHT22 are decoded differently.
• Test with shorter wires and with the supply measured at the sensor.

Worked example

A reading loop with a failure check, followed by how the five bytes of a DHT22 reading are decoded:

#include <DHT.h>
DHT dht(4, DHT22);

void setup() { Serial.begin(115200); dht.begin(); }

void loop() {
  delay(2000);
  float h = dht.readHumidity(), t = dht.readTemperature();
  if (isnan(h) || isnan(t)) { Serial.println("read failed"); return; }
  Serial.printf("%.1f %%  %.1f C\n", h, t);
}
// Bytes 02 8C 01 5F EE: humidity 0x028C = 652 -> 65.2 percent
// temperature 0x015F = 351 -> 35.1 C
// checksum 02+8C+01+5F = 0xEE, matches the last byte

Common mistakes

• Using a DHT11 setting on a DHT22 or the other way round.
• Calling read functions faster than the sensor’s sampling period.
• Leaving out the pull-up on a bare four-pin sensor.
• Powering the sensor from a pin that droops when other parts switch on.
• Using printf-style formatting on a board whose Serial lacks printf support.

If this did not fix it

• Another DHT library installed alongside, so the compiler uses the wrong header.
• Interrupt-heavy code that disturbs the timing; read the sensor at a quiet moment.
• A damaged or counterfeit sensor; try another.