Ceci est une ancienne révision du document !
Last month, I suggested you get a number of parts and if you were able to get them, I hope that it didn’t cost you too much. If you haven’t gotten them, then follow along as best you can, and if there is a particular project you want to try, then get those components that are needed. I’m trying to do this on as little cash outlay for either you or me as possible. Frequently, you can recycle many of the items from older electronic items; many can be found at a local thrift store for pence on a pound. (Hopefully I got that one right. We say pennies on a dollar here, so at least give me an “F” for effort… ok?) As I was laying last week, waiting for some surgery, I was thinking that if someone were to come up to me and ask directly why I’m doing this, what my answer would be. Before the wonderful chemicals they pumped into my body to make the process less horrible, I realized that the REAL reason is multi-part. First, is to create excitement in “non-programmers” when doing things that seemingly could not be done without a ton of training. Secondly, is to show that the newer technology, like the Raspberry Pi and the Arduino, is not beyond the ken of the “general joe” out there, but that anyone can do things that have real world applications (hence the title of our series). That having been said, making LEDs blink is only the same kind of project for the hardware world as the “Hello World” program is in the programming realm. You have to take small steps before you move to the big race. Believe me, we will be doing some amazing things with all those little parts, whatsits and thingamabobs.
This month, we will be using the DHT11 Basic Temperature/ Humidity Sensor with our Raspberry Pi. Next month, we will be doing the same sort of thing using the Dallas DS18B20 temperature sensor, and if there is time and/or space, we’ll also talk about the 16×2 LCD display. In a few months, we’ll switch from the Raspberry Pi to using the Arduino. Don’t worry, none of the things we are using now will go unused after a single project. For example, once we have a grasp of some of the Arduino basics (which WILL involve learning a small amount of ‘C’ like programming (sorry about that)), we’ll be writing programs in Python on the RPi (or your local computer) to control the Arduino. The sensors we have learned about in our RPi experiments will be re-used when we learn about the Arduino, and many will be incorporated into some larger projects. Very shortly, we will be using DC Motors, Solenoids and Stepper Motors in some really basic projects, but we’ll use them in larger projects, including building a Computer Controlled (RPi) Laser Engraver using a Laser Diode recovered from an old DVD Burner. Enough about the future. Let’s start with this month's project.
The DHT11 is the least expensive sibling of a series of temperature and humidity sensor sets. The DHT11 has a temperature range from 0⁰ to 50⁰ C with ±2⁰ C accuracy (32⁰ to 122⁰ F, ±3.6⁰F) and a humidity range from 20-90%RH ±5%. You can see that it’s not the most accurate sensor on the market; there is a DHT22 that is more accurate and has a wider range (-40⁰ to 80⁰ C temp range) but about twice as expensive. It’s a bit of a funny looking thing. A blue rectangular plastic box with holes in it and something shiny inside it. It might come just as a single sensor with 4 pins, or already on a mini-circuit board with 3 or 4 pins. Either way, they are basically the same. For now, we’ll use the discrete component (the one without the circuit board) for the sake of the discussion, and I’ll address the differences as we go along. Whenever you want to work with a new sensor, you should get a spec sheet (data sheet). A simple web search should turn up a number of results. Try to get something directly from the manufacturer if at all possible. For the DHT11, a good place to get one of the various data sheets available is http://www.micropik.com/PDF/dht11.pdf. While this isn’t directly from the manufacturer, it is from a company that sells it, and has “translated” the manufacturer’s data into a 9-page PDF file.
You might already be asking, why do I need this? There’s a bunch of information that, unless you have a PhD in Physics or something, you’ll never need. Well, that is true, but there is a lot of information that IS relevant and can potentially keep you from blowing up either the sensor, the controller, or your work bench. In this case, we find that the DC operating voltage is between 3 to 5 volts and it pulls about 0.5mA during “normal” conditions (section 6). We also find that this is a rather slow device and that we should not try to pull data more than once per second. Basically we’ll keep it around once every five seconds in our testing program, which is way more than we’ll need in reality. Another thing: if the cable that sends the data from the sensor to the microcontroller (our RPi) is less than 20 meters, we should have about a 5K ohm resistor between the data line and the local power supply (at the sensor) as a pull-up. One last thing (I’m going to stop here, but there’s much more): Pin 1 is positive voltage, Pin 2 is the data pin, and Pin 4 is the ground pin. This gives us pretty much everything we need to know to safely connect this to our RPi. Below is the wiring diagram for a “raw” DHT11 sensor WITHOUT a breakout board. If you have a sensor with a breakout board, see my discussion below the diagram.
Notice that I said earlier that a 5K resistor was needed as a pull-up. If you are going to use 3.3 VDC as a power source (RPi pin 1), then a 5K resistor works pretty well. If, however, you are going to use 5 VDC as shown in the diagram, use a 10K resistor. You can see that it’s fairly simple, just three wires and a resistor. For our simple project, don’t try to make the wiring the entire 20 meters though. If you have a DHT11 on a breakout board, you will likely have only 3 output pins on it. I have two sensors from different vendors, and (go figure) both have a different pinout. One is laid out [Data] [Positive Voltage] [Ground] and is marked “S -”. The other is [Ground] [Data] [Positive Voltage] and is marked as such. Hopefully, yours has some sort of pinout definition printed on it. If not, you can use a multimeter to trace the ground pin and voltage pin directly from the sensor to the breakout pin. You can usually guess that if there are three output pins on the breakout board and you know ground and positive voltage, then the other SHOULD be the data pin.
Now our program code. For the sake of getting things up and running quickly, we will be using some code provided by the kind people at Adafruit.com – they provide the library for working with the DHT11. (They found that trying to run straight Python code for the library causes some timing issues, so the library is actually written in ‘C’.) There are a number of steps involved, so follow the instructions carefully. I’ve paraphrased them so if something doesn’t work, you can also find the instructions at the Adafruit website at https://learn.adafruit.com/dht-humidity-sensing-on-raspberry-pi-with-gdocs-logging/software-install-updated . Once everything is done, you can run my modified Python example presented at the end of the instructions. In your “/home/pi” directory, run the following commands: git clone https://github.com/adafruit/Adafruit_Python_DHT.git cd Adafruit_Python_DHT sudo apt-get update sudo apt-get install build-essential python-dev python-openssl Ignore any errors that state a package is already installed.
Next, install the library by running: sudo python setup.py install Once all that is done, you can move on to our sample code. Above is my modified sample code “borrowed” from the Adafruit sample code. All of the above can basically be boiled down to three lines of code. The two import statements and the assignment of the variable ‘sensor’ to the class code. pin = 4 sleep(3) Here we define that the sensor is connected to GPIO pin 4 and then we wait 3 seconds for things to settle and be ready to work.
We use a simple loop (next page, top right) to grab the values for humidity and temp over and over. I never got the knack of relating Celsius to “real” temperatures, so I convert it so that I can understand it. If you want Celsius, just comment out the conversion line. Now (next page, bottom right) we check to see if we got realistic values for both humidity and temperature, then we display them and sleep for 5 seconds. I must admit, when I run the program with one sensor, it gives some rather wacky results for the first two or three minutes, then settles down to values that I can trust. The other sensor seems to “lock in” faster, so I’m just writing it off to something in the first sensor. Well, that’s it for this month. Remember, we’ll be using the Dallas temp sensor next time, so be ready. Have a good time and I’ll see you next month.