Metering The Smart Meter: part, the 4th

I’ve made some significant progress in measuring those pulses from the smart meter that I talked about in previous blog entries. The IR remote receiver was a total fail in reliably receiving them as they weren’t modulated that way, or in any way to make their reception reliable or easy to manage. It’s just on/off once for each watt hour used.

So i built a new sensor to velcro over the LED on the meter. This one has just a phototransistor and some resisters, the values of which I failed to record and cannot remember. So i’ll have to sort that back out again before I can make more of them. I did some math to decide what they should be but have cleaned up the lab since then and the notes are gone... Need a notebook rather than scratch paper I think.

I’ll post the software when it’s all working. The problem with a phototransistor is that you have to measure the output on an analog pin. You can’t just get a nice pulse of digital on/off. So that means sampling in a loop and comparing the values. Though that phototransistor is in a black casing which reduces it’s sensitivity to regular light it still changes it’s values significantly when the sun is shining on the meter.

This makes it difficult to just pick 2 readings and call one the ON threshold and the other the OFF threshold for the LED. What I finally did was to save each loops reading into a buffer of an arbitrary size calculated that even for the lowest power use it will always contain samples from on and off. Then I walk that array and take the min/max of the values. Finally I create an ON threshold at a quarter of that difference above the min, and the OFF at a quarter below the max.  These numbers adjust during the day as the light levels change and make sure that it can always tell the difference between an on and an off.

I still get the rare oddball pulse. It’s so reliable in it’s timing that it’s either real coming from the meter or that is the shortest time frame that can be calculated with the arduino that I’m using. I’ve added code to ignore a pulse if the calculated power usage is more than 150 amps. It is possible that this might actually ignore a real peak power usage starting up a large AC unit with a hard start kit on it or something like that, but thats probably an unlikely occurrence that wont change the overall calculations that much.

Once doing that I am now reporting to XTension a value for the last reporting period, at least 5 seconds between reports, the number of pulses counted for a more accurate overall usage than adding the calculated values together and lastly the average power usage for the period and the peak usage for the period. All together making a very nice graph inside XTension.

thats just the AC cycling on and off the other morning. Interesting the compressor profile there where it uses a lot of power initially (though no big startup spike) which drops off and then as it comes up to full operating pressure returns almost to the starting load. Does it every time too.

This one is me cooking dinner the other day and you can see the electric stove elements cycling on and off and the spikes they generated when they first turned on. The graphing software needs some help there calculating the x axis lines ;) Dont know why that is so bad looking, but I never tested it with such a wide range of values.

This reports up to XTension through the serial port of an xBee, the next project will be to get it working with the wifi version of the xBee which I just received a couple of from Digi and will start messing around with shortly. Adding support for those and the traditional xbee radios to XTension really opens up a lot of possibilities. Here’s the Wifi one: