How to read input from multiple (dozens) of sensors, with fewer pins

Question

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.

Answer 1

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

Protocol

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.

• Modbus over serial v1.02
• Modbus Application Protocol v1.1b3
• NMEA-0183

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.

Answer 2

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).

Answer 3

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.