I'm using current transformers (200A) that clip around the main power lines coming into the house. These feed one of the analog inputs to an Arduino Duemilanove. I also sample the wall power level to give me a voltage reference and use a basic wall wart for power. Originally I had a Wishield for wifi since there is no network connection near the power panel, but Wifi proved to unreliable over time. I changed my link to an XBee and eventually installed them all over the house.
Most of my implementation was blatantly stolen from Trystan Lea. Please visit his site at http://openenergymonitor.org/emon/ for an in-depth discussion of his ongoing implementation. I took his Arduino code for power monitoring, modified it to work with two current transformers, and added network code to serve data based on a simple html request. Trystan has single phase 240 power and didn’t need to consider using double CTs, but don’t worry, you simply tie the two of them in series if you have split phase 220. My device hasn’t made it past the breadboard stage. Why bother right now? It works fine and I can get back to it anytime.
Update March19, 2011: I had a failure of a WiShield in the power display that I will detail on that page later, but this pointed out that I need to have a wireless communication path that has massive availability. I chose XBee as the tool to use. Since this entire set of projects is for saving power, I started with the power monitor. After doing a bunch of work to enable the device to send over XBee radio I realized I had forgotten how I had built the darn thing. So I reverse engineered my own device to get the schematic and am posting it here to help other folks and provide a reference for myself next time.
Simple isn't it? Nothing but a couple of voltage sources and dividers to scale the values for the Arduino to read.
Update April 16,2012: After literally months of perfect operation, the device failed. I really don't have a clue what happened, but it quit transmitting power information over my XBee network. A simple reset got it running again which indicates the problem is, most likely, software, not hardware. I didn't get enough to fully understand the failure so I really don't know what to fix. But, since the device has been running really well for months, I just decided to put in an automatic reboot on a periodic basis to clean out any problems that may be building up in the code.
Initially, I wanted to get the correct time from the XBee network and set the Arduino clock for real, but when the Arduino is spending most of its time calculating, it doesn't leave much time for decoding a semi-constant stream of XBee traffic. See, each power reading takes about a second and the incoming data can easily get lost during that second. So, I just gave up on having the correct time on the little device. I added the timeAlarm library for the Arduino playground to the device to handle timing the reset. This allowed me to set up a timer that causes the device to send the power data every 5 seconds. This stuff worked perfectly. I don't know when the device will reset exactly, but it will at roughly 24 hour intervals starting from when it last rebooted.
When I came here to update this blog, I noticed that I never posted the code that uses my XBee network instead of the WiShield and ethernet. I also noticed that the drawing of the home network and photo of the device are way out of date. Guess I'll take care of updating those. I want to keep the WiShield code online to help people that want a web based device, so I'll have both examples here to confuse the reader a little more.
Notice that the comments at the top are almost as long as the code? Yes, I have trouble keeping track of the various problems, changes, and solutions to my devices over months of time. It's funny how often I come here to see what I did about a particular problem. Nice way to keep a diary of this kind of thing. Notice also that the loop() routine only calculates the power, updates the watchdog, and updates the alarm timer. If it hangs in a loop somewhere the watchdog will reset it and start over. Every 5 seconds the alarm code causes it to send the data; that's about as simple an implementation as I can come up with. The timers are set up in the setup() routine and the reporting is done using the callback routine reportPower(). The XBee for this device is set up in transparent mode; this is a specific mode for the XBees and you'll understand this when you start working with the little devices, but it means that I don't have to have special encoding or decoding software to use it.
Three people now have asked me how to put the CTs in series. It's actually pretty simple to do: first put them on the incoming power wire, see the picture of my power panel with the CTs installed. Then hook one color wire from one CT to the other color wire from the other CT. The remaining two wires are your input. Measure the input and then hook two wire of the same color together and measure again. You want the highest reading. Notice above that I have a black and white wire running to the center of the three screw input block; that's where I short them together. I just wrapped them together and screwed them down. The other two wires on the other terminals are my input.
Now, I'll let the device run until the next problem crops up.
Update, February 14, 2013: I decided to move the software forward from Arduino IDE 21 to the latest, 1.0.3. I expected this to be a pain, so I decided to make it worse and convert the XBee code to use the library created by Andrew Rapp. I noticed a while back that the library had been updated to work with Software Serial and supported the multiple serial ports on the Mega2560 board. This means I can still use the software serial pins and have the normal serial pins for debugging and other things.
Well, it turned out to be pretty painless. Yes, there were a few items that I had to work out, but it took less than a morning to make all the changes and return the device to service. The code was greatly simplified by using the library, although I now have the XBee running in API mode 2 to fit with the library. This is OK though since I discovered that I can monitor it with a little XBee sniffer I put together, or tell the XBee to transmit in broadcast for a while if I think there are problems. Here's the updated code:
Of course, I have the XBee handling in a separate source file (these are known as 'tabs' in the Arduino IDE) so this is the code that resulted from moving to the XBee library:
Notice that I have both the addresses for the House Controller and Broadcast in the file. All I have to do to revert to broadcast for debugging is to use the broadcast address. Nice little capability; I may automate that in the future.