ACTIVATED!
Our provider finished their musings and, much sooner than expected, an engineer showed up to swap out the uni-directional meter with a bi-directional meter.
The system was officially turned on with our meter change, which occurred three days into our last billing cycle. This was fortuitous, since it meant we'd get most of that bill on solar.
So, was it worth it?
Real Time Use
I found a Python library that can talk to the SMA SunnyBoy inverters. One of the downsides of a string inverter is that you don't get per-panel statistics. But, the flip-side is that it's that fewer electrical components to deal with, which helps with cost. We're in full-sun, with no trees nearby (except when the sun gets very low), so by and large there is no need for the extra components. One could argue having the additional data is useful, and sure that could be a thing. That said, is it worth $40-$60 per panel? That's another conversation.
Anyway, the Python library, after a minor modification, gave me the data that I wanted. After a little Curses play (console text magic, for those who don't know), I have the following little "dashboard" that updates once a second:
Obviously, I am a little obsessive about data breakdowns and aggregations. The above values should be easily understandable: mostly watt values listed per-string, then per-side, and finally in total (that is, what we're sending to the grid if we don't use it all). Given the theoretical panel max values, and the inverter limits, and I'm able to calculate how well we're producing. The above image was captured just before I started typing this, and represents a rather sunny moment in March. Today is partly cloudy, however, and moments earlier I captured this:
Cloudy versus Cloudless Comparison
On cloudless days, the total output graph of the system looks like this - at least for these shorter pre-summer days:
Partly-cloudy looks more like this:
These graphs were pulled from the SunnyPortal site, which aggregates all our data and provides centralized monitoring and reporting to both us and the installer (and, of course, SMA). So, the graphs show the total of all three inverters for the days shown.
The sunny day was a 111 kWh day, while the partly-cloudy day rang in at 87 kWh. Both are still more than we're consuming, but it should be noted that we're also making an effort to cut power usage where possible. The solar isn't going to save us money if we crank the air down to 60 degrees and leave all the lights on. Part of that power-savings came in the form of combining three different fish tanks into one system, so that only a single tank heater was necessary. Ultimately, our goal is to zero out the power bill in the long run, and anything we pull above that is just gravy on top.
The First Bill, In Review
Our first on-solar billing statement finally closed, we are now able to assess just how well the system is doing. Of course, bear in mind that there are many variables that will play into future performance and cost efficiency, but we're ready to track the data that is available. Our last few bills, and our latest, are summarized here:
That $39.64 is our most recent bill, and as can be seen from the Used and Generated column, we did pretty good for missing the first three days of the cycle. We've been averaging about 100 kWh per day of production, so if we'd been able to capture those three days, our overall bill might very well have been zero or negative kWh (which doesn't obviate the flat usage fee, but I'll take whatever I can get).
The expectation is that future bills will see the Credits column light up, and over the summer months a nice balance build there that we'll be able to feed off of as the winter months reduce our yields.
Tracking the daily inverter yields is also an activity, for the moment:
Most of the numbers on this chart are in kWh. The provider bills based on whole kWhs, so the "month total-to-date" is configured thus. The "Moving Average" column takes the last 7 days production totals into consideration. I might add a 14-day moving average column as well, to give us a more stable estimate on expected yields.
Equipment Operation Review
By and large, the system has been self-sufficient. There were some issues initially, some caused by my tendency to tinker and set things up in a "non-standard" way (such as putting the inverters on their own VLAN and then forgetting to give that VLAN internet access). After those were ironed out, about the only thing that has cropped up has been intermittent loss of string on daily start-up. Since the installer came back to finish the necessary setup steps, that has only happened one time. I'm keeping a log regardless. The issue isn't with the inverters, but with the Sunspec rapid-shutdown devices (TS4s) attached to all the panels. These are minimalist devices that are designed to respond to data-over-power-line commands and allow energy to flow only when the inverter says it's safe to do so.
The trouble is, some were getting confused and not activating. Like I said, this appears to be a very intermittent issue, but one right now worth tracking, as the loss of a single string would noticeably impact yields. This might be taken as an argument for optimizers or micro-inverters, but remember that optimizers still have to aggregate and send their power to a central inverter. Micro-inverters would be the only things unaffected, but would be significantly more complex and expensive. Ultimately, the TS4s shouldn't be doing that anyway, so if there is an ongoing problem, it will be tracked and addressed.
Another option might be, in the future, replacing the TS4s with more advanced modules. There are modules that would allow the array to be used as a grid-detached independent power source, which would be very useful during a major outage. It would mean running extension cords, since in this mode the inverter does not feed the main panel, but instead feeds an outlet attached to the inverter itself. However, between that and having no power at all, it's basically an instant-win.
At that point, will the system be much different from an optimizer system? I think the answer is still: yes. The TS4s only control flow of power, they do not otherwise interact with it. In that way, there are no efficiencies or losses to be considered - optimizers do DC-to-DC power conversion at the panel, and some power is lost in doing so. The TS4s are supposedly glorified relays, so losses should be minimized and, in theory, far below the optimizer losses. Note that this is conjecture, though, and my working knowledge of these devices is relatively limited. The TS4s do require some power to operate, but I do not know their actual watt consumption. I'd hope they'd be minimal.
By comparison, it is not uncommon for optimizers to report 97%-99% efficiencies. One SolarEdge optimizer touts a "maximum" 99.5% efficiency - but what are their minimum and typical efficiencies? To take the best case, however, for a 330W panel, you are guaranteed to lose 1.65W. Across 68 panels (my array), that's 112 W if the panels are operating at their maximum. Yes, that's still an aggregated 0.5% loss of overall yield, which doesn't seem like much; I guess the question then is would they provide additional power that I would not otherwise get, given my situation? If not, then I'm at a total loss in both power and money. For semi-shaded scenarios, this might play out different. What little research that is available on the subject seems to point to the reality that with an unshaded reference array, optimizers do not help with yield. This particular subject seems fertile for further study.
To really assess the impacts of optimizers, we would need to understand what their actual raw power requirements are, at which point we could plot them against a range of panel production values. For instance, I have yet to see my panels max-out, but 80% production is pretty common. If the optimizer requires a constant feed of, say, 2W to operate, taking that away from 100W per panel hurts a lot more than from 270W per panel. We'd also need to do the same for the TS4s, for fairness.
Monitoring
Generally, monitoring has been extremely easy. I did the Python program for fun, but the inverters have nice web interfaces, which include a "smart screen" display that gives you the current status without having to log in:
In the long-term, I'd like to get a Modbus-enabled recording app running, and to record more details from my inverters into a central database. I'd also like to build a little Angular front-end that will basically provide the same details as my Python console app, but in a much more visually-pleasing and network-accessible way.
More to come as we track how the system performs in the coming months!
