Skip to main content

PiAMI HEAT



There is one little thing that has started to bother us.  All these unspectacular robot enhancements, all these limited robot movements, is bound to result in something.  Something dark and sinister.  Is that something "singularity", in which autonomous vacuum cleaners surpass the intelligence of human beings and end up hoovering us all up?  Doubtful.  But, heat.  Definitely.

Everyone knows that machines get hot (and not in the look-at-me-on-Instagram sort of way).  And Rosie 2.0 is no different.  When all her electronics and motors are in full flow, we need some way to cool her down.  She just needs to - quite literally - chill out.

And how hard could that task possibly be?  Are we about to make a mountain out of a mole hill?

Let's get our hands on a temperature sensor and find out the answer for ourselves.  And let's be quick.  Because we might just have to build ourselves a survivalist bunker in our backyard to evade the marauding terror twins that will be Henry and Hetty.

You don't want to be the tool without the tooling:

  • A Raspberry Pi 3, running Raspbian OS
  • DS18B20 1-Wire Digital Temperature Sensor.  We are using a module by Kuman, which came as part of the Kuman 37 Sensor Module Robot Starter KitDS18B20 itself is a widely used temperature sensor so it is available from many vendors and outlets, often as a module under different brand names.  Getting it as a module, as opposed to just the sensor itself, may mean you have less fiddling around to do (such as soldering a pull-up resistor).  Either way, you'll need the sensor.  Period.
    • We did experiment with the less accurate DHT11 humidity / temperature sensor as well, which is chronicled towards the end of this post.  In fact, we eventually invited its more attentive cousin - DHT22 - to the party also.
  • If you want to demonstrate that some of this can actually be quite useful, you could hook up a cheap battery-powered fan (via a relay) to operate it.  You may also want to use a two-colour LED as a simple visual warning indicator.
  • You are likely to require some resistors if your module doesn't come with any

Chequered history:

Building Rosie 2.0 - naturally - assumes that there is a Rosie 1.0.  For that reason, casting your eyes over the organised chaos that was Rosie and Rosie Patrol is highly recommended.

Bit by byte:

  • Connect the DS18B20 Digital Temperature Sensor to the GPIO pins of the Raspberry Pi.  Connect a 4.7kΩ pull-up resistor if there isn't one there already.
  • Enable 1-Wire for your Raspberry Pi
  • Write some Python code to take temperature readings over 1-Wire
  • That's it... unless you want to also:
  • Inject a relay into a battery-powered fan, and connect it to the GPIO pins of the Raspberry Pi.  Oh yes.  Don't forget the bi-colour LED as well for the obligatory warning effect.  Remember the principle law of electronics?  Green LED = the world is a happy place (but may not be for long - see next LED colour), red LED = everything is about the be annihilated into extinction.  The LEDs will also require some resistors to limit current.
  • Alternatively try a DHT11 humidity / temperature sensor. It doesn't use the 1-Wire protocol, it's far less accurate and requires a Python library, but it's a fun alternative.

You ain't seen nothing yet:

1-Wire is a protocol that allows you to receive low-speed data (such as temperature measurements) using guess how many wires?  Yep.  Ninety-two.  One.  So a temperature sensor, such as the DS18B20, can make its measurements available to the Pi using only one 1-Wire-enabled GPIO pin (pin 7 / BCM 4).  And it does this extremely well.

By enabling 1-Wire in Raspbian OS, and connecting the DS18B20, the Raspbian Linux OS itself can start to read the measurements that miraculously appear visible to the filesystem... quite literally, as contents of a file.  And as a result, Python can interrogate the file to obtain the latest temperature recordings.  It really isn't very sophisticated, but unusually effective for very low-tech sensors such as one that only needs to send temperature measurements every now and again.

And what should we do with these measurements?

You could record the temperature readings inside your favourite mole mound over time, and Tweet the 3-day moving averages to www.whatistheaveragetemperatureofyourfavouritemolemound.com*.  Or alternatively, Tweet them at Countryfile, who are likely to happily feature your findings on their next show.  Or, you could simply operate a fan and a bi-colour (green / red) LED based on the readings.  Yes, we've opted for the most boring of the options, as we attempt to remain sensible for a change.

*Not an actual website.  But please do not attempt to visit (in case it turns out to be).

Detail:

There really isn't much to this outing; especially since taking temperature measurements using a DS18B20 digital temperature sensor and a Raspberry Pi appears to be a really popular thing to be doing.  Therefore, there is already a lot of useful tutorials out there on this very topic.

We found the below two particularly useful.
It's worth noting that we used a DS18B20 "module" - which is essentially a sensor pre-soldered into a board.  More importantly, it already has a pull-up resistor built-in, and there is a handy light that flashes on and off (presumably when it makes a reading, although we're not 100% sure).  If you are using only the DS18B20 sensor, there are some additional considerations to make (like the pull-up resistor - likely to be 4.7kΩ), which the above guides carefully walk you through.

The DS18B20 essentially has three pins, and this is how we cabled them up:

DS18B20 PinPi GPIO PinDescription
GND (Ground)Any 0V Ground (e.g. 6, 9, 14, 20, 25, 30, 34, 39) 0V (Ground)
DQ (Data)7 (BCM 4)This is used by 1-Wire for sending back temperature data
VDDAny 3.3V (e.g. 1 or 17)Used to power the sensor using 3.3V

The pull-up resistor (4.7kΩ) is inserted between VDD and DQ.

Once it's all cabled up, it will probably look a little like this:


There's nothing more to this in terms of hardware, so let's quickly move on before we start to ask awkward questions, like: are there now more moles living in the UK than people?

In order to use the 1-Wire protocol, it needs to be enabled in Raspbian OS.  And the way to do this is to append a parameter in the /boot/config.txt file.  But that was blindingly obvious, right?  Not.

Open up /boot/config.txt using the nano editor.

sudo nano /boot/config.txt

And add the following line right at the end (also add a comment if it helps you remember what you did):

dtoverlay=w1-gpio


Once you save the file, it's time to reboot the Pi for the setting to take effect.

sudo reboot

Now that 1-Wire has been enabled, sensors connected to the Pi's 1-Wire pin (GPIO pin 7 / BCM 4) should be picked up.  This is how we can check this.

sudo modprobe w1-gpio
sudo modprobe w1-therm
cd /sys/bus/w1/devices
ls


The terribly named "28-011513b6e9ee" is our temperature sensor.  And we can quite literally address it using that name.  For example, navigating to its directory and opening the "w1_slave" file allows you to interrogate the sensor data in its raw format.

cd 28-011513b6e9ee
ls
cat w1_slave


In amongst the jumbled up data is actually the temperature reading.  Notice the "t=" at the end?  Divide that value by 1000, and you get your latest temperature measurement from the sensor in Celsius.


Now clearly we want to be able to get this value programmatically from within Python.

The examples that are provided by ModMyPi and The Pi Hut tell you all that you need to know.  But in short, the code simply reads the file that we were viewing not so long ago, and identifies and returns the "t=" value that we are interested in.  We'll make this module-like, so we can call get_temp() from outside this snippet, to make use of the temperature reading elsewhere.

Our code ended up looking a bit like this:

Let's now test this using IPython.

ipython3

While in the directory with the Python file, import our module, and run the get_temp() function.

import rosie_temperature
rosie_temperature.get_temp()


This is what we observe every time we run rosie_temperature.get_temp().  In this example, we were pressing against the sensor with our finger, which is why the temperature was creeping up ever so slightly between readings.

There really isn't much else to do to test that the sensor works.

However, in the interest of proving that this *could* be useful, we've hooked the Pi up to a small, battery-powered fan (via a relay), and a bi-colour (red / green) LED.  Both items were also found in the Kuman 37 Sensor Module Robot Starter Kit.  The fan, on the other hand, is a cheap, desktop fan available from many online retailers.


We've simply soldered the cables in parallel to the Normally Open (Push to Close) button equipped on the face of the fan chassis, similarly to what we did to a flashlight sometime ago.  This way, the physical switch continues to work, but the relay can also perform the identical function, electronically.

It's important to revisit the past post on operating a relay, and re-read all the accompanying warnings.  In particular, we are using a battery-operated fan on purpose, due to the low voltages involved.  Do not go anywhere near a mains-operated fan.

Here's how we cabled up the relay.

Relay PinPi GPIO PinDescription
GroundAny 0V Ground (e.g. 6, 9, 14, 20, 25, 30, 34, 39) 0V (Ground)
VccAny 5V (e.g. 2, 4)Used to power the relay
Vin8 (BCM 14)Used to operate the relay
CommonN/A (Fan)For closing and opening the circuit like a switch.  Connect to one end of where the circuit needs to be closed.
Normally OpenN/A (Fan)For closing and opening the circuit like a switch.  Connect to the other end of where the circuit needs to be closed.

The bi-colour LED has a much simpler set of cabling requirements, although you will need to cable resistors (330Ω) in series with both the green and red inputs if your module doesn't already have these in.  Bi-colour LEDs work by displaying a different colour depending on the direction of the current... which means like normal LEDs, we want to restrict the current travelling through them using these resistors.

Bi-colour LED PinPi GPIO PinDescription
GroundAny 0V Ground (e.g. 6, 9, 14, 20, 25, 30, 34, 39) 0V (Ground)
V (Green)10 (BCM 15)When this is high, and other is low, LED will be green
V (Red)12 (BCM 18)When this is high, and other is low, LED will be red

You can guess where we are heading with this, now that we have both a fan and a bi-colour LED under our control.  But first, here is how everything ends up being cabled together.


All we want to do now in our main() function is to monitor the temperature every second, then if it's above a preset warning threshold (25c in our case), we'll turn the LED red from green, and switch on the fan at the highest setting.  Once the temperature falls under that threshold, we'll turn the LED back to green, and switch off the fan.

Note that our particular fan has multiple settings which can be toggled through each push of the Normally Open switch.  This needs to be mimicked by the Python code.

The fan settings are:
  • 0 = Off
  • 1 = Low
  • 2 = Medium
  • 3 = High
  • 4 = Just the LED on (no idea why this is useful on a fan)
For all of this we've created another module - rosie_fan.py - in which we're housing two classes; one for the LED, other for the fan.  The LED class simply allows us to toggle the relevant GPIO pins to turn the LED green (set_green() method) and red (set_red() method).  Nice and simple.

The Fan class does something similar with the relay GPIO pin, but with a bit more context about what it is that it's been asked to do.  We'll track what we think is the current state of the fan (using self.fan_state) to make sure that we can instruct it to arrive at the requested target_state through the relevant number of close / open relay actions.  Of course, there's no way to keep this in sync.  If we manually push the button on the fan, the code won't know anything about this.

Here's our rosie_fan.py which we import from rosie_temperature.py:


Run rosie_temperature.py and hopefully you will see the temperature readings, and more interestingly, the fan turning on, and green LED turning red, when the threshold is reached.

python3 rosie_temperature.py


And here's what happens when we hover the temperature sensor above some hot water.


And that's about it.  Nothing more to see here.  Move along, please.

We've demonstrated that we can use a temperature sensor with the Pi and Python to take temperature readings.  And made it slightly more useful by operating a LED and a fan.  Clearly, you could do a lot more with this.  Like operate the fan in different fan settings depending on the temperature, or maybe even display the current readings on a LED display, purely for the benefit of the moles in the mounds, you understand.

But it's getting late; and quite frankly, we really need our sleep.  Besides, mole mounds are harder to find in the dark.  Ah ok, maybe that was what setting (4) on the fan was for...

Can't stand the heat?

Didn't we say taking meaningless temperature readings using some sort of sensor attached to the Pi is a very popular pastime (according to the reliable, collective source of wisdom that is the Internet)?  So don't feel the need to use a DS18B20 to take your readings - there's plenty of other widgets available.

Below are the steps we used with a primitive DHT11 sensor.

It's not as accurate as the DS18B20 (±2°C accuracy is actually quite inaccurate when it comes to temperature) - but hey - it takes humidity measurements as well which is just another pointless data point that we can claim to have collected.  It also takes readings every second, and is only useful between 0-50°C.  In other words, take something else along for your interstellar travels.  Compare that to the DS18B20 (with a range of -55-125°C and accuracy of ±0.5°C), and you can see why the original is the clear winner.

But we've already written a wordy paragraph on it, so purely to see this task through, let's give the DHT11 a go.  Incidentally, there are other (superior) members of the DHT family available, such as the DHT22, which we eventually got to play with.

The sensor is simply connected to a standard GPIO pin, and Adafruit have a perfectly usable Python library for it, so we didn't exhaust too much effort working out how it works.  In fact, it's advisable to use the library.  The protocol used by the sensor isn't 1-Wire... and so there will be a lot of head scratching involved in trying to work out how the device is sending back its readings.

Here are what the connections look like from the Pi when you obtain a DHT11 as a pre-mounted, soldered module.  If you get the sensor by itself, you'll need to attach the DATA pin to Vcc via a pull-up resistor.  In short, it's near identical to how a DS18B20 is connected, except DHT11 doesn't use the 1-Wire protocol so you could use any of the other GPIO pins.

DHT11 PinPi GPIO PinDescription
GND (Ground)Any 0V Ground (e.g. 6, 9, 14, 20, 25, 30, 34, 39) 0V (Ground)
DATA7 (BCM 4)This is used by the sensor for sending back data
VCCAny 3.3V (e.g. 1 or 17)Used to power the sensor using 3.3V



And in real life:



We didn't find the orientation of the pin headers very helpful on our module, so as you can see in this photo, we have replaced them with simple cables soldered directly to the board.

All hooked up.  Ready for some coding,  Let's start with the prerequisites, because that's what the documentation tells us.

sudo apt-get update
sudo apt-get install build-essential python-dev 

We can now clone the Adafruit library which is hosted on GitHub.

sudo git clone https://github.com/adafruit/Adafruit_Python_DHT


Once it's cloned, navigate to its directory and install.

cd Adafruit_Python_DHT
sudo python3 setup.py install


All done? It's time to launch IPython and give the library a whirl.

ipython3

It's real simple: import the Adafruit_DHT module, instantiate an Adafruit_DHT class (the DHT11 variant), and simply take readings using read_retry() - passing your sensor instance with GPIO pin number.

import Adafruit_DHT
dht_sensor = Adafruit_DHT.DHT11
print(Adafruit_DHT.read_retry(dht_sensor, 4))


And that's about it. A tuple containing two values is returned. Containing your humidity reading (%), followed by the temperature (°C). Simple (and crude). But arguably quite effective.

As it transpires, there's a heat wave taking place here in the UK (June / July 2018).  So here's how hot the DS18B20 and DHT11 sensors believe it is in a west-facing room that noticeably warms up throughout the afternoon.  Measurements were taken at minutely intervals over a 48 hour period.  Yes: as you can see, it demonstrates perfectly how the resolution of the DS18B20 makes it a clear winner (although the DHT11 is still quite usable).


Here's from the same setup, but over a longer 7-day period.  Interestingly, we start to see some erroneous looking readings (outliers).  During practical application of the data, we might want to filter these out.


Update - April 2019

How does it work with the slightly superior DHT22?


Yep, you guessed it.  If we're still using the Adafruit library (which we should, since it works effortlessly) then the 11 becomes a 22.  Basically, like this:

import Adafruit_DHT
dht_sensor = Adafruit_DHT.DHT22
print(Adafruit_DHT.read_retry(dht_sensor, 4))

There they are.  Humidity and temperature readings (again).  Who knew it would be this easy, eh?


The DHT22, also curiously branded as "AM2302" when wired up, provides better accuracy, and works at a wider measurement range.  Clearly, at an additional financial cost (and size).  Worth an upgrade?  Just maybe.

Go and see the doc:

The official datasheet for the DS18B20 sensor can be found here:
There's a detailed explanation on how to get the DS18B20 working with your Pi here:
...And also here:
Finally, as always, the Pi pinout reference is very useful when trying to figure out what to connect where.  Specifically, relevant for this, is the 1-Wire pin.
Adafruit sell these DHT11 (and DHT22) sensors if these are what you prefer to the superior DS18B20 (or you have a particular interest in recording humidity):
And there is a neat tutorial on how to use the DHT sensors here:

Comments

MOST VISITED (APPARENTLY)

LoRa-Wan Kenobi

In the regurgitated words of Michael BublĂ©: It's a new dawn .  It's a new day .  It's a new Star Wars film .  For me .  And I'm (George Lucas, and I'm) feeling good .  Unfortunately for Canadian Mike, the Grammy that year was won by the novelty disco classic with the famous refrain: We love IoT, even in Planet Tatooine * . *Not true. Clearly, the Star Wars producers didn't sincerely mean the last Jedi the previous time around.  Return of the Jedi, released during the decade that spearheaded cultural renaissance 2.0 with the mullet and hair-metal , was less economic with the truth.  Either way, we're going to take inspiration from the impressive longevity of the money-spinning space-opera and reboot our franchise with some Jedi mind tricks.  Except this particular flick doesn't require an ever-growing cast of unrecognisable characters, unless ASCII or UTF counts.  In place of an ensemble gathering of Hollywood stars and starlets, we will b

Battle of BLEtain

The trolling . The doxing . An army of perplexing emojis. And endless links to the same - supposedly funny - viral video of a cat confusing a reflection from a dangling key for a golden hamster, while taking part in the mice bucket challenge. Has social media really been this immense force for good? Has it actually contributed significantly to the continued enlightenment of the human (or feline) race? In order to answer these poignant existential questions about the role of prominent platforms such as Critter, StinkedIn and Binterest, employing exceptional scientific rigour equal to that demonstrated by Theranos , we're going to set up a ground-breaking experiment using the Bluetooth Low Energy feature of MicroPython v1.12, and two ESP32 development boards with inexplicable hatred for one another.  And let them hurl quintessentially British expressions (others call them abuse) at each other like two Wiltshire residents who have had their internet access curbed by the co

Hard grapht

You would all be forgiven for assuming that bar , pie and queue line are favourite pastimes of the British .  Yet, in fact – yes, we did learn this back in GCSE maths – they are also mechanisms through which meaningless, mundane data of suspect origin can be given a Gok Wan -grade makeover, with the prime objective of padding out biblical 187-page PowerPoint presentations and 871-page Word reports (*other Microsoft productivity tools are available).  In other words, documents that nobody has the intention of ever reading.  But it becomes apparent over the years; this is perhaps the one skill which serves you well for a lifetime in certain careers.  In sales.  Consultancy.  Politics.  Or any other profession in which the only known entry requirement is the ability to chat loudly over a whizzy graph of dubious quality and value, preferably while frantically waving your arms around. Nevertheless, we are acutely conscious of the fact that we have spent an inordinate amount