DHT sensors/Two builds and a check/10. Both sensors side by side
Two builds and a check · 10 of 12

Both sensors side by side

The most useful thing you can do with a box holding three of each is wire one of both and watch them disagree. It takes two pins, one sketch and about thirty milliseconds a loop — and it turns the accuracy figures on the datasheet into a number you can see.

Two pins, two objects

Two sensors, one sketch
Arduino Uno

Two boards, two pins, nothing shared but power and ground. Neither knows the other is there.

Your board
Pins used
2
Loop stopped for
30 ms
Interrupts off
9 ms
Adding a second sensor costs a pin and about 30 ms. There is no bus and no addressing, so the two never interfere — but each read is a blocking conversation your sketch cannot do anything else during, and the forty bits are timed by counting, so the library switches interrupts off while they arrive. Six sensors is six pins and the better part of a tenth of a second, which is fine for a room monitor and not fine inside anything that has to answer a network in the meantime.

There is no bus here, so there is nothing to share and nothing to configure. Two boards, two data pins, two DHT objects, and neither sensor is aware the other exists. Power and ground are common; that is the whole of the shared wiring.

What it costs is the two blocking reads. Each one holds the wire down to wake the sensor, then counts pulses for forty bits with interrupts switched off. The DHT11 is the expensive one, and almost all of its cost is the 20 ms start pulse rather than the data.

Why build this

Because the datasheet's ±2 °C and ±5 % are abstractions until two sensors in the same air are printing different numbers at you.

Leave it running for an hour and three things become obvious:

The DHT11 moves in steps. It will read 22.00 for twenty minutes, then jump to 23.00 in one reading. There is no gradual anything; the resolution is a whole degree.

The gap is not constant. ±2 °C is not a fixed offset you could calibrate away — it wanders, which is why the sensor is not worth calibrating.

The humidity is worse than the temperature. ±5 % against ±2 % is the bigger of the two differences, and it is the one that matters most once you compute anything from it. A comfort reading puts a number on that.

Mount them the same

This is the one way to get a misleading answer out of the experiment. If the DHT11 is plugged into the breadboard and the DHT22 is dangling on 20 cm of wire, the DHT11 is reading a warm board and the DHT22 is reading the room, and the gap you measure is your wiring rather than the sensors.

Same height, same airflow, same distance from anything warm, and both away from the board — see how slowly it catches up for why.

Reading it into a spreadsheet

The sketch prints comma-separated values with a header row, so the Serial Monitor's output pastes straight into a spreadsheet or a plotting tool. Five seconds per row is 720 rows an hour, which is plenty to see the shape and small enough to paste.

The code

side_by_side.ino

Reads a DHT11 and a DHT22 on two pins and prints both plus the difference between them, once every five seconds. Leave it running for an hour beside a window and the gap is the specification made visible.

// Both sensors side by side: a DHT11 and a DHT22 on one board.
//
// Wiring, both sensors:
//   Sensor GND  -> board GND
//   Sensor VCC  -> board 5V on an Uno, 3V3 on an ESP32, ESP32-S3 or Pico
//   Sensor NC   -> nothing
//   DHT11 DATA  -> Uno D2, ESP32 GPIO 18, ESP32-S3 GPIO 4, Pico GP2
//   DHT22 DATA  -> Uno D3, ESP32 GPIO 19, ESP32-S3 GPIO 5, Pico GP3
//
// Count the pins from the square pad: GND, VCC, NC, DATA. Mount the two
// sensors the same distance from the board -- if one is on the breadboard
// and one is on wires, you are measuring the breadboard.
//
// Arduino IDE: install "DHT sensor library" by Adafruit from the Library
// Manager, and accept "Adafruit Unified Sensor" when it offers it.

#include <DHT.h>

#define PIN_11 2      // Uno D2.  ESP32: 18.  ESP32-S3: 4.  Pico: 2.
#define PIN_22 3      // Uno D3.  ESP32: 19.  ESP32-S3: 5.  Pico: 3.

// One object each, and the type is what makes them different. Nothing on
// the wire tells the library which is which.
DHT blue(PIN_11, DHT11);
DHT white(PIN_22, DHT22);

const unsigned long EVERY = 5000;   // well clear of both sensors' floors
unsigned long last = 0;

void setup() {
  Serial.begin(115200);
  blue.begin();
  white.begin();
  Serial.println("t11,rh11,t22,rh22,dT,dRH");
}

void loop() {
  if (millis() - last < EVERY) return;
  last = millis();

  // Each read blocks: about 24 ms for the DHT11 (20 ms of it just holding
  // the wire down to wake it) and about 6 ms for the DHT22.
  float t11 = blue.readTemperature(),  h11 = blue.readHumidity();
  float t22 = white.readTemperature(), h22 = white.readHumidity();

  if (isnan(t11) || isnan(h11) || isnan(t22) || isnan(h22)) {
    Serial.println("read failed");   // one sensor failing fails the row
    return;
  }

  // Comma separated, so it pastes straight into a spreadsheet.
  Serial.print(t11);  Serial.print(",");
  Serial.print(h11);  Serial.print(",");
  Serial.print(t22);  Serial.print(",");
  Serial.print(h22);  Serial.print(",");
  Serial.print(t11 - t22, 1); Serial.print(",");
  Serial.println(h11 - h22, 1);
}

Expect the two to disagree, and expect the DHT11 to be the one that moves in steps. A steady offset of a degree or two is normal and is mostly the two sensors being at slightly different heights and airflows; a gap that grows as the room warms is the DHT11's ±2 °C.

When it does not work

One sensor works and the other does not

Swap the two data wires without changing the sketch. If the fault follows the wire, it is the pin or the wire; if it stays with the sensor, it is that board or that constructor line. Nine times in ten it is a DHT11 declared as a DHT22, which usually never answers because the start pulse is too short to wake it.

The DHT11's temperature only moves in whole degrees

That is its resolution, not a fault. The column will sit on 22.00 for twenty minutes and then jump to 23.00, while the DHT22 beside it walks up in tenths. Seeing that next to each other is most of the reason to build this.

They disagree by two degrees and never converge

Check they are mounted alike — same height, same airflow, same distance from the board — before blaming either. A sensor on the breadboard and a sensor on 20 cm of wire are measuring two different things. If they are alike, ±2 °C on the DHT11 alone permits this.

The loop feels sluggish

It is: about 30 ms of every pass is spent inside the two reads, with interrupts off for roughly 9 ms of that. The sketch above only reads every five seconds, so it is 30 ms in 5000. Doing it every loop is what makes a sketch feel stuck.

Can I put both sensors on one pin?

No. There is no addressing in this protocol, so both would answer at once and the two sets of pulses would overlap into nonsense. One sensor, one pin, always.

Where this goes next

Turning temperature and humidity into a dew point, and what the sensor's tolerance does to it.

A comfort reading

Edit this page — content/books/dht22/both-sensors-side-by-side.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