It’s Alive!

Happy to report the system is now in and working!

(To be honest, it’s been in and working for a while but blogging time has been pretty limited since.)

After running the thermometers for a while to ensure that the data logging was working fine (it was), I took the plunge and wired in the boiler controller. Here’s what it looks like:

DSC_3544The Arduino-based controller is at the bottom, on the wine rack.  To the left is the feed from the boiler.  I’ve used a mains connector block to allow me to disconnect the system easily without shutting everything down; on top of the switch (about 1 o’clock) is a hard-wired replacement that allows the timer in the boiler to do its own thing.  To the left of the controller is the cable to the outside thermometer.  Here’s what it looks like outside:

DSC_3547Does it work?  Yes, it does 🙂

The Web UI is graphing temperatures for all of the zones.  It’s interesting to see the saw-tooth gradients, an example of which is below.  In a bit I’ll post some graphs showing the differences before- and after- installation, to show the difference the system has made.  I had intended to do so my now but have been rather busy with a few other things.


But yes, IT’S ALIIIIVE! 🙂





Unflaky Pi and PiPower.

The last post was about the flakiness of the Pi; that’s now fixed. Overclocking didn’t help (returning clock to stock and removing forced_turbo increased uptime to about 16h) but what really did the trick was killing squeezeslave. This is a shame because I was hoping to use the Pi sensor as both thermometer and media extender; looks like that’s not an option, at least with the original Model B. Still, it now works.

Raspberry Pi Foundation have recently released the Model A. It has 256 MB of RAM compared to the B’s 512, one USB port and no Ethernet. This makes it perfect for a temperature sensor; very little going on and there’s only one USB port in use anyway. They’re also much cheaper (circa £19). Might put this down as a “further work” package.

Speaking of further work… the HVAC system is perfect for controlling the temperature of a beer bucket during fermentation. Same principle: temperature sensor feeds logic that activates a relay, in this case a Brew Belt. There are loads of other prospects so I think the next project will be a relay-controlled extension cable. PiPower! First though, to finish this one and fit the Boiler Controller.

Flaky Pi

Been having some issues with the PiTherm; crashing, one after about 5h uptime and one after about 47 seconds. At least that’s how many ICMP echo requests it sent back before crashing.

Last time something similar happened on the PC, I fixed it by switching PSU. A quick Google tells me the Pi is a bit sensitive to power fluctuations. I’m running the DS18B20, Wi-Fi dongle and SD card, plus the Pi itself and the wall wart is rated to 600 mA. Not an expert on power but it sounds like a reasonable hypothesis.

Upon inspection of the SD card, it appears I was also overclocking. Pi running at 950 MHz, forced turbo (i.e. always at full bore, never dynamically scaling back). I’ve changed it to stock and disabled forced_turbo; now seems to be consistently around 450 MHz.

Hopefully this will save a bit of power. It’s now stayed up 10 minutes; let’s see how it goes.

Taste of Pi

Until now, all of the electronicy bits have been based on an Arduino. This has a couple of advantages: Arduinos are cheap, simple and are designed for electronics. However, to communicated, they need a shield, which pushes the cost up. The Wi-Fi shields are prohibitively expensive and the Ethernet shields, well, require an Ethernet connection. There is an alternative: the Raspberry Pi.

Pis are slightly more expensive; however, you can pick up a Pi, including case and Wi-Fi dongle for circa £45 from somewhere like ModMyPi. This requires a full-blown OS (Raspbian Linux preferred), but this means it can do so much more.

I have four Pis; two of the original 256 MB ‘Model B’s and two of the newer 512 MB variants. I have one of the originals running as a squeezeslave (Logitech’s best music distribution tech, for free!); my plan is to add a DS18B20, meaning it is both a thermometer and music player. Win. One of the 512 MB versions will probably become the website on which the main processing is performed.

Electronically, I’ve wired the DS18B20 using “proper” (i.e. not Vampire) power. The Pi’s 1wire modules look at GPIO pin 4 by default, so this is where I’ve stuck the thermometer. Wasn’t using it for anything else, anyway.

DS18B20 Pi

The GPIO Connector Pinout identifies +3.3V as Pin 1, GPIO4 as Pin 7 and Pin 9 as a suitable ground. So I soldered some wires and then plugged them into a breadboard.

PiTherm Top

Note the data line still needs a 4.7K pullup resistor. This could be remotely, on a piece of stripboard – but I soldered it directly to the back of the Pi:

PiTherm Bottom

Yes, I modified a commercial piece of hardware. As a software engineer, I believe this makes me officially “bad-ass” 😉

Software-wise, the rest was a piece of cake. Inserting the kernel module (w1-therm; dependences automatically resolved, naturally) gives you a new entry, /sys/bus/w1, under which is the thermometer. A quick python script reads it and submits to the web server as with the Arduino code.


The temperature is the second line, given as “t=60062”. Divide by 1,000 to read the temperature. Yes, that’s 60 degrees – at the time of the screenshot I was testing my “sealed” DS18B20 in a cup of coffee 🙂

Next step to put my money where my mouth is and install it…

More reading: Cambridge University Computer Lab has an entry in its material for freshers that details the process in excruciating detail. See:

Soldering On

This weekend I’ve put the compiler behind me and have been getting my iron on.  And a bit of sawing, drilling and clipping (not to mention cussing).  It’s time to take this thing from the breadboard and make it real.

Not having access to a PCB machine, I’ve been making circuits on copper stripboard.  This is the stuff we used to use in school!  A bit of plastic with a grid of holes and strips of copper running length-ways.  Poke components through the hole, solder them in.  Occasionally (e.g. between fuse terminals) the tracks have to be broken.  For a tenner, you can buy a special “veroboard cutting tool”; I twiddled a 4mm drill bit and it did the job perfectly.  The stripboard can be sawn “across” the tracks with a hacksaw; going “down” the tracks is a case of scoring with a stanley knife and then just snapping it off.  Easy as.

It’s a bit nerve-wracking, soldering something in – will the heat affect the component?  Thankfully it doesn’t seem to!  Haven’t done much proper soldering since I was a kid doing my NRAE but I’m glad to report I don’t seem t have lost the knack 🙂

I decided to start with the most complicated part – the boiler control.  This needs a circuit board for the external thermometer (c/w connection cable – I had some twin-core mains laying around), a board for the relay circuitry and a board for the status LEDs.

Didn’t take lots of photos here because I just wanted to crack on – but here are a few that I took during the process…

The first component to be soldered in was the DS18B20+:

This is what the back of the thermometer PCB looked like after I’d finished soldering it together.  I cut two holes where I’d originally intended to put a resistor, then realised that would mean I need to run three wires out to the thermometer and I only had twin-core.  I figured that by bringing as much “indoors” as possible, I could get away with only running two cables out – so I bridged the cut track with a bit of wire, which you’ll see later.  But of a kludge but works just fine 🙂

Here’s the remote part in its box.  I bought a project box from Maplin for a couple of quid, drilled a 6mm hole for the cable and two 4mm holes for the screws to mount it on the wall.  There are also three tiny holes in  the bottom for drainage (just in case). I plan to glue the board in with a hot glue gun in due course.

To the main unit… LHS is the Arduino, RHS is the board.  Relay at the bottom; on the LHS will be the AC throughput (with fuse); on the RHS is the feed to the thermometer.  I couldn’t finish it tonight because I lost one of the screw terminals so I’ll have to buy another, irritatingly.  Spaghetti wires connect it to the Arduino.

This is the unit with the relay status light proudly indicating that the CHS should be on:

And this shows what happens if the box can’t contact the web service:

This is what it looks like together; this was before I’d fitted the LEDs:

The LEDs were fitted by drilling a 3mm hole in the plastic and then just pushing them through. Easy enough, might not even have to fix the stripboard to the plastic!

Almost done with this now – just need to get the second set of screw terminals in and then we’re done.  Then it’s a case of installing it, building the thermometer and writing the python controlling script!

Winning Gold in the 230V Relay

Hooray, an Olympic pun.

The next major component is to be able to trigger mains voltage.  Being entirely software, this scares me somewhat.  Still, how hard can it be – it’s AC, right?

For this, I’m using a relay by finder ( CPC code SW03899).  I chose this by searching for relays and then filtering down to those with a contact voltage of above 230V (250V will do) and a coil voltage of 5V, as supplied by the Arduino.  I also needed a couple of screw terminals (RS code 467-0271).

The relay is pretty simple. It has two pins on the left for your 5V switching current and three on the right for your 250V output.  The middle of these three is common; when there’s no voltage on the input, the left two of the three output pins are connected; given 5V, the relay switches and the right two output pins are connected.

The former mode is useful as it’s essentially “fail on” – if the kit breaks then the relay will close, meaning we’ll still have heating.  This means a switch in the logic though, so for now I’ll use “device on = switching current on” as it’s more straight foward.  It’s only flipping the logic to change.

The other thing I’m doing here is adding an LED – so I know whether the relay should be on  – and a temperature sensor, the idea being I can stick it outside and log it.

All the software is as before – re-used network code for reading device status and submitting temperature; easy enough.

Worth stating: I know wiring it all directly is bad.  There needs to be a fuse and, in the finished system, there will be.  There’s only other potential problem, too – back EMF.  The relay is based on a coil.  If the relay breaks and the AC affects the coil, it could theoretically send a large current back up the 5V channel and into the controlling device.  This can be fixed with an opto-isolator, which is essentially an LED connected to the controller and a light-sensitive switch.  Signal high, switch closes, 5V source connected to relay, back EMF sends current to the (fused) source.  One problem here, though: the only 5V source I have is the Arduino, so the same bit of kit would get nailed.  Nice idea, though!

One gotcha through this process: I have to keep track of two timers to see how frequently I should submit temperature readings. In doing so, it never seemed to work and seemed indeterminate. Turns out I was storing my 32-bit timer value in an int – and the Arduino is 16-bit! Quick switch to a long and all was well; it shows how easy it is to make assumptions based on a given platform.

Not going to include a circuit diagram as it’s really too easy.  Instead, I’ll close with something better.  Enjoy 🙂

Of Mood Lamps and Sensors

So, the next stage is to read the temperature from a sensor and submit that to the database. The network code is pretty standard, based as it is on the previous post, so it’s the sensor bit that’s important.

I started tonight’s session by making a mood lamp. I bought an RGB LED (CPC code SC11728); this looks like a chip but is three LEDs in one package. Based on previous code, it was fairly easy to randomise an RGB value and set it, then wait a few seconds, re-randomise and fade smoothly. Amazing what cool stuff you can make with very little effort and know-how 🙂

Project-wise, I was looking at the Dallas DS18B20 (CPC code SC10426). This is a digital thermistor that sits on the Dallas One-Wire bus. Previously, this was something I’d only seen when configuring a Linux kernel; now, it’s time to use it.

The DS18B20 can be powered in two ways: regularly or parasitic. The latter means you need to run one fewer wire to the component but can cause a 750ms delay in reading the temperature. That’s not such an issue for me, so I went with parasitic mode as my book instructed me. The book also told me to use a 4.7K pull-up resistor; however, I didn’t have one of those so I used two 10Ks in parallel instead (R = 1/(1/R1 + 1/R2)). I figured 5K would be close enough; I have some 4.7Ks on order (Rapid code 63-1376).

The circuit diagram looks like this:

DS18S20 (Parasitic Power)

Multiple One Wire components (of which the DS18B20 seems the most common) can be strung together on one wire, which is ace because the Arduino has limited pin availability. You just connect all the ground pins and all the data pins together and hey presto! However, the accumulated lag could be irritating so I’d probably go with regular power rather than parasitic.

The Arduino IDE doesn’t come with One Wire or Dallas Temperature libraries by default; however, they’re readily available with a quick Google and installation was a case of unzipping them into the right place. The library provides methods for reading serial numbers of every device on the bus, reading the temperature, converting to degrees C or F, all the stuff you need. Decent enough.

So, a little bit of C++ to read the device and then existing network code to submit to the DB, which logs the reading and records the time against it. It also notes the “check-in”, which might be useful for diagnostics later. Pertinent code fragments as follows:

const int oneWirePin = 3;
OneWire oneWire(oneWirePin);
DallasTemperature sensors(&oneWire);
DeviceAddress thermometer;
const int temperaturePrecision = 12;

sensors.getAddress(thermometer, 0);
sensors.setResolution( thermometer, temperaturePrecision);

Network::SubmitReading( zoneId, sensors.getTempC(thermometer) );

Was pleasantly surprised to see that the thermistor didn’t require any calibration – it just worked! By holding it between finger and thumb, I could see the temperature rising. Job done.

Apart from the “productising”, that’s effectively the remote sensor part done 🙂 Or could be. There’s still the option for a Raspberry Pi variant using the Pi’s GPIO pins. That might be useful; for example, the lounge or bedroom media players could double as temperature sensors. For now, though, the Arduino version is just fine 🙂

The most complicated LED switch Ever.

Component: Boiler Controller

For my second day Arduino-bashing task, I decided to make the LED database-controlled. The idea is that I can switch the LED for a relay and I’ve essentially built the boiler controller.

I run a Linux server at home with a standard LAMP stack; a few lines of PHP and SQL later and I had a basic database that could keep state of a number of Devices and a web service that could be queried for a device state and would return a simple 1 or 0.  While I’d normally return some XML or JSON, I’m going to be parsing this on an Arduino with 32k of code so the simpler the better.

The LED circuitry was the same as before – a simple LED.  The new part here was the network connectivity.

The Arduino Ethernet Shield comes with an API that allows you to establish up to four TCP connections, either as client or a server.  For this, we’ll be a client.  One of the neat things is  you can specify your own MAC address; I chose 0xDEADBEEF0001.  Impressively, you can either specify static or DHCP-based addressing and it’ll do name resolution as well.  I’d love to capture a few packets and see what the stack generates on the wire and how similarly to “real” stack it behaves; one day I’ll get around to it 🙂

Connecting to the server and submitting the GET request is as simple as follows:

DNSClient.getHostByName(serverAddress, &ip);
if ( !client.connect( ip, 80 ) )
Serial.println("connection failed\n");
return false;

client.print("GET /~hjs/hvac/services/getstate.php?did=");

The client object has a method that denotes whether data is available, so I busy-waited on that until it became true (no other process on the CPU!  Just me! Muahahaha!) and then started reading bytes.  I was expecting to have to read until I received two newlines, then take the next character; however, I’d forgotten that the GET syntax used wouldn’t result in any HTTP headers, so the byte I was after was the very first on the wire!

Having abstracted this into a nice little Network class, it became then very simple to poll the webserver periodically (every 1/2 second initially) and set the status of the LED accordingly.  From this point on, the LED could be turned on or off by setting a field on a row in the DB.  Job done! 🙂

It makes me dizzy thinking about how many layers of tech are involved just to turn the LED on or off; however, it was all pretty straightforward.

So, Boiler Control report card:

What’s Done:  Database control

What’s Left To Do: Mains control (not just LED); temperature sensing and submission; network connectivity

Components: Arduino Uno; Arduino Ethernet Shield; (breadboard, LED, 150 Ohm resistor)


First taste of Arduino

So, where better to start than with the thing about which I know least?  Hello, Arduino.

To make stuff with the Arduino, you jack it in with a USB cable; electronic bits are wired together using a breadboard; this is essentially a massive set of plugs that are connected in strips.  If you don’t know what one is, Google it.  They make it really easy to make connections without soldering.  This is good because you can fix stuff when you break it and your first stupid LED circuit can be torn down to make something better.  So, to that first stupid LED circuit.

The Arduino pumps out 5V.  My LEDs take 1.8V at 30mA.  To make these work, I need a potential divider – a resistor to limit the current.  The formula is: R=(V-VLED)/I. This works out at 107 Ohms.  Apparently, resistors are at intervals and you choose the next one up – 150 Ohm it is.  The circuit looks like this:

Programming the Arduino is pretty easy.  The IDE, however, is rubbish.  You have to download a specific Arduino IDE that includes the cross compiler and everything needed to manage the device.  The device management side is really well done but the bit you use to write code sucks.

Coding itself is in C++; nice and familiar.  What isn’t familiar is being limited to a 32k binary.  Thankfully the IDE tells you how much space on the chip you’re using and I’m nowhere near it.

Controlling a LED is easy; connect it to one of the output pins on the Arduino and use a function call to set the state of the line to high or low.  There’s a nice API for all the basic stuff (writing, reading, delaying, etc) and the documentation is pretty sweet too – all on the Arduino and AVR websites.

Reading a button push is a bit more complicated; the button goes between +5V and an input pin.  When the button’s pressed, the input is definitely high; however, what happens when it’s not?  Input is low, right?  Not necessarily – apparently it’ll float anywhere between 0V and 5V.  To fix this, I learned you need a pull-down resistor of about 10K Ohm between your input pin and ground.  This means any floating charge is dragged to ground; the high resistance stops short circuit when the button is pushed – and, because the ratio of resistance-to-ground vs resistance-to-input is 10K Ohm vs 0 Ohm, the full 5V will go to the input.  Least, that’s how I understand it.  If I’m wrong then please stick something in the comments 🙂

For consistency, here’s a circuit diagram:

At the end of the evening, I had finished Chapter 2 of Beginning Arduino and had a nice little system that emulated a pedestrian crossing, complete with button push and five-light sequence.  Baby steps – but it’s hardware and it’s working!

Note I’m deliberately not including a component list because this isn’t directly to do with the HVAC system. Any decent Arduino Book will provide all the info needed.

System Overview

System Overview

System Overview

Most thermostats say what the temperature of a room should be. This system should set schedules, with a target temperature and time; for example, “I want the room to be 20oC by 7am.” The system should make this happen.

The system will be network-based. IP networks in the home are commonplace and easy to integrate with. I could use X10 or Zigbee but I don’t need to. One thing at a time. This does mean I’ll need switching fabric; happily, I have plenty of that in the house 🙂

The system must allow the temperature of numerous zones to be recorded and logged. It must be possible to chart and analyse historical data.


The overview of the system is given below:

System Overview

As you can see, there are four chief components, each of which is outlined below:

Component 1: Web Service
This is responsible for collection and dissemination of data. It’ll allow the thermostat to record temperature in rooms and will allow the boiler to find out whether it should be on or off. It’ll also be the main UI and will allow the user to configure schedules.
In the future, Android/iPhone apps will talk to the Web Service to do their magic.
Component 2: Boiler Control
This is the dangerous bit because it involves switching the thermostat line of the boiler and that runs at 230V. It’ll talk back to the web service by a standard HTTP/TCP/IP/Ethernet stack and will comprise an Arduino Uno and Ethernet Shield. It will physically be in the garage; I may well run a cable through the wall to log the external temperature as that could probably be used for some analysis.
Component 3: Thermostat
This is the bit that records the temperature; it’ll log it to the web service using an HTTP/TCP/IP/Ethernet stack as above. It will comprise either an Arduino and Ethernet Shield or a Raspberry Pi. There’s a trade-off to be made involving portability, cost, power source and complexity. I’ll think about that later.
Component 4: Control Logic
This component is responsible for reading temperatures and deciding whether the boiler should be on or off. No pressure, then! It’s another opportunity to learn so I’ll be implementing it in Python (which, TBH, I should have learned a long time ago).
Initially the Control Logic will be pretty basic (say, turn the heating on 1/2 an hour before the target time) but, in time, will be expanded to do things like learn how long the house takes to heat and adjust the start time accordingly. That could be tallied to external temperature to increase accuracy…



Boiler -> Boiler Control
230V AC line. When closed, the boiler is on; when open, it’s off.
Boiler Control -> Web Service
HTTP / TCP / IP / Ethernet. Ethernet may be over mains or I may run a cable into the next room so I can plug it into the switch.
Thermostat -> Web Service
HTTP / TCP / IP. Hardware layer may be Ethernet (we’ve got some kind of network presence in every room) or it may be Wi-Fi. This will partly depend on the solution chosen; the Arduino will be limited to Ethernet but can be battery-powered whereas the Raspbery Pi can use Wi-Fi but requires a wired power source. Probably.
Control Logic -> Web Service
HTTP / TCP / IP / Local. I intend to run this on the same box 🙂

That’s an appropriate level of design. Now all that’s left is implementation, testing and TTO.  To the breadboard!