Update: I have a much better solution (and meter), the ECM1240 from Brultech, read about it here.
Ok, the title is a mouthful, but that's why it's been about 6 months since I started and I have results to show for it only now.
My goals were to get:
a daily summary of power use per hour
have enough data to recreate a PG&E bill on a daily basis before we get it (to be able to predict whether we're using electricity in the right amount and at the right time before getting the bill).
more importantly, be able to drill a bill down to the day and the hour (we have data updates every 2mn) and see how much more power the house is using if the dishwasher is on, or the electric toaster oven.
get a real sense of how much our AC is running and how much it costs.
For this, while ordering the Solar Panels (aka PV system) from Cobalt Power, I asked for a monitoring system and the only one they found at the time that would allow monitoring of both the PV production and the PG&E Meter was a third party One Meter from One Brand Electronics.
It looks like this:
the meter that does gathering and resending to my monitoring server
the probe gathering boxes (gets volts and amps)
The voltage probes are simply connected to the lines and those are precise. Unfortunately, I don't care about voltage nearly as much as current sinc ethe voltage tends to be known and the current is what affects your bill.
It's a reasonably easy solution to add to any setup during or after the fact, but the low points with the Brand Electronics One Meter solution are:
by design the current measured is inexact. I see current used on the PV inverter when it's not supposed to use much of anything, and of course I also see random small currents in either direction on the AC when it's off.
while the data gathered is good enough for general trends, longer term use has shown that it can be off by as much as 40Kwh/month on my PG&E Meter, which is a fair amount.
the One Meter interface is really bad. I'm a linux CLI guy, but it is bad. It is impossible to change its basic configuration like what it sends over telnet and at what interval without having its firmware reburnt by onebrand, but get this: you can't even change the IP address it'll talk to either without sending it back.
it has a serial interface for configuration that is quite poor and it'll dump old data you might have missed in a different format that what it sends over telnet to make your life harder.
it is a very slow microcontroller that is so slow that it takes over one minute to send 12 samples of data
it is of course unable to set its own time over ntp and is unaware of DST, so I just put mine on UTC and I fix things on the server side.
last, but not least, it will randomly corrupt itself and send totally bogus data points. Thankfully it however recovers at the next sample. I had to write fairly complex code to analyse the data samples, detect and throw away bad ones.
Ok, so are you sold yet? :)
this shows the CTs that measure current from their induced magnetic field
Well, it's not that bad now since I went through the effort of writing the code to deal with all this. So, if you were to get one, you'd be up and running pretty quickly if you can hack perl, the language I used for my magic script that does all the work (see the bottom of the page for source code).
The above script took a fair amount of time to write since outside of working around quirks in the One Meter output, I wrote in the PG&E billing logic for California and it is able to output per hour per day production and use, as well as equivalency in dollars. Converting into dollars make sense since with TOU (time of use pricing) you can end up with days where your used more than you produced, but the end bill is still negative.
This is a typical example of a summer day (July 8th picked at random):
Yellow shows partial peak rates, where it's good to have the meter run backwards, and red for peak rates when it's even better. Unfortunately the solar panels are facing south east and south instead of south west where they would produce more when electricity is worth more.
That is a more interesting example in September showing that despite having used more electricity in a day than what was produced, the daily bill was still negative thanks to the time of use magic, even it our case where we only get partial benefit from TOU due to the sub optimal south east angle for some of our panels:
If you want to see other days at random, you can pick them from here.
Now, a per hour text output is useful to see how we did on a given day, but it does not let you see your power usage in the last 10mn after you turned something big on or off, or how all of last week looked, or see a month's trend at a glance.
This is where cacti comes in. I spent a fair amount of time looking for a graphing solution that would keep all my data and let me zoom on any portions I wish. Quite frankly, the fancy widget that google uses in google finance would have been what I was really hoping for, but baring that, cacti came like a reasonable alternative.
So, I came up with a compound graph that looked reasonable, and the option to see all the graph items separately.
So since this is about solar panels, one of my questions to Cobalt Power was why my system was spec'ed for 5Kwh at peak and why I was typically seeing 4.5-4.7Kwh at best. The reason is that 2/3rd of the panels are pointing south-south-east and the remaining 3rd is pointing due south.
What this means is that our system doesn't actually peak at one time and then drop off. The graph clear shows that the PV production takes longer to peak and then stays at that lower peak a bit longer before dropping off more sharply. So, the production at the end of the day is still the same, but just with a slightly longer and slightly lower peak. Too bad the peak is on the morning side as opposed to the afternoon side when the electricity is worth more.
You'll also notice the sharp start which is when the sun goes high enough to reach the roof over the neighbours' houses across the street. You'll also notice the jigsaw drop on the way down as the sun starts to get hidden behind some branches in the high trees blocking our west view.
This graph and the graphs below are selected in zoom mode, so you can use the mouse cursor to draw a rectangle on a time region and the graph will refresh on the time slice you selected. Note that you can also zoom out by clicking the graph with the right button:
Below is a closeup of all the colors showing AC working hard in bursts while the black PG&E meter line goes from sometimes negative to always positive the green area of solar panel energy offset goes down to 0. Blue then shows the basic house energy usage with the red peaks on top showing AC tripling the house electricity use when it's running.
In other words: the red line is the AC use, the blue is the rest of the house use, red line goes on top of house use gives the red area which is total house use. You then remove green which is production from the solar panels and you end up with the black line which is what the PG&E meter actually sees. Confused yet? :)
Here's a typical day without AC use since we weren't home:
Here's a very warm day with AC (keep in mind that you can zoom in by selecting a time slice with the mouse):
and a glance at just AC use during a few hot days in July:
Here is a link to an historical view of this graph at multiple time sample levels. Try the zoom function (magnifying mirror next to the graph) on the yearly graph at the bottom and you'll be able to zoom on random time in the past.
Another view is each probe graphed separately for a less cluttered view. Note that the AC view is pretty useless right now as it's only showing noise picked up by the coils, but if you click on it, you'll get the multiple timerange view as above and can view more interesting months, like the July zoom above.
Well, I had written some somewhat complex code to actually keep up of production for each tier and find out if I went into tier 2 to 5 (which pay or cost more per unit of energy), but because the One Meter gives me somewhat inaccurate readings, especially on the PG&E side, the numbers were just too far off to compute a bill that was close enough to the actual bill I was getting. So, I unfortunately had to give that part up.
It would otherwise have been nice to know in advance if my use or production for a given tier was going to exceed tier 1 and possibly adjust electricity use accordingly, but I'll need a more accurate measuring device than the One Brand one.
All this ended up being a fair amount of work, which with not that much extra work could have been a service that all solar companies sell. I think a few do, but I'm not sure if it's as complete as what I did, or if it is, please let me know so that I can compare with their work.
Anyway, if it's useful to you, here's the parsebrandpower script. Please note that if you were planning on taking it and selling service based on my work, it is protected by the GPL 3 copyright which you must understand and apply if you are going to use it. I also request that you contact me and let me know if you're going to use the code.
For more details on cacti integration, see my Gatewaying 1-wire, XPL (Oregon Scientify Weather), Brultech ECM1240 Power Data, and Brand OneMeter Data to cacti page.