The start and the answer
One wire, two devices, no clock between them. Your board asks by holding the line low for at least 18 ms; the DHT11 answers by holding it low for 80 µs. Nothing else is a request, and the long start pulse is most of the time a reading takes.
Watch the wire change hands
Press the button and follow the colour. Green is your board driving the line; orange is the DHT11.
Idle. Nobody is driving the wire; the 10 kΩ resistor on the board holds it high on its own.
Four things happen, always in this order.
Your board pulls the line low and holds it. That is the whole request. There is no command byte and no register address; holding the wire low long enough is the question, and the answer is always the same forty bits.
Your board lets go. It switches the pin back to an input. For 20 to 40 µs neither side drives the wire, and the 10 kΩ resistor on the board holds it high on its own.
The DHT11 pulls it low for 80 µs, then lets it up for 80 µs. This is the
"I am here". If it never comes, the library gives up after a millisecond and
returns nan. The datasheet's own advice for a line that stays high is to
check the connection.
Then the bits start, and the sensor owns the wire until all forty are sent. Afterwards it drops back into its low-power mode until the next start pulse.
Why 18 ms
The DHT11 sleeps between readings, and the start pulse is what wakes it. The
datasheet (§5.2) asks for at least 18 ms; Adafruit's library sends 20. The
DHT22 on the TK39 wakes in 1 ms, and a sketch that declares a DHT22 sends
1.1 ms. A DHT11 given 1.1 ms often never answers, which is why a wrong
DHT_TYPE usually shows up as silence rather than as bad data: the wrong
type.
What it costs the sketch
The start pulse is delay(20): twenty milliseconds in which the sketch does
nothing else. The forty bits that follow are timed by counting loop turns, so
the library switches interrupts off for them.
One reading is therefore about 24 ms of stopped program, 20 of them the start pulse. For a room monitor that is invisible. Inside something that also has to answer a network or keep a motor stepping, it is worth knowing, and it is a reason to read every few seconds rather than as often as the loop spins.
Why this is not 1-Wire
The name is confusing and the likeness is skin deep. Dallas 1-Wire gives every device a 64-bit serial number so that a dozen can share one line. This protocol has no addresses, no way to pick a device, and no way to ask a particular sensor anything.
So there is nothing to scan for and no bus to hang a second sensor off. Every DHT11 gets a pin of its own.
When it does not work
It is waking up. The DHT11 sits in a low-power mode until the line is held low, and its datasheet asks for at least 18 ms to be sure it notices. Adafruit's library holds it for 20 ms. A sketch that says DHT22 holds it for 1.1 ms, and a DHT11 often sleeps straight through that.
Check DHT_TYPE before anything else. Declared as a DHT22, the DHT11 gets a start pulse about eighteen times too short, so the symptom is a sensor that answers now and then or not at all on wiring that is correct.
No. The protocol has no addresses, so two DHT11s on one wire both answer at once and neither reading survives. One sensor, one pin.
The library handles it: it switches the pin between OUTPUT driven LOW and INPUT, which is open drain done by hand. What matters is that your own code never drives DATA HIGH. The resistor does that, and a pin driving HIGH while the sensor pulls LOW is a short through both.
Five bytes, and how the length of a pulse becomes a 0 or a 1.
Forty bits and a checksum →Edit this page — content/books/dht11/the-start-and-the-answer.mdx
Questions about this product
See what other owners have asked, and read their solutions.
DHT11 Temperature and Humidity Sensor
Loading 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.