The wrong type
The library cannot tell a DHT22 from a DHT11, so it believes the type word in your sketch. Say DHT11 on a TK39 and the DHT22 still answers, the checksum passes, and a 23.4 °C room prints 0.0 °C and 2.0 %. Say DHT22 on a TK38 and the start pulse is too short to wake it, so every read is nan.
One word, two jobs
#define DHT_TYPE DHT22The type word decides two things, and nothing on the wire can overrule it.
First, the start pulse: how long the library holds DATA low to wake the
sensor. For DHT22 it is 1.1 ms, against the at-least-1 ms in the DHT22
datasheet's §6. For DHT11 it is 20 ms, against the DHT11's 18 ms.
The start and the answer
in the DHT11 book draws the whole exchange.
Second, the decoder: how the five bytes that come back become two numbers. For a DHT22 each pair of bytes is one word of tenths; for a DHT11 the first byte of each pair is whole units (tenths and the sign bit).
Both ways round
Put either board on the wire and let the sketch say either type.
DHT11 on a TK39 is the mistake to fear. A 20 ms start is far longer than
the DHT22 needs, so it wakes, answers, and sends a frame whose checksum
passes. The DHT11 decoder then reads the high byte of each word as whole
units: 51.2 % arrives as 0x02 0x00 and prints as 2.0 %; 23.4 °C prints as
0.0. It is steady, it never says nan, and on a first run it can look like
a cold, dry room.
DHT22 on a TK38 is the loud one. 1.1 ms is well short of the 18 ms the
DHT11 datasheet asks for. What a DHT11 does with a pulse that short is not
in its datasheet, and in practice it usually does not answer, so every read
is nan. If one does answer, the DHT22 decoder turns 51 % into 1305.6 %,
which is at least obviously wrong.
Why the checksum does not catch it
The checksum is the low eight bits of the first four bytes added up. It proves the bytes arrived as they were sent. It says nothing about what they mean, so a frame decoded with the wrong rules passes it every time. Forty bits and a checksum shows the sum.
The only defence is the type line. Every sketch in this book says DHT22,
and every sketch you copy from elsewhere is worth checking for it first.
When it does not work
The sketch says DHT11 and the sensor is a DHT22. The DHT11 decoder takes the first byte of each 16-bit word as whole units, and for room readings that byte is between 0 and 3. Change DHT_TYPE to DHT22.
Also a DHT22 read as a DHT11. Below zero the DHT22 sets the top bit of its temperature word, and the DHT11 decoder reads that byte as 128 or more whole degrees: −5.3 °C prints as 128.5. The fix is the same one word, DHT22.
Most DHT examples declare one type. An example written for a DHT11 runs on a TK39 and prints nonsense; one written for a DHT22 on a TK38 usually prints nan. Check the type line of any sketch you did not write before checking the wiring.
The cage: white is the DHT22, blue the DHT11. The back of the board says TK39 DHT22 or TK38 DHT11, and the DHT22's cage in the kit is printed AM2302 DHT22. There is no way to ask the sensor.
nan, a steady wrong number, a reading that repeats, and one that is warm and dry: what each points to.
When the number is wrong →Edit this page — content/books/dht22/the-wrong-type.mdx
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.