First of all, as this question involves a raspberry, python, Rpi. Gpio module and hardware build, I thought this was the place for it.

In the past I've done some work around Dht11 sensor and python seamlessly. I used the little library below, consisting in two classes that handle a dht11 and it's results (or errors). It's not mine and I found it somewhere, kind of undocumented but stable, readable and working out of the box:


But recently I've came across a bunch of dht11 with different pinout and a built in led. The library above doesn't work quite well. It returns an error of missing data often, stored in the DHT11Result.error_code returned from DHT11.read()

I wanted to fiddle with them in arrays, so I made this workaround to avoid missing reads to sensors. The key is in __read() method, where a while loops over reads while the result error is different from 0 (success) the rest is just convenience:

class DHTarray:
    def __init__(self, pinArray):
        self.sensor_array = []
        self.tR = [] #temperature results
        self.hR = [] #humidity results
        self.avT= 0 #average temperature reading
        self.avH= 0 #average humidity reading
        for val in pinArray:
            self.sensor_array.append(DHT11(val)) ##add a DHT instance per pin
    def __read(self):
        self.tR = [] #erase previous readings
        self.hR = [] #erase previous readings
        for sen in self.sensor_array:
            r = sen.read()
            while r.error_code != 0: #workaround loop for frequen missing data errors
                r = sen.read()
    def __average_read(self):
        self.__read() #get updated reads
        self.avT = 0
        self.avH = 0
        for i in self.tR:
            self.avT += i
        self.avT = self.avT/len(self.tR)
        for i in self.hR:
            self.avH += i
        self.avH = self.avH/len(self.hR)
    def update(self):

Then i can come up with code like:

import dhtLib
import RPi.GPIO as GPIO
myarray = dhtLib.DHTarray([16,18])
print myarray.avT,myarray.avH #average temp and hum
print myarray.tR, myarray.hR #individual readings

While this works (and need improvement like a maxRetry setting or something to prevent endless loops), I'd like to know where the problem is, if it's software stuff, because this solution really slows down performance (sometimes it takes 8seconds to make a valid reading, or even more)

But what if the problem is the hardware? I've checked solder traces, no shorts, data lines are not being messed by anything. Every sensor in the array (2 in this example) shares vcc and gnd lines. Using one sensor with jumpers and same pin configuration gives the same problems.

Could be power supply problems? I've never had problems with using 5v line from raspberry, even with things that usually are a no-no like motors. But what if pi isn't capable of feed properly this version of dht, because of the built-in led and who knows what else?

1 Answer 1


The problem is that the DHT series of temperature/humidity sensors require precise timing ot their data to get a reliable reading.

The following is from memory so will probably contain mistakes but should give the idea.

For each reading the DHT returns 40 bits of information (2 bytes temperature, 2 bytes humidity, 1 byte checksum).

Each bit is signalled by two level transitions

0 is 50µs low, 30µs high
1 is 50µs low, 70µs high

So a total of 80 transitions and their edges must be correctly captured.

This is hard for a multi-taking operating system like Linux on the Pi.

If you look at the code you may get a feel for the number of different ways the software tries to capture the data.

Most code will repeatedly try the reading until one is found which seems to be correct.

There are a couple of exceptions I know about. One uses the SPI hardware to capture the bit stream. The hardware is handled by the kernel and its timing is immune from user land timing problems.

The other is the solutions based on (my) pigpio. pigpio can reliably time the events.

See my DHTXXD for a reliable method which uses the pigpio daemon.

  • I've managed to read the parts about timing in the scavenged library but I'm clueless about a lot of concepts there. Could my problem be solved jumping straight into c++ to get more accurate timing? I'm going to check your sources, to see if they fit the build
    – David P.
    Commented Mar 9, 2018 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.