Thursday, September 24, 2026

Solar 1 year wrapup part 2: spreadsheets!

 Ok, so my prior wrapup post was primarily concerned with comparing the different arrays I installed, and seeing how much the direction of each array impacted generation of the panels within that array. I recently got the last bill I needed to put together my big overall tracking spreadsheet, so I thought I'd share that here:




For context, I get numbers from a few different places:

1) the Unitil smart meter, which records incoming power, outgoing power, and net power at the meter

2) my emporia vue power monitor, which for this purpose records total power consumption at the electrical panel, and total power production from the solar panels

3) the enphase gateway, which gives me total power production from the panels, as well as per-panel data. I am not using the enphase data for this particular analysis.

Why does this matter?  Well, if I only look at the Unitil data, I only see power that crosses the meter. BUT a lot of the time I am making power at the panels, and burning it in my house at the exact same time. This power never crosses the meter. I call this power "concurrent consumption+production" power, and it's part of the bigger picture.

Ok, so walking through the spreadsheet:

Columns A and B are the billing month start and end dates, important for linking meter data to power monitor data.

Columns C, D, and E come from my Unitil bills. I get other Unitil bill data as well (like $), but that's hidden in a separate tab with bill data. I might make a separate post about that.

Columns F, G, and H come from my emporia data export. They are aggregated from daily data into billing-month bins.

Column I is that concurrent consumption + production number. It's calculated with the difference between emporial produced power and unitil received power. Kind of academically interesting.

Column J is variance in the "net" between Unitil and emporia. It is interesting because it shows that where (and when) you are measuring your power in the system tells you different things. I think a lot of it is driven by slightly different time-binning, since you can sort of see row 11 and 12 "make up" for each other...

Columns K and L are how much of the preceding month and year worth of power consumption have been satisfied by solar production, based on my Emporia data. The year data isn't super meaningful until the last month, because I've only had the system turned on for a year.

Columns M and N are the same calculations, but using Unitil's data. The difference is small, but I think important to consider, since Unitil is what matters from a $ standpoint.

Columns O and P use the monthly gross electricity cost per kwh (calculated in my Unitil bill spreadsheet) and multiply it by the monthly power generation recorded by my Emporia monitor. This gives my best guess at the true value of the energy I have produced at a monthly timescale.

Column Q just starts with the total out-the-door cost of the system ($19,300) and subtracts off the monthly generated-electricity value. If we take this as a typical year, we would expect to need another 4.5 years to pay for itself, for a total of 5.5 years to break even (not counting opportunity cost). Instead, I am leaving with a net cost of just over $15k, since we are selling the house :|


Finally, here are some plots.

This one is from the summary data we just talked about:


These 4 are from the unitil billing spreadsheet:









Wednesday, September 23, 2026

Central Massachusetts DIY solar - 1 year wrapup

 Just over a year ago I finished installing a fully DIY (with the help of an electrician and a trenching guy) grid-tied residential rooftop solar install.  Some day I'll make a post that covers all of that, because it was pretty interesting. But this post is just to discuss production data after a year.

I installed 27 panels across 3 arrays, as seen below:


North is up, so the garage array, outlined in red, faces southwest. The front array, outlined in green, faces southeast. The back array, outlined in blue, faces northwest. There is significant partial shade from trees on both front arrays at different times of year and day. I also roof-raked the front and garage arrays in the winter, but not the back arrays, which were covered with snow pretty continuously in january and february

Ultimately, all of the panels performed well. The overall average production was 305kwh per panel. The back side panels generated 82% of the per-panel power that the front arrays generated, and the worst panel (248kwh) generated 75% of the power that the best panel (328kwh) generated. I found this interesting, because while everybody says north-facing panels are bad, its very hard to get real-world numbers on HOW bad. Standard deviations across each array were small, under 5%, despite variable and uneven partial shading. 

All in all, I am quite pleased with the performance of the system, and the amount of power it generates. We are moving to a new house soon, and I am strongly considering building a 36-panel array there.



Monday, May 4, 2026

Cleaning up mouse poop in the mustang :(

 I had some mice build a nest under the  back seat in the mustang last year, and I thought I got it all cleaned out. But I found a lot more under the passenger seat this spring... It's look (and smelling) a lot better now!









New starter switch and stereo head unit for the mustang

 The mustang got some love this spring. In addition to cleaning out mouse poop :(


The ignition switch is flaky, so I bypassed it with a starter switch:


Also after years with no stereo, I installed an old alpine head unit I had lying around, and soon should have some speakers as well...




canoe roof rack extension

When i first built my truck ladder rack, the front was higher so I could carry a canoe without it hitting the truck roof. I ended up cutting the front rack shorter so the truck would fit in the garage, but then a canoe (due to their curved shape) hit the truck roof. I finally got around to building a removable rack extension, that also conveniently flips upside down for storage:






well pump controller to allow development in low-flow wells

Background: when you install a well, the screen always clogs up with fine particles, slowing down how fast water can get into the well bore. To clean it up, you need to develop the well. There are lots of ways to do this, but maybe the simplest is just to pump a bunch of water out of the well and wash the fines out. I have some crappy wells I installed with students this spring, and the challenge is that they currently are so clogged that the pump runs dry in about 10 seconds, and then it takes 5 minutes for the well to fill up again enough to pump. So if I just leave the pump running, it'll burn out from running dry most of the time.


Project: a simple timer that will run the pump for some time, and then shut it off for some time, and repeat. The time intervals need to be adjustable. 


I have the hardware I need to build it, but screwing around with buttons and knobs and displays is always a bit of a challenge, as is keeping all that stuff water-resistant and robust. 


Idea: I have plenty of microcontrollers that can act as wifi access points, and host their own websites, and interact via those.


Challenge: the coding for the website hosting and interacting is fairly complex, and I've never really done a good job figuring it out.  Sounds like a great opportunity for LLM coding!


So I wrote up a basic description of what I want the system to do:


"Make a program that runs on an esp8266. The program will control a 12v pump using a pair of relays attached to gpio pins. The esp8266 will host a website the provides places to enter 2 time periods, ON time and OFF time, as well as a start button, stop button and timer status display. When the user clicks the start button, the pump runs for ON time, then waits for OFF time and then runs again. It repeats this cycle indefinitely until turned off."


It spit out some code, and with one small tweak it worked great.  here's the code:

github