Home / IoT, Sensors & ESP32 / DHT22 with ESP32: Accurate Temperature and Humidity

DHT22 with ESP32: Accurate Temperature and Humidity

IoT, Sensors & ESP32 ✍ Oliver Adam ⏱ 6 min read August 9, 2026

The DHT22 reports temperature and humidity over a quirky single-wire protocol every two seconds. It is cheap, cheerful and everywhere and it works flawlessly on ESP32 once you respect its timing and pull-up requirements.
> At a glance: 6 minute guide · part 6 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.

## Wiring and pull-ups

VCC to 3. 3 V, GND to GND, DATA to a chosen GPIO with a 10 kΩ pull-up to 3. 3 V (many breakout modules carry one). Long cable runs degrade the single-wire timing keep it short or move to I²C sensors like the BME280 for distance.

| P | r | o | p | e | r | t | y | | | | | | | | |
| — | — | — | — | — | — | — | — | — | — | — | — | — | — | — | — |
| D | H | T | 2 | 2 | | | | | | | | | | | |
| B | M | E | 2 | 8 | 0 | | ( | u | p | g | r | a | d | e | ) |
| Interface | 1-wire timing | I²C | | | | | | | | | | | | | |
| Minimum read interval | 2 s | Continuous | | | | | | | | | | | | | |
| Accuracy | ±0.5 °C / ±2–5 %RH | ±0.5 °C / ±3 %RH | | | | | | | | | | | | | |
| Extra outputs | | Pressure | Cost | Low | Moderate | | | | | | | | | | |

## Reading rules

The sensor needs ≥2 s between reads; faster polling returns cached or NaN values. The Adafruit library handles the protocol; read with a null check and retry logic, because one missed bit checksums the whole packet out.

## Accuracy expectations and checks

±0. 5 °C and ±2–5 %RH are realistic, with humidity drifting over years of service. Sanity-check two sensors side by side; a 2 °C permanent offset deserves calibration constants, not guesswork. For serious logging, step up to SHT31 or BME280.

## How to apply this in your build

Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Wire with the 10 kΩ pull-up on the data line
2. Wait two seconds between reads
3. Check for NaN returns and retry once
4. Validate two sensors side by side before trusting either

### Worked example

A greenhouse monitor polled every 500 ms and logged NaNs hourly. Moving to a 2. 5 s cadence with a single retry produced a month of gap-free data from the same hardware. Run the numbers yourself with the related calculator and the result should agree to within rounding.

> Practical note from the bench. Every climate build we publish states sensor accuracy honestly ±0. 5 °C is plenty for comfort control, marginal for scientific logging.

## Pitfalls that cost real hardware

– Polling faster than the 2 s protocol allows
– Leaving the pull-up off on a bare sensor
– Trusting absolute humidity values that were never calibrated

## Key takeaways

Wiring and pull-ups the foundation of this guide; revisit it if any measurement here surprises you.
Reading rules the foundation of this guide; revisit it if any measurement here surprises you.
Accuracy expectations and checks the foundation of this guide; revisit it if any measurement here surprises you.

## Prerequisites and preparation

Before starting: wire with the 10 kω pull-up on the data line and wait two seconds between reads. Keep a calculator to hand every number in the worked example is reproducible. Total time including the bench steps: about 6–6 minutes.

## Who benefits most

Hobbyists meeting this topic for the first time, students who want the version with real numbers instead of abstract symbols, and returning engineers refreshing a corner of the craft. The mistake list alone justifies the visit every entry in it was learned the expensive way.

### Quick reference card

| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Wiring and pull-ups |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Pitfalls that cost real hardware |

## How this fits the complete IoT and ESP32 guide track

This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [ultrasonic distance sensing](/tutorial/hc-sr04-ultrasonic-esp32) and [ESP32 starter guide](/tutorial/esp32-getting-started).

## Frequently asked questions

DHT11 or DHT22?
DHT22 costs a little more for half the temperature error and better humidity range worth it for anything you log.

Why do I get NaN occasionally?
A checksum failure read too soon, marginal wiring, or missing pull-up. Retry logic is standard practice.

Where do I go next?
Back to the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page it indexes every guide in this track and updates as new ones are published.

## Continue this track

– Building a foundation? The [iot, sensors & esp32 complete guide](/tutorial/iot-esp32-complete-guide) maps every step in order.
– Next: [ESP32 vs Raspberry Pi 5: Which is Best for Your Project? 2026 Guide](/tutorial/esp32-vs-raspberry-pi)
– Next: [5G Architecture Explained: What Actually Changed](/tutorial/5g-architecture-explained)
– Next: [Gyroscope Sensor Explained: Working, Arduino & Uses](/tutorial/gyroscope-sensor)
– Work the numbers: [battery life estimator](/tools/battery-life) · [LM317 designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)

## Verification routine

Component substitution is a legitimate experiment as long as it is deliberate. Swap one part, predict the effect, measure, and record. That single habit converts a parts bin into a teaching lab and makes every future guide in this track faster to absorb.

The fastest way to internalise this topic is to change one variable deliberately and predict the result before measuring. Wrong predictions are the curriculum, they show exactly which mental model needs revisiting, and the bench grades honestly.
## Formulas and checks from this guide

Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts, and confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.

Bookmark this page against your next build in the track: the checklist above is the same one used across 23 guides in this series.

## Notes from the bench

Location, then device, then measurement. Document the tree before flashing the first device.

Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.

## How to revisit this guide

Second readings work best with a purpose. Pick one section from Wiring and pull-ups,Reading rules,Accuracy expectations and checks and rebuild only that part at the bench, predicting each value before measuring. Prediction errors mark exactly which concept needs the next pass, and the linked iot calculators resolve any arithmetic doubt in seconds. Keep the marked sections in your notebook: after a month of builds, that list becomes your personal IoT syllabus.