Click to enlarge

PVWatts is a website run by the National Renewable Energy Lab (NREL) which can be used to estimate how much energy a given solar array might produce, based on historical mesurements of insolation.  If you ever have a site analysis done, the installer will probably use it to estimate your potential for annual production, and you might wonder how close the the mark it’ll be.  Now that I’ve had solar PV for almost 2 years, it’s interesting to look at how close the estimates were for my situation.

Once you choose your location, you input a few other bits of information such as array size (in kW), orientation (tilt & azimuth), and a derate factor (more on that later).  If it’ll be a tracking array rather than a fixed array, you give it that information as well.  I have 11 230W panels, due south, flush mounted to a roof pitched at about 33 degrees.  So, I entered:

• DC Rating (kW): 2.53
• DC to AC Derate Factor: 0.817
• Array Type: Fixed Tilt
• Array Tilt (degrees): 33
• Array Azimuth (degrees): 180

There are a couple of items to note.  First, the DC rating.  Although the nameplate wattage of all my panels adds up to 2530W, the Enphase M190 microinverter under each one has a max output of 190W (in practice, it gets up to 199W).  So even on a perfect day, the array maxes out at about 2190W:

Click to enlarge

However, this doesn’t happen very often, and when not “clipping” like this, the modules are performing as 230w panels would with any other inverter, so I left it at the nameplate value.

Second, the Derate Factor.  This is essentially a measure of the aggregate efficiency of DC to AC conversion.  The default in PVWatts is 0.77, but Enphase recommends a slightly higher value of 0.817 due to stated efficiencies of their system.

If you look at the graph above, some months outperform, others underperform.  In the first full year, I produced 3209 kWh, and PVWatts estimated 3448 – so I produced about 93% of the estimate.

There are a couple of reasons for this, I think, which are related.  PVWatts assumes no shading (although it can be incorporated into the Derate).  In reality, I do have some trees and some snow.  If you look at  the winter months, I fairly drastically underperform the estimates, and I think snow is the likely culprit here, despite my best snow-clearing efforts.

And year round, I do have just a little shade from my neighbor’s trees – this was known at the time of install, because my installer used a Solar Pathfinder [amzn] (see here for how it works, a very cool tool) for the site survey, and it put efficacy right at about 93% after accounting for shading.

So overall, I’d say that if a site assessment is done properly, you should absolutely be able to trust the estimates, based on my experience.

(Click to see full size).

I added regression lines this time – btrfs should catch xfs around kernel version 3.8 or so. 

Again, I draw no strong conclusions from this – I just think it’s interesting to see how things are moving as these filesystems evolve.

I used CLOC to count lines; the numbers on the graph reflect no blank lines & no comments.  For ext3 & ext4 I included jbd[2] and some of the peripheral files they use; code snippet from the script:

ext3lines=`cloc fs/ext3/*.[ch] include/linux/ext3*.h  fs/jbd/*.[ch] \
           include/linux/jbd.h fs/mbcache.c include/linux/mbcache.h \
           | grep SUM | awk '{print $5}'`;
ext4lines=`cloc fs/ext4/*.[ch] include/linux/ext4*.h  fs/jbd2/*.[ch] \
           include/linux/jbd2.h fs/mbcache.c include/linux/mbcache.h \
           | grep SUM | awk '{print $5}'`;
xfslines=`cloc fs/xfs/*.[ch] fs/xfs/*/*.[ch] include/linux/dqblk_xfs.h \
           | grep SUM | awk '{print $5}'`;
btrfslines=`cloc fs/btrfs/*.[ch] | grep SUM | awk '{print $5}'`;
gfs2lines=`cloc fs/gfs2/*.[ch] include/linux/gfs2* \
           | grep SUM | awk '{print $5}'`;

(Some of the files above no longer exist, but I used the same script to iterate over all the kernel versions.)

It took a while, but Opower has now launched their “social” site at http://social.opower.com, in conjunction with Facebook and the NRDC.  This site encourages people who know each other to engage in a little friendly utility-bill competition.  If your utility is one (of the few) which is already engaged with Opower, it’ll pull in data automatically.  If not, you can enter data yourself.  (So far, it only tracks electricity use, but natural gas is planned).  You can also create groups of friends such as college alums, coworkers, neighborhoods, etc.  The site is still labeled “Beta” but it seems like a good idea to me.  My journey to a lower power bill started with actually paying attention to what I was currently using, and this looks like a fun way to encourage more of that!

For the friend comparison, it requires a Facebook account, but even without that you can compare your home’s use to aggregate data.  If you decide to give it a shot, send me a request and we can go head to head next month!

I was partly motivated to do this because my boiler manual states that the inlet temp should always be above 140F, with various methods to achieve this.  The guy who installed it didn’t put in a temp gauge, so I had no idea.  Turns out that when the main zone fires, it’s NOT getting to 140F, and now I’m concerned about damage caused by condensation as a result.  But that’s only so interesting.

What I find more interesting is that now I can see how often the boiler fires (by the temp rise) and I can even discern which zone called for heat (because the smaller aluminum-fin baseboard zone gets much hotter than the larger cast-iron radiator zone).

I’m also monitoring temperatures & setpoints in each zone by querying my wifi thermostats [amzn] and creating a pachube.com feed for that here.  I should add the thermostat call-for-heat state too; it’d be interesting to overlay temp, boiler runtime, setpoint, etc to see how the system works together.  The hacky perl script which queries the thermostats & sends that data to pachube.com can be found here.

I’m not sure what real use I can make of the data, but it’s still interesting to have, IMHO.  The first thing that comes to mind is that it’d probably be more efficient if some effort was made to coordinate firing the two zones together whenever possible.  Any other ideas?

pvoutput.org is a free service run by a mystery man down under, which can accept solar generation as well as household consumption data, and slice, dice, and graph it just about any way you would like.

It’s really quite amazing, he has set up a site which, IMHO, puts some of the big solar vendors’ monitoring sites to shame.  It’s a little tough to navigate to everything you can do, but you can:

• Compare output between 2 days
• Compare output to pvwatts production estimates
• Compare production by season or by weather
• Join teams of people with like minds or similar equipment
• See consumption percentage by hour
• And it goes on and on…

But most impressive is that this isn’t tied to any particular data source – First of all, the site has a bidirectional API so you can send data from/to just about anything.  For non-hackers, he has something called the “pvoutput integration service” which is a java framework which can talk to many different types of devices, and there are contributed scripts as well.

He’s also recently added support to automatically pull in data from other sources, from the Enphase API, to pachube.com‘s internet of things, to the TED 5000 energy monitoring device (which is sometimes cheaper on Amazon, btw).

If you’ve got solar, you really should be sending your data to pvoutput.org.  It’s hands down one of the most impressive energy-monitoring related sites on the web.

The only downside is that since the code that runs the site is, as far as I know, not published under any open source license, it makes the whole enterprise a little bus-sensitive.

Looks like his code is here.

$ curl http://thermostat1/tstat
{"temp":67.50,"tmode":1,"fmode":0,"override":0,"hold":0,
"t_heat":62.00,"time""{"day":1,"hour":9,"minute":47},
"t_type_post":0}

We can get current temperature, set point, mode (heating, cooling, or off), humidity (on some models) etc. And it’s not just a read-only interface; you can set parameters like target temp, schedules, etc, as well as display some information on the screen (4 digits on the CT-30 [amzn] , alphanumeric on the CT-80 [amzn])

There’s a Windows tool out there called “Set Your Thermostat” which seems to have gotten the most press, and there’s a 3rd party iPhone app called Thermostapp which likely uses this API as well. So far all I’ve done with it at home is to query the devices every 5 minutes for setpoint and current temperature, so I can graph stuff out, like in the graph above.  At the end if this post is a basic & ugly perl script to gather that information from the thermostat; I process this a little with a bash script and use MRTG to graph it out.

I think there’s a lot more that could be done, such as:

• Display of household electricity data, or thermostat run time, on the display
• Use of indoor & outdoor temps to start heating/cooling in time to hit setpoint at desired time
• Better graphing than MRTG can provide, maybe with Cacti or PCP.
• Addition of X10 or similar occupancy sensors for automatic setback
• Automatic coordination of two zones to minimize boiler firing cycles

Text display on a CT-80

I’ll leave you with my simple perl script to gather some basic data from a thermostat:

#!/usr/bin/perl

use LWP::UserAgent;
use MIME::Lite;
use MIME::Base64;
use Getopt::Std;
use JSON;
use strict;

use vars qw/ %opt /;

my $debug = 0;
my $host = "thermostat2";
my $tempurl = "http://$host/tstat";

my $ua = LWP::UserAgent->new;
my $req = HTTP::Request->new(GET => $tempurl);
my $res = $ua->request($req);

if (! $res->is_success) {
    exit;
}

my $scalar = from_json($res->content);

# target isn't there if not in heat mode
my $t_heat = 0;
$t_heat = $scalar->{ 't_heat' } if $scalar->{ 't_heat' };

print "Temp is " . $scalar->{ 'temp' } . "\n";
print "Target temp is " . $t_heat . "\n";
print "Mode is " . $scalar->{ 'tstate' } . "\n";

Click for interactive graph

In an earlier post I had tried out a few ways to figure out if our energy-saving efforts with respect to natural gas use were paying off; I did a few bar graphs of therms per day, per heating degree day, rolling yearly averages, etc.  I knew that I needed to normalize for the weather using Heating Degree Days, since natural gas is our primary heating fuel, and I probably needed to find a way to separate space heating from water heating, which have different conservation methods, and which may or may not be weather dependent.

I came across this article, Degree Days – Handle with Care! (run by the same folks who provide www.degreedays.net, a great source of free  HDD data) which listed a lot of the issues involved, some of which I had thought of, and some of which I had not, including:

• Separating out non-space-heating use (water, cooking, etc)
• Getting the right base temperature for the building in question
• Using proper degree day data for the actual monitoring period
• Differences in occupant behavior over the time period

But the other thing that caught my eye was the idea to do a scatter plot of HDD vs. heating therms used, and doing a linear regression; the slope should give you an idea of your average therms per heating degree day.

The graph above is my attempt at this; I found some old data from 2004-2005, which was before we did any insulation work, and I have more recent data for the past 4 or 5 years as well, so I have a decent data set.  The graph above does not attempt to factor out water heater use, or to perfectly match HDD (which I actually obtained from the Minnesota Climatology Working Group website, as monthly data) to the precise billing period (which can vary from 27 to 35 days).  It simply graphs therms vs. heating degree days, by heating season, for any months which had over 200 HDD.  But even with that basic, raw data, I still think it shows some interesting trends.

(edit: if you click above, the live graph now has all datapoints for all months; this more accurately shows the base gas load at the Y intercept.  It is also more accurately matched to the actual HDD for the billing period.)

If you click the graphic above, you will be taken to an interactive javascript plot of the data (made with my new favorite toy, jqplot).  By clicking on the legend you can turn data sets on or off; most interesting is to compare 2004-2005 (before any work) with 2010-2011 (after all insulation and air sealing, but before the extra heating zone was added in the basement).  All the years in between are pretty clumped together, with roughly the same slope (or, therm per hdd efficiency).  It’s a pretty messy data set so far; I’ll try to come up with a good way to factor out water heating etc, but I still found it to be an interesting way to visualize the data.  What do you think?

Edit: After a brief discussion with the nice folks at degreedays.net / energylens.com, I have a few more ideas on doing a better analysis.  Hopefully will have some spare time over the holidays to try out some other things, and do another post.

Oddly, gas was a little tougher to get a handle on – there is a lot more variability month-to month, as well as year-to-year depending on the weather.  Our therms used per billing period has ranged from around 10 to almost 200 in the last 3 years.  I’ve also done a lot of work that should help things (note, some amazon affiliate links follow):

• Sealed the attic and added insulation
• Retrofitted blown-in cellulose insulation in exterior walls
• Sealed as many air leaks as I could find
• Added programmable [amzn] (and wifi [amzn]) thermostats to set back home temp at night (I bought a 3M-branded version of that wifi thermostat at Home Depot)
• Insulated hot water pipes as far as I could
• Added low-flow shower heads [amzn] & sink aerators [amzn]

And on the increased-use side, we turned the basement into a zoned, heated space last year.

So it’s a ton of variables all working together.   How does it look, are there any trends?  My best attempt to analyzing that question is to look at therms used per heating degree day during the heating months.

A heating degree day is”a measurement designed to reflect the demand for energy needed to heat a home or business. It is derived from measurements of outside air temperature” according to Wikipedia.  I gathered degree days per month from www.degreedays.net (which didn’t perfectly overlap with billing periods, but close enough), subtracted about ten therms from each period (a rough approximation of our water heating use, probably a little low), and graphed the remaining therms per degree day:

We were on a fairly steady decline until about March/April 2011… which is when we put the 2nd heating zone in the basement.  Oops!  This is what actually prompted these posts; I hadn’t looked for a few months, and when I did, I realized that something had apparently gone a bit wrong in our gas conservation efforts.  I’ve since decided to let the basement stay cold unless we are down there; the baseboard radiators heat up in just a couple minutes, there’s no need to keep it warm down there all day long.

Here is the graph of therms per HDD (without normalizing for water heating use) and therms per day as a 12 month rolling average.  Around March 2011 looks again like a reversal of the downward trend:I’m not sure if this is really enough data to see a trend – and I’m not quite sure how to properly normalize for weather & separate out hot water from space heat use.  This is the best effort so far; I’m open to suggestions!

See also:

• Part 1 – Electricity
• Part 2 – Water

Anyway, water really wasn’t that hard to reduce.  We did these things:
(note, some Amazon affiliate links follow; these are the items I used)

• Got a high efficiency (HE) clothes washer
• Put low-flow (1.5 gpm) aerators on several faucets
• Put dual flush adapters in both toilets [amzn]
• Got low-flow showerheads for the upstairs and the basement showers [amzn]
• Use a rain barrel, and don’t water the lawn too much

None of this is too tough, or especially impactful on our lives.  The showers are quite fine; they aren’t human car washes, but c’est la vie.  And the grass isn’t always a lush green, but that’s just natural consequences in a drought, right?  The dual flush adapters work surprisingly well, and the clothes washer is a great machine.  The dishwasher is about all that’s left; we have to use a roll-around one so our choices are limited.

Anyway, it’s paid off pretty well; here are my gallons per day over time (measured quarterly via our utility bill) with a yearly rolling average:

We’re down to about half our peak use.  And here is a graph comparing use in each quarter (you can see that some summers we did use quite a lot more):

It still amazes me that we use 100 gallons per day; that does seem like a lot, although maybe not so bad for 4 people.  But as the kids grow up and start to want long and/or daily showers, we’ll see how things go!

Part 3 will cover my gas usage, and there’s an admission to make there …

See also:

• Part 1 – Electricity
• Part 3 – Gas