As part of my quest to drive up the savings that our solar battery is able to generate, I recently adjusted schedules to allow for a small overnight charge.
This was done in order to try and ensure the battery had a charge so that it could shave the morning pricing peak.
It's... uh... not gone particularly well, so as I'd mentioned it previously, I thought I'd follow up with a relatively short post detailing the impact that it had.
Each morning, there's a small peak in prices - presumably as a result of half the country flicking the kettle on to brew some starter fuel and get ready for the day.
During the height of summer, we won't even notice these peaks, because by that time of the day, the solar panels are already soaking in photons.
Recent anomalous weather aside though, the height of summer has passed and we're increasingly not seeing meaningful output until after that peak has started.
So, the plan was to adjust charging schedules so that the battery would charge from the mains a little before the morning peak (when prices are lower)
It was a nice theory, but the impact on daily savings was pretty disastrous:
The schedule was added on the evening of the 7th and, since then, all but two days have been negative.
The two positive days are the result of particularly sunny days and an Octopus Power-up.
The underlying issue isn't actually all that different to what I've observed elsewhere:our usage during the peak simply isn't high enough.
It turns out (and I really should have checked first) that we average about
1kWh consumption during the morning peak.
The configured charge, though, stores anywhere between 2 and 3kWh into the battery. So, once peak is over, there's often another
2kWh left to trickle out at prices that are sometimes lower than that of the charge period.
Reducing the Charge Period
One option, then, would be to reduce the charge period to something like 45 minutes so that we put closer to
1kWh into the battery.
I did briefly consider this, but it runs into a couple of issues:
- Prices climb ahead of the morning peak. So a charge starting shortly before won't achieve a particularly significant price difference
- With a small charge and already slim margins it's possible that we might have to start caring about efficiency losses.
Our morning consumption starts a little way into the pricing peak, so charging immediately before we need it means charging at high cost in the hope that we'll use enough to avoid a loss.
So far in my posts, I've not really talked much about efficiency loss - it's ever present but quite hard to accurately measure.
When the inverter charges the battery, resistance within the circuitry means that some of the energy is lost as heat.
In my graphing, we can see that the inverter temperature starts rising in the middle of the night, dropping again at the end of the charge period:
This temperature increase is fuelled by energy that'll never make it to the battery.
The inverter doesn't provide a good way to see what losses are occurring, the closest that we can get is to approximate by comparing the inverter's battery charge claims to percentage charge level reported by the battery management system (BMS).
The BMS only exposes a percentage value, so we need to convert each change into a kilo-watt hour value:
SELECT non_negative_difference(max("batteryPowerPerc")) * 0.072 FROM "Systemstats"."autogen"."solar_inverter" WHERE $timeFilter GROUP BY time(15m) fill(null)
This query uses
non_negative_difference to extract the difference between each value (i.e. how much the percentage charge figure increased by).
The battery is made up of 3 Pylontech US2000 modules, each with a capacity of
2.4kWh (totalling 7.2kWh in storage). So, each
1% increase in battery charge represents
0.072kWh being stored, so we multiple by that to convert percentage to
The inverter's claimed charge can be extracted by querying the field
Putting those together into a query:
SELECT non_negative_difference(mean("batteryPowerPerc")) * 0.072 AS BMS, non_negative_difference(mean("batteryChargeToday")) as inverter FROM "Systemstats"."autogen"."solar_inverter" WHERE $timeFilter GROUP BY time(30m) FILL(null)
Generates the following chart
It's an extremely inexact means of comparison: there's no way to account for inaccuracies (or rounding) in the values reported by the BMS.
However, the percentage difference between the two smallest gaps (at 04:00 and 05:00) are
2.4% respectively. Accepting an (inevitable) margin for error, that matches the efficiency claim made in the inverter's datasheet:
(The EU efficiency value, apparently, is a weighted efficiency based on a middle-Europe climate.)
The main thing, really, is that we're not seeing an inexplicably large value - the graph supports the idea that efficiency losses are negligible (if our profit margin is
£0.05/kWh, even a 3.2% efficiency loss would cost us just
The Need for Automation
Not being able to automate inverter changes is really proving to be a bit of a pain in the arse. If I were able to automate, we'd be able to dynamically block battery discharge, increasing the chances of being able to turn the morning peak in savings.
In my earlier post, I talked a little about Octopus Power-Ups and my current reliance on me making manual changes:
This approach, of course, relies on me being available at the right times to switch things around. But, it also leads to much higher export volumes (and therefore revenue)
During today's Octopus Power-Up, though, that lack of automation has led to things going quite spectacularly wrong.
14:00 my alarm went off to remind me to turn appliances on. I was in the middle of something, so I went and quickly turned them on and then re-submerged in the code I was working on.
What I didn't do, however, was flip the inverter mode back to self-use, leaving it in grid priority. As a result, rather than starting to charge from the grid, the battery started supplying my appliances:
I've spent the afternoon happily absorbed in code and blissfully unaware of my mistake, with the result that we're now going into peak with an empty battery... fuck (good excuse for a take-away I guess).
It's probably time to look at ordering that rs485 splitter so that I can reduce the system's exposure to human error.