Shaving the Morning Peaks

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.


The Idea

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.

Grafana chart showing Octopus Agile prices over 7 days, there's a small peak between 7 and 9 each morning

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)

Screenshot of Solis loud schedule showing a scheduled charge between 03:15 and 05:45


The Result

It was a nice theory, but the impact on daily savings was pretty disastrous:

Screenshot showing daily savings, they've gone negative

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 Problem

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.


Efficiency Losses

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:

Graph showing inverter temperature, it starts rising around 3am and dropping around 8am

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 kWh.

The inverter's claimed charge can be extracted by querying the field batteryChargeToday.

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

Graph comparing reported charges converted using the query above. The two figures do differ, with BMS being lower, but it is very close

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 3.5% and 2.4% respectively. Accepting an (inevitable) margin for error, that matches the efficiency claim made in the inverter's datasheet:

Screenshot of the inverter datasheet. Claimed max efficiency is greater than 97.5%. EU efficiency is 96.8

(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 £0.0016/kWh)


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.

At 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:

Graph showing our energy consumption and source since about 11am. At 2pm the appliances I turned on started consuming power but it came from the battery not the grid

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.