Watts-your-consumption? - Wireless Power Meter

I've recently become somewhat obsessed with understanding how much electricity our home is using. There are certainly commercial offerings to allow you to monitor the power consumption in your house and there are also award winning kits available but these don't quite cut it for me for a couple of reasons:

1) Why buy something when I can frustrate myself? In all seriousness, I've been looking for a project that will hook together a number of different interests as well as to being sufficiently large that I have to break the problem down into a number of discrete parts.

2) A lot of the solutions look at monitoring by measuring in series with an appliance (or extension cord) from a plug as oppossed to the whole house. I think the ideal solution is a combination of both but the majority of documented projects concentrate on the plug side of things.

3) The UK is somewhat behind the curve in offering smart metering and measurement so I want to provide a local example for a change!

In the UK, as houses are slowly upgraded to new digital meters, the handy hacker has access to a means of monitoring without worrying about induced electric fields (e.g. measurement through Hall effect sensors) or through cracking open the meter itself (which would no doubt get you in trouble if not shocked!).

"What is the capability?" I hear you cry, well it's an LED that flashes for each 1/1000KWh consumed from the mains and as its a BSI certified product its reliable.

So this instructable documents the process of creating a device that monitors the number of flashes being produced by a UK Electric meter and sending the count to a computer for data logging and visualisation.

The system consists of two parts, a unit that sits in the meter cupboard (based around a photdiode, an Arduino, a DS1307 Real Time Clock and an XBee wireless board) and a computer based reader (an XBee via a USB explorer board and a Mac OS X logging application).

It can be used in conjunction with other solutions such as adafruit's Tweet A Watt to provide a very detailed picture of consumption within your home and gets you one step closer to having a home smart grid.

From my perspective this project has green credentials because if you can't measure your consumption, how can you begin to understand your impact? As an added bonus, if you can see when you use your electricity, you can start looking at how to cut back, not only saving the earth, but saving money too.

Step 1: Watt You'll Be Needing

Buying parts in the UK is an interesting process as there isn't as broad a base of suppliers who are targeted at people like you and me.

In addition, I also bought the parts over a series of months as I switched around in terms of what projects I wanted to try and complete (as well as watching the GBP/US Dollar rate slide from nearly $2 to $1.35).

I've decided to group the parts list by the supplier that I used. I am pretty certain that people will have their own preferred supplier and I would also plug Octopart if you live in the US to find your own bargain.

Sparkfun
2 x XBee 1mW Chip Antenna
1 x XBee Explorer USB
1 x Arduino NG
1 x Arduino breakout board

Adafruit Industries
FTDI cable
Boarduino

Tinker.it (Actually a UK provider of some Sparkfun boards and Arduino training)
2 x Breakout Board for XBee Module
4 x 2mm 10pin XBee Socket

Farnell UK
1 x Photodiode
1 x LD1117 3.3v voltage regulator

Futurlec
1 x DS1307 Real-Time Clock Mini Board

Miscellaneous
1 x 3mm Red LED
1 x 3mm Green LED
1 x 3mm White LED
1 x 10K resistor
1 x 1K resistor

From browsing through the various suppliers its obvious that there are variations in price and shipping etc. so I guess its a case of going with what you feel most comfortable with.

Step 2: A Flash Counter

The first building block I required was a means of counting the flashes from the power meter, so I could calculate power consumption.

I didn't know a great deal about photodiodes before I started this project aside from that they sounded like what I was after. E.g. when in the presence of light a current will flow. I certainly wasn't aware of the different modes of operation and for a while I was confused as to how to proceed. In the end I decided the best approach was to hook up a scope and just try a few configurations. So having soldered some test leads to a photodiode I got a small torch and then measured the output in the presence and absence of light. The circuit diagram shown illustrates where I ended up in terms of resistor value and configuration.

Having determined that I could get a measurement on a scope I wanted to make sure I could get things hooked up on the Arduino. So the following circuit and code was put together and I wired the photodiode up to pin 2 (one of the default pins for Arduino interrupts) and an LED to pin 7 for debugging. I verified that when I flashed my light source, the interrupt got fired and the LED lit.

Note: I chose to use a rising edge condition (i.e. a voltage state change from low to high on the input pin) on the interrupt as observations from the scope indicated this was going to be the most reliable method.

At this point the first of my building blocks was in place. I had a reliable means of counting the flashes of an LED and consequently a counter value updated by an interrupt routine.

Step 3: The Time Keeper

Having got the first building block in place my next step was to create a way to capture the date and time against the flash count so I could perform mathematically averages to determine power usage over time.

So I moved on to the Real Time Clock piece of the puzzle. At this point it is worth discussing why there is a RTC in the circuit. One approach to solving my problem would be to simply send a raw counter from the Arduino and then do all of the heavy lifting at the receiving end. However, on reflection I liked the idea that I could use the battery backed RAM on the DS1307 as a store for my counter and that my "packet" of data would be able to broadcast the time that the count was accurate. This may seem like an odd decision but I think in the long term its going to serve me well.

The DS1307 is an i2c device and there are a number of articles on the device on the internet (as well as interfacing to an Arduino), so I am not going to concentrate on the ins and outs of the device. Instead I shall illustrate a pitfall I came across and the eventual design I went for.

My initial idea was to have the DS1307 RAM be the store for the counter and that during the interrupt handling routine I would read and then update the counter. However, I discovered that whilst the Wire library in Arduino is really useful it won't work in an interrupt routine (which is fair enough).

My second approach, which worked, was to maintain a counter in the Arduino RAM and then, after a configured delay in the main loop, write the value out to the DS1307 RAM.

The circuit diagram shows the connections for the DS1307 and how I hooked it up to the Arduino (note that the Futurlec mini-board I used already has the required pull-up resistors and therefore they aren't shown on the diagram).

So now I had the second building block in place. I had a means of capturing a date and time and a counter value updated by an interrupt routine.

Step 4: It's All About Communication

Having got building blocks one and two together, I needed to be able to broadcast the results wirelessly (as my utility cupboard is someway away from my machine).

At this point I re-read my copy of Making Things Talk (see references in step 7) and saw that it would be a good idea to upgrade the firmware of my XBee's to the latest version before starting. At this point I entered a week long period of frustration as I couldn't reliably connect to the XBee devices using the XBee USB explorer board on my computer setup (a MacBook Pro running a Vista Ultimate Parallels session). I went round and round the houses and eventually got sufficiently good results be de-installing the FTDI drivers (that were installed by default when I first connected the XBee USB explorer board) and upgrading to the latest version from the FTDI website. Having been bitten by this on the windows side of things I decided to upgrade the drivers on the Mac OS X machine and then succeeded in stopping my Arduino from being visible to Mac OS X. So my lesson learnt is, if you run windows go with the latest version of FTDI drivers. If you run a Mac use the version distributed with the Arduino IDE (e.g. arduino-0015).

Having sorted out the software side of the problem (and having the ability to update firmwares and set various values) I struggled with my initial circuit. I was using the FTDI cable and built a simple circuit. But no matter how hard I tried I couldn't get the XBee to respond. Again the internet came to the rescue and following some top tips from the adafruit forums, I was told to check the voltage coming out of my regulator. Lo and behold, rather than the 3.3v I was expecting it was down at 2.1v. This was the measured voltage on the breadboard ground rail and once I hooked up a direct connection from the regulator output to the Xbee breakout board I was up and running.

Having got the circuit up and running and testing things out using AT commands it was time to wire it up to the Arduino for some programmatic control. Although I wanted the meter to be standalone and not be connected to a USB cable, I thought it would be useful to maintain the hardware serial connections for debugging purposes etc. Following pointers on adafruits XBee pages I downloaded and installed the NewSoftSerial library and wired the XBee up to pins 4 and 5.

The following code shows a number of functions that I wrote to issue AT commands to the XBee and provide a handy means of configuring the XBee as part of the startup of the Arduino.

So now we had building block three in place, a means to wirelessly transmit the time and count packet from building blocks one and two.

Step 5: Hiding It All in a Cupboard

So now I have something that can count and record flashes over time and transmit the data to my computer. The next step was to install the meter end of things in the meter cupboard!

The circuit diagram in this step illustrates the complete set-up up at the meter end of the device. All of the building blocks from the previous steps have been brought together.

I am in the process of creating a google code project to host all of the code from this Instructable and will post the URL when available.

As an extension in the future, I plan to implement a small control protocol that will enable the power meter system to be controlled without having to take it out of place, as well as to use power saving features in the XBee device to allow for extended running on a 9v power supply.

Note: at this stage I have kept the communication from the power meter device one way only. Whether something is reading the data that is being broadcast is not important to the meter end of the device.

Step 6: Watt Does It All Mean?

Having created a device that wirelessly broadcasts data from the meter, its necessary to read the data and provide a means of logging and visualizing the results. For this I decided to write a logging application.

As I wanted to get this instructable in to be considered for the Epilog challenge I kept the computer end of the device as simple as possible, I plugged an XBee into the XBee USB explorer and simply read the results via the serial connection.

Note: in the future I plan to use a second microcontroller and serve up the results via ethernet. Therefore providing a means to have the data logged and making it available on a network, without having to have the computer turned on all the time. Then a device (such as an iPhone) could query my power meter device and visualise results as they are recieved.

There are a multitude of ways in which the computer logging application could be implemented, as logging simply requires access to and reading from the virtual serial port created by the FTDI device drivers.

I feel comfortable coding in Java, Python and to a certain extent Processing, but seeing as I am trying to reacquaint my brain with its 10 year old knowledge of Objective-C, I decided to implement the logger as a Mac OS X native cocoa application. After some hunting around I came across the AMSerialPort code from harmless.de. This code provides a native means of connecting to the serial ports and the bundled example application helps get things up and running very quickly.

Note: there aren't too many examples of direct interfacing of Mac OS X and serial devices and therefore this instructable may be of use to people who want to become more familiar with how to do it.

As can be seen from the screenshots, the PowerMon application provides a simple means of connecting to the (obscurely) named FTDI serial port (trust me, when you have two or three FTDI devices connected things get very confusing) and logging the results of the power meter data in a text view. Behind the scenes the application is also writing the contents of the logged data into a CSV (comma separated variable) file.

Again for the sake of expediency, I decided that I would use the CSV data logging approach as a quick way of being able to import data into tools like Numbers and Excel.

Step 7: Watt Comes Next?

Power Meter Device Plans:
Obviously the tangle of wires on the breadboard is not a long term (or pretty solution) to stuff into the utility cupboard so I am planning to create a PCB to house the various component. As I am a fan of re-cycling the PCB is going to have 0.1" headers so I can install a boarduino as well as 0.1" header to hold the XBee breakout board. This will increase the physical size of the PCB but will allow me to scavenge the parts if I need them for another project. I also have a preference for this more 'Lego' based approach to device design.

Receiving device:
As previously mentioned I went for the path of least resistence on the receiver side of things and got a very direct route to the data via the XBee and an FTDI chip. Long term I want to construct a device that will sit on the network capturing the log information on an SD card and serve up the data via HTTP to whatever visualizer you want to use (e.g. a standalone Mac OS X application, iPhone application etc.) A topic for the next instructable.

iPhone enabled:
As aluded to above, my long term goal is to be able to monitor the power consumption of my house via my iPhone. Additionally, if I implement the control protocol I have in mind (see step 4), I could change the sample rate of the power meter reader and monitor the increase in consumption as I turn on an appliance.

References and thanks
I am not sure if it is good Instructables form to thank people but seeing as I have built up the concepts used here from reading good reference material, asking questions on forums and from friends, I think its only fair I tip my hat so others can work out where to go to to ask more questions and get help. Note, none of the suppliers gave me a discount or were promised anything, I just wanted to thank them for good service and supporting people like me.

Suppliers
Adafruit industries - great forum and Limor has some great tutorials and articles to help out on the XBee side of things.
Sparkfun - top service and always a pleasure receiving red box gifts from the US.
Farnell - the quickest delivery possible in the UK.

People
Zoe (the wife) for giving me some time off from parenting duties and household chores.
Dave Watkins for giving me the RTC from Futurlec and realising one day I may do something useful with it.
Tom Igoe for writing "Making Things Talk" and making me realise I could use that A Level electronics I got back in 1990!

References
The Art of Electronics - Horowitz and Hill (I bet Hill wishes he had put his name first!)
Cocoa Programming for Mac OS X - Aaron Hillegass
Making Things Talk - Tom Igoe
Stackoverflow.com - best place for code questions