Interfacing DHT11 & DHT22 Temperature and Humidity Sensors with ESP32

This guide connects a DHT11 or DHT22 to an ESP32 and takes it from Serial Monitor readings to four Wi-Fi projects: a live web page, a JSON endpoint for Node-RED or Home Assistant, a chart of the last hour on your phone, and a battery-powered outdoor sensor that deep-sleeps between readings. One line, DHTTYPE, selects the sensor. The ESP32 is a 3.3 V board, so there is one wiring rule the Uno guide does not have: power the sensor from 3V3, never from 5V.

Which GPIO? GPIO 4 is a safe default. Avoid:

• GPIO 34 to 39 - input-only. The DHT protocol needs the pin to drive the line low for the start signal.
• GPIO 6 to 11 - wired to the module's flash chip. Using them crashes the board.
• GPIO 0, 2, 12 and 15 - strapping pins read at boot. A pull-up on them can stop the board booting or uploading.

Good alternatives are GPIO 13, 14, 16, 17, 25, 26, 27 and 32.

Install the library and the board

Sketch 1 - Read temperature and humidity

The same sketch as on the Uno, with two changes: the data pin is GPIO 4, and the Serial Monitor runs at 115200 baud, which is the ESP32 default.

A DHT22 shows real tenths; a DHT22 that only ever shows .0 is usually still set to DHTTYPE DHT11. Breathe on the sensor and watch humidity rise. If you see an occasional Failed to read, that is normal on the ESP32: Wi-Fi and the second core can interrupt the microsecond timing. The sketch simply retries on the next loop. If every read fails, check the wiring table and the GPIO list above.

Sketch 2 - A live web page over Wi-Fi

This is where the ESP32 earns its place. The sketch joins your Wi-Fi, reads the sensor every two seconds in the background, and serves a small page that refreshes itself every five seconds. Open the IP address it prints from any phone or laptop on the same network.

How it works. updateReading() uses a millis() timer instead of delay(), so the ESP32 keeps answering web requests while it waits between sensor reads. A failed read keeps the previous good value, so a single bad frame never shows up on the page. From here it is a small step to publish the same numbers over MQTT to Home Assistant or Node-RED.

Add a JSON endpoint for Node-RED, Home Assistant or a script

A web page is for people. Software prefers JSON. Add this handler to Sketch 2 and register it next to the page, and any tool on your network can poll http://<ESP32-IP>/json:

Opening it in a browser shows something like {"temperature_c":24.0,"humidity":55.0,"age_ms":1312}. The age_ms field tells the client how old the reading is, so a stalled sensor is easy to spot, and the 503 status before the first good read lets a client tell "no data yet" from a real 0 °C. To have the ESP32 push readings instead of being polled, see ESP32 MQTT temperature sensor for Home Assistant or the Node-RED ESP32 dashboard.

Sketch 3 - A live chart of the last hour

A single number tells you what the air is doing now. A chart tells you what it has been doing: whether the room is still warming up, how fast an open window cools it, how long a shower's humidity lingers. The ESP32 keeps the last 120 readings (one every 30 seconds, so one hour) in memory, serves them as JSON on /data, and the page draws them as two small charts that refresh every 30 seconds. No cloud account or extra library is needed. A DHT22 draws smooth curves; a DHT11 draws steps of a whole degree.

How it works. sample() stores a reading every 30 seconds in two ring buffers, overwriting the oldest once 120 are stored, so memory use never grows. /data returns them oldest first, and the page's JavaScript scales each series to its own minimum and maximum, so even a 0.3 °C drift is visible. The chart starts empty after a reset; for days of history, push readings to a database such as InfluxDB and Grafana via Node-RED, or stream them with WebSockets.

Sketch 4 - Battery outdoor sensor with deep sleep (DHT22)

Outdoors, the DHT22's −40 °C floor finally matters (a DHT11 stops at 0 °C), but a board running Wi-Fi all day empties a battery in hours. This sketch does the job in a few seconds per wake-up: power the sensor, wait for it to settle, read with retries, remember the day's minimum and maximum in RTC memory, then deep-sleep for 10 minutes.

The sensor's VCC comes from GPIO 25 instead of 3V3, so it draws nothing while the ESP32 sleeps. A DHT22 needs about 1.5 mA, well within what a GPIO can supply.

What battery life to expect. The ESP32 chip sleeps at about 10 µA, but a typical DevKit board draws several milliamps asleep because of its USB-serial chip, LED and voltage regulator. On a DevKit, an 18650 cell lasts days to a couple of weeks; on a bare module or a low-power board with an efficient regulator, the same code can run for months. The ESP32 deep sleep battery life guide shows how to estimate it.

Mounting outdoors. Sun on the plastic grille can make it read 10 °C high, and rain kills the sensor. Mount it in a radiation shield (stacked white plates, open at the sides), about 1.5 m above grass and away from walls. Keep the ESP32 and battery below the sensor or outside the shield, so their warmth does not rise into it.

Troubleshooting on the ESP32

ESP32 FAQ

Can I use the DHTesp library instead? Yes. DHTesp by beegee_tokyo is written for the ESP32 and ESP8266 and handles both sensors; some people find it more reliable with Wi-Fi active. The wiring is identical; only the code changes.

Does this work on the ESP32-C3 or ESP32-S3? Yes. Pick a free GPIO that is not a strapping or flash pin on your board, update DHTPIN, and select the right board in the IDE.

Can I run it on a battery? Yes: Sketch 4 is built for it. Power the sensor from a GPIO so it sleeps too, and choose a board with a low sleep current.

Can I use MicroPython instead of Arduino? Yes. MicroPython's built-in dht module reads either sensor in a few lines; see DHT11 and DHT22 with MicroPython.

Why not power it from 5 V for longer cables? Because the pull-up would then raise the data line to 5 V. If you need a long cable, use the bare sensor with its pull-up to 3.3 V, or a small level shifter.