Forty bits and a checksum

Five bytes

Every reading is forty bits, most significant bit first, in the same five bytes. Play them through, then change what the sketch says it is talking to.

Byte 0 is the humidity and byte 2 the temperature, each a plain count: 51 % is 0x33, 23 °C is 0x17. Bytes 1 and 3 have room for tenths, and on nearly every DHT11 they are zero. Byte 4 is the low eight bits of the other four added up. If it does not match, the library throws the whole frame away and hands you nan.

How a bit gets its value

There is no clock line, so the length of a pulse is the data. Every bit opens with the DHT11 holding the line low for 50 µs. Then it lets the line up, and how long it stays up is the value:

• about 26 to 28 µs high is a 0
• about 70 µs high is a 1

Adafruit's library does not measure microseconds. It counts loop turns for the low half and for the high half of each bit and compares the two: if the high count is the bigger, the bit is a 1. That works the same on a 16 MHz Uno and a 240 MHz ESP32 without either knowing its own clock, and it is why interrupts have to be off while the counting happens.

Decoding it as the wrong sensor

The DHT22 packs each number into two bytes, as tenths. Tell the library the TK38 is a DHT22 and, if the sensor answers at all, it reads 0x33 0x00 as one number, 13056 tenths, and prints 1305.6 %. The temperature comes out at 588.8 °C.

The frame still passes its checksum. The library reports success. Nothing on the wire says which sensor sent the bytes, so the only guard is the line in the sketch: #define DHT_TYPE DHT11.

What the checksum is worth

It catches the fault this protocol is prone to: a bit whose pulse was stretched or clipped because something interrupted the counting. When that happens you want the frame thrown away, not averaged in.

It cannot catch anything upstream of the bytes: the wrong sensor type, the wrong pin, a sensor measuring its own warm board. Those all produce valid frames.