I am looking to have a few dozen DHT11 temperature/humidity sensors connected to a raspberry Pi. I would like to be able to determine the temperature/humidity of each unit, without having to use dozens of MCU Pins. I also will eventually be needing a servo motor hooked up to each unit as well. I was thinking about using a multiplexer, but that would result in lots of wire to be used. Some sort of addressable latch seems to be the solution here, but not sure whats the correct route to take here.

  • \$\begingroup\$ What's the DHT11? Is it SPI or I2C or something? Or is ti a ratiometric sensor? \$\endgroup\$
    – Hearth
    Commented Oct 17, 2022 at 0:29
  • \$\begingroup\$ Similar question: arduino.stackexchange.com/questions/8193/… \$\endgroup\$
    – ErikR
    Commented Oct 17, 2022 at 0:36
  • \$\begingroup\$ wellpcb.com/dht11-datasheet.html \$\endgroup\$
    – Mattman944
    Commented Oct 17, 2022 at 0:59
  • 1
    \$\begingroup\$ Any chance at all there’s a better sensor available? I hate that communication spec \$\endgroup\$
    – Bryan
    Commented Oct 17, 2022 at 1:15
  • 3
    \$\begingroup\$ How far apart are the sensors? \$\endgroup\$
    – Mattman944
    Commented Oct 17, 2022 at 1:28

3 Answers 3


Dozens of temperature/humidity sensors sounds like a set of greenhouses, eventually with servos to open windows or run pumps ...

If you have dozens of anything, modularity and testability are really important. Instead of an addressable latch -- of itself a perfectly good idea -- consider local intelligence, whcih will give you a lot of benefits. A very small local MCU solves addressability and serial connection.

With a local MCU, obviously addressing is easy. But you can also standardise your interface so that later, different sensors only require local changes on the MCU.

  • Long Wires For wires longer than a single enclosure (over 50 cm, say) my suggestion would be: consider RS-485. (In half-duplex 1-pair configuration)
  • Short Wires If your wires are short (say, less than 20 cm) you might consider SPI or I2C. Advantages as above, saving a chip, PCB area, and power requirements. (But I can't immediately think of something that would have dozens of humidity sensors in a small area. Something in a lab?)

Architecture outline

What immediately jumps to mind is

  • Smallest MCU with enough IO, I often use 8-pin ATTiny85 (with internal oscillator)
  • Some 75176-pinout RS-485 driver and half-duplex 1-pair
  • Your sensor (1 pin IO) + line driver (2 pins IO) + 2 spare for servo
  • MCU transmits Node 7 17.6 C 25 %RH XXXX
    • XXXX is some kind of checksum or CRC
    • On a very lightly loaded net, remote units could transmit periodically (with randomising to reduce clashing, CRC to detect it (but see notes below)
    • Either/or with polling from master, responding to Node 7 ? XXXX
  • Do sensor normalisation on the local MCU so Pi master knows nothing about it.
  • Very slow transmission (9600 baud or even 1200)

This kind of arrangement

  • Scales extremely well
    • Especially for distance
  • Future-proofs extremely well
    • Especially for different sensors and actuators
  • Is extremely easy to test
    • Broadcast-until-silenced slaves are trivial to perform basic test
    • You can just type commands and read the answers
    • Tip: allow humansaysso as always-good checksum, so can type without special program


I'd imagine very simple text messages as the protocol:

node id name value unit name value unit ... XXXX

XXXX being whatever checksum/CRC you use. I'd suggest looking at CCITT-16 or even -32.

But if you like standards, consider Modbus-RTU or Modbus-ASCII or NMEA-0183, all of which have very useful ideas for you.

Low-road protocol You might not like having such a "high-road" protocol (unit conversion, readability, parsing). Instead you might consider having the local MCU do as little as possible, ie, just be a translator from the serial bus to the sensor format, and adding addressing. This is a perfectly reasonable approach. It comes down to whether you are more worried about forced changes in sensors (because of supply or functionality) or forced changes in your MCU firmware (because of bug).

Lastly, on the master Pi, consider UDP convert daemon translating to and from the bus outlined above. Then the real program interfaces via UDP datagrams. This modularity has huge benefits for futureproofing and testability:

  • Testing is great: can easily make N processes representing N slaves
  • Could put "real program" at any desired distance from "converter" over ethernet, internet

PS Re protocol and CRC: Consider actual text messages,

Update re broadcast slaves. My suggestion specifically is only good for very lightly loaded networks; concretely, is for the slaves to broadcast at whim after a reset. If you can be certain your network is very lightly loaded (perhaps a message every 10 minutes per slave, <100 slaves, ~10 ms/message) and the price of a missed message is very low (interpolated value on a graph for some slow-moving variable), you can just leave it like that. But for a bit more order, many would consider it better if the master polls the slaves. My preference is for slaves to wake up and announce themselves, master notes them, and then polls them -- but it depends entirely on what you're doing. If you've got anything which might get anywhere near loading your bus, or have any significant downside to individual missed messaegs, pay close attention to possibilities of collisions. As noted in comments (thanks @graham, @supercat), collisions are exponentially nasty on message size and frequency, and number of nodes. Where your tradeoffs lie is up to you and it's quite dependent on the frequencies and speeds etc.

  • 1
    \$\begingroup\$ @jonathanjo The problem with slaves spontaneously transmitting on a common bus is that the system is also self-destroying; and the more slaves you have, the closer that probability gets to 1. To make that work, you'd need a complex comms system which checks for bus conflicts, and with randomised retry periods. Because retries are random, you can't guarantee that a message will get to the master within some time (that's provable as a theorem), but you need retry periods to be random otherwise you can guarantee (again as a theorem) that states exist where you'll never get a message. \$\endgroup\$
    – Graham
    Commented Oct 17, 2022 at 14:00
  • 1
    \$\begingroup\$ @jonathanjo ... I wouldn't dispute the usefulness of a "test" button on the side which makes that specific slave do a transmit. But if all of them can transmit, then you don't actually have a "master-slaves" configuration. In fact what you have is a multi-master configuration, and multi-master configurations become more complex exponentially with the number of masters. (Literally exponential; that's how the probability of conflicts scales.) \$\endgroup\$
    – Graham
    Commented Oct 17, 2022 at 14:05
  • 1
    \$\begingroup\$ @jonathanjo Fair enough, although I'd suspect that at 9600 baud and with a few bytes of message, it won't take many devices before collisions become a reasonable probability. I agree with you on the rest of the answer though - a small smart device is definitely the way to go. \$\endgroup\$
    – Graham
    Commented Oct 17, 2022 at 14:14
  • 2
    \$\begingroup\$ If all transmissions by the master include a short preamble, then it may sometimes be useful to say that a slave which has something to say, and hasn't heard anything lately, may transmit an unsolicited "I have something to say" pulse. If that the master can and does ask "Does anyone have anything interesting to say" whenever it thinks it has finished handling everybody, it won't matter if one or more slaves transmit their "I have something to say" pulses at the moment the master is starting its preamble. \$\endgroup\$
    – supercat
    Commented Oct 17, 2022 at 15:35
  • 1
    \$\begingroup\$ @Graham: If unsolicited slave transmissions are limited to an "attention" pulse which must be preceded by a long silence, and is shorter than a "line clearing" preamble by the mater, I wouldn't regard such pulses as violating master/slave protocol, since the master would still be entitled to transmit any time it wants provided only that it sends out a "line-clearing" preamble any time slaves might transmit anything. \$\endgroup\$
    – supercat
    Commented Oct 17, 2022 at 15:41

An addressable latch may be a start of a multiple sensor system but you also want bidirectional communication (for the DHT11) and other functions ("a servo motor hooked up to each unit"). Such a system could become quite complex with dozens of sensors. Two addressable latches I've seen are CD4099 and SN74ALS259. These are parallel addressed devices with 3 address lines and a disable line, so each group could support up to 16 sensor positions. But as you see this is already requires up to 7 wires (4 addresses, data, power & ground). Each additional group of 16 sensors would require another line.

A better method may be to use an addressable serial device. One chip that does fit some of your requirements is a Maxim DS75LX (Digital Thermometer and Thermostat with Extended Addressing). This chip has addressable serial communication (with 27 addresses), plus an output fault pin (that might be usable as a servo enable).

Yet another option may be to add a small 8 pin controller (e.g. PIC or ATtiny) at each sensor location. The controller could be programmed to communicate on a serial data interface and also have a unique address stored in EEPROM. The number of sensor branches would then be limited only to the size of your address word. With a controller at each sensor position there would be many other options that could be implemented at each position, (such as a servo motor control).


DHT11 waits for a low level of sufficient length on the data pin, then transmits the whole data serially. It is not addressable, and the data pin is bidirectional.

So the simplest solution would be an analog mux with one channel per sensor, for example it can be made out of several 74HC4051.

This has the drawback of not being extendable, and you have 3 wires per sensor (VCC, GND, Data).

Adding the servos into the mix makes this impractical because you need one PWM per servo, which gets cumbersome when you need "dozens".

Therefore, I agree with the two other answers: you need a bus topology and modules. This makes it extendable, much easier to use and wire. RS485 is the cheapest protocol, and the differential transmission works well against interference. Note one module doesn't need to have only one servo and one DHT11, depending on which micro you use, it's always a good idea to route all the pins to a connector, so one module could manage several sensors/servos if it is convenient, or do other things.

  • 1
    \$\begingroup\$ There are I2C-controlled PWM generators out there. \$\endgroup\$ Commented Oct 17, 2022 at 13:11

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.