Most modern energy meter have one or more LEDs which blink at a rate directly related to the energy used. The one above has two of them : one pulses at 1000 pulses per active kWh, the other one pulses at 1000 pulses per reactive kWh. I dealed with the active power only, event though I’m billed partially for reactive power also.

The idea is to collect the blinks of the LEDs in 5 minutes blocks. Twelve groups of 5 minutes-worth counts give an hour, then data are collected around 24 hours.

I used Processing to read to read the LED through a webcam and detect and collect the blinks.

Processing and its video library is the most obvious choice to me as I’m not much of a high-level programmer. Processing is well supported and gives instant gratification. It also runs on a variety of platforms, including my little Acer Aspire One where I managed to have processing run some time ago.

Grabbing the camera image is straighforward with processing : had to install vdig (vs 1.0.1) as instructed in the processing support forum and Apple’s Quicktime 7 which is the essential part to grab the video Everything went smooth, on my desktop at least. I couldn’t have it running on my Aspire One as vdig of course doesn’t run on it, and would have had to use a different library.

That said, I wrote a quick ’sketch’ in Processing to grab the camera, select with the mouse the “hot spot” of the meter (the LED) to minimize interference from the reactive power LED and ambient lights reflection. The code also represents visually the energy used in 5-minutes chucks over the 24 hours.

This is what is seen in Processing through the web cam. The image is upside-down because the camera is. But of course it doesn’t matter.

The LED area is selected clicking and dragging with the mouse. Some sort of dark cloth sleeve is necessary to pretect the camera from glare and reflection which might cause false or missed reading.

The camera view is activated pressing the “v” key on the keyboard. Click and drag a square around the LED. When done press any other key to turn on the count reading window, the one below :

The bars represent the total reading for a 5 minutes slot starting from 0:00 to 23:55 hours. The height of the bar is the reading (in my case 1Wh per pixel) and is incrmented every blink of the LED (1 Wh gone). Hovering the mouse on window (do not click on the window) returns on the top left the reading (kWh) for the time slot on the extreme left. Click on the image above to go to the flickr’s noted version for what the peaks are due to.

On the right of the string is the total reading over the last 24 hours.

A reasonably fast PC is necessary though to catch the quick blinks and evaluate the very frequent counts during peek energy requirements. And I didn’t want to dedicate my main dual core desktop PC to the purpose.

For now I did not design any mean to read remotely the data. Of course it is probably nonsense to keep continuously a fast-power hungry PC for the purpose. The Tweet-a-watt is a better option, with remote reading option also.

But I wanted to try this.

Version 2 !

It would be faster and less processor intensive to use an external event derived from the blinks and input it somewhere into the PC and log it with Processing.

I went for the “recycle way” and took apart an old mouse (well, no so old) and hooked the following circuit to the left mouse button : the light of the LED makes the TIL78-like phototransistor go into conduction which triggers an ever green NE555 (in the shape of a CMOS TLC555). The monostable in turn makes the NPN transistor close the relay which close the left mouse button of the mouse. Simple yet effective.

Side effect : the mouse can’t be used for anything else during count accumulation, otherwise the counts are affected, obvious. A dedicated external USB I/O device would solve the problem but this cost zero.

The purple wires are hooked to the coil of the relay inside the mouse.

The sketch for Processing for photo transistor version is here.

The sketch for Processing for the web cam version is here.

Have fun.

Alessandro