We love big BESS and we cannot lie

If anything has been proven this winter, it is that the battery and solar combination can genuinely hack the cold months. When the sun is not shining, the battery shines brighter: when you can't power your house from the roof, smart optimisation makes sure the energy you do consume comes at the lowest possible price. Households in cloudy European cities are running at close to zero energy cost, the charts on their home energy apps look impossibly good, and the screenshots are everywhere on LinkedIn.

However, the visual tidiness of those charts hides a remarkable amount of computation. Behind every charge and discharge decision lies a continuous loop of forecasting, optimisation, and real-time correction. This article explains how that loop works, why it is harder than it looks, and what distinguishes a well-optimised PV and battery system from one that is merely connected. The residential case is the easiest one to picture, but many of the same building blocks (forecasting, optimisation under constraints, real-time correction) show up at larger scale too, even if the loop itself looks quite different once you move past the meter.

What is actually being optimised?

Start with the physical reality. A solar panel produces power that follows a bell curve shaped by the sun, the season, and the weather. A battery has a state of charge that sits between a minimum and maximum, charges and discharges within power limits, loses a small fraction of energy in every cycle due to round-trip efficiency, and degrades incrementally with use. Neither asset is controllable in isolation without accounting for the other.

On top of the physics sit the external signals that determine what decisions are worth making:

• Solar: how much cheap energy can I get from the top of my roof today and tomorrow?
• Baseload forecasts: will the oven be on all afternoon for baking cookies?
• Energy tariffs: what does electricity cost right now, and what will it cost tonight?
• Customer preferences: comfort constraints, minimum charge thresholds, peak demand limits.
• Market signals: if the user is enrolled in a flexibility program, should the asset react to extreme imbalance prices or a congested local grid?

The optimiser has to find the best charging and discharging schedule that respects all of these simultaneously and that is not a trivial problem, even for a single asset. By optimiser we mean the piece of software that takes the forecasts, the physical limits of the asset, and the external signals as inputs, and produces a concrete charge/discharge schedule as output. Everything that follows in this article is, in one way or another, about how that optimiser is built, fed, and corrected.

Forecasting: seeing the playing field

Optimisation is only as good as the forecasts it runs on. Before any schedule is computed, the system needs to predict what will happen across the relevant horizon, typically the coming 24 to 48 hours.

Three forecasts matter most:

• PV generation: how much will this panel produce, quarter-hour by quarter-hour, given the expected irradiance, cloud cover, and temperature?
• Load: what will the household or building consume? This is harder than PV in many ways, because human behaviour is noisier than meteorology.
• Price or grid signals: for dynamic tariff customers or assets enrolled in markets, what will the price signal look like, and when are flexibility activations likely? For large scale assets this widens out to day-ahead, intraday, and balancing market price forecasts; the same forecasting discipline applied across more markets and longer revenue stacks.

‍

This is where machine learning earns its place. The word AI is used loosely in the energy sector, so it is worth being precise. What ML does here is pattern recognition. A model trained on months of historical production data, weather inputs, and local irradiance measurements learns to translate raw weather data into a PV forecast that reflects the specific roof in question. Weather predictions from providers like ECMWF give us the meteorological inputs like irradiance, cloud cover and temperature but they say nothing about how a particular array, with its specific orientation, tilt, shading and degradation, will actually convert that weather into kilowatt-hours. The ML layer learns that mapping per asset, and learns its quirks. For example, this rooftop in this postcode systematically underperforms expectations on overcast mornings by a predictable margin.

The same logic applies to load. A gradient-boosted tree or a recurrent neural network trained on consumption history learns that Tuesday evenings in February look different from Saturday mornings in August, and that this household reliably spikes at 07:30 when the heat pump kicks in. The model does not need to know why. It needs to know that it happens, reliably enough to be worth building into the schedule.

Forecasting is simply supervised learning applied to time series data, constrained by physics, and continuously retrained as more observations arrive.

What that looks like in practice: data engineering and MLOps

The 'continuously retrained' part deserves a moment, because it is where this stops being a research exercise and becomes a platform problem. Each household has its own model. Model parameters drift as winter turns into spring and the sun's geometry, ambient temperatures, and consumption patterns all shift underneath them. Retraining therefore has to happen on a regular cadence, per asset, not as a one-off.

Inference happens far more often than training. Every time a new numerical weather forecast arrives, typically multiple times per day, every PV forecast in the fleet needs to be refreshed so the optimiser can react to it. With thousands of assets, that means a pipeline that pulls in new weather data, runs inference per household, writes the updated forecasts to the optimiser, and does all of it within minutes, every time. None of it is glamorous, all of it is essential, and getting it wrong is the difference between a fleet that responds to reality and a fleet running on yesterday's assumptions.

Optimisation: choosing when to charge and discharge

Given those forecasts, the optimiser solves a decision problem over a rolling horizon. In plain language:

• Objective: find the schedule that minimises the energy bill (or maximises margin, or minimises carbon, or some weighted combination of these).
• Constraints: honour battery physics, stay within grid connection limits, respect customer comfort rules, and meet any committed flexibility obligations.

It is worth being precise about two terms that often get conflated. A mixed-integer linear programme (MILP) is the optimisation problem we solve in a single run: given a set of forecasts and constraints, what is the best charge/discharge schedule over the next 24 to 48 hours? Model predictive control (MPC) is the surrounding loop. As new measurements and forecasts arrive, the MPC framework re-runs the optimisation, takes the next action from the updated schedule, then forecasts, plans and steers again at the next interval. The MILP is the maths of a single decision; MPC is the discipline of continuously redeciding as reality unfolds.

The objective changes with the asset class; a residential system minimises a household's energy bill, while a large scale BESS more often maximises wholesale and balancing market revenue, sometimes co-optimised across day-ahead, intraday, and ancillary services. The maths underneath stays recognisably the same

Classical MILP approaches are interpretable and solve reliably, but they become computationally expensive as the fleet scales. Heuristic and reinforcement learning approaches sacrifice explainability and some optimality for speed and scale, and are increasingly used in production at the portfolio level. In practice, the industry tends to use classical methods at the asset level and ML-assisted heuristics for portfolio coordination.

Dispatching the generated plan

There is one more layer between the optimiser and the asset itself. We rarely have direct, high-frequency control over residential hardware and smaller-scale Commercial and Industrial (C&I) installations hardware; instead we talk to the cloud APIs of inverters and batteries, which expose a limited set of operating "modes"; charge, discharge, self-consumption, zero feed-in, idle, and so on. So the continuous, optimal power values produced by the solver have to be translated into a sequence of discrete modes before being dispatched. That translation step is where a lot of the practical engineering lives: choosing the right mode at the right time so that the asset behaves, in aggregate, as close as possible to what the optimiser asked for.

A day in the life: a March optimiser

Here is a concrete example, without equations.

It is a March Sunday. Locally it is partly cloudy, so this particular roof will not produce enough to fill the battery on its own. Across the wider system, however, solar generation is high enough to push day-ahead prices negative around midday; exactly the kind of mismatch between local conditions and system-wide prices that a good optimiser is built for.

The local optimiser produces a sequence like this:

• 09:00 to 13:00: charge the battery, but don't feed any energy into the grid because prices are negative.
• 13:00 to 14:00: top up the battery from the grid alongside the solar to take advantage of the cheap (negative) prices.
• 14:00 to 07:00 (next day): use the energy stored earlier to cover the household's load.
• 07:00 to 09:00: the grid needs extra energy, so the battery discharges directly to the grid as a flex activation. The household is no longer following its ideal local schedule, but the end-consumer is being paid for providing that flexibility.
• 09:00 to 10:00: instead of charging the battery from solar, feed the solar into the grid, because right now the export reward is higher than it will be at midday.
• and the story continues.

The chart above shows actual BTM optimisation output across a 36-hour window. The middle panel plots BESS power, state of charge, PV generation, and the site mode (zero feed-in, charge, default self-consumption, BESS idle, flex upwards). The lower panel shows the dynamic tariff for the site. The pattern of midday solar absorption, charging, peak discharge, and flex activations is clearly visible and the flex_upwards intervals in particular are moments when the household is paid to deviate from its locally optimal schedule in order to support the grid.

The optimiser derived this whole sequence from the price signal, the PV forecast, the battery state, and the household load profile; automatically, every day, adjusted to whatever that specific day looks like.

From single asset to portfolio and grid

Everything above describes a single home. The harder problem is a portfolio of thousands.

When you aggregate a fleet of PV-battery systems, the optimisation logic does not simply run in parallel. Assets interact through the shared grid. A cluster of batteries all discharging into the same low-voltage feeder at 18:00 can cause voltage rise and congestion at the distribution level. A good portfolio optimiser accounts for this, coordinating dispatch across the fleet to stay within grid topology constraints, not just individual connection limits.

This creates an opportunity. A well-coordinated fleet of residential batteries is, from the grid's perspective, a controllable, dispatchable asset. DSOs can call on it to relieve congestion. Balancing responsible parties can use it to reduce imbalance. TSOs can activate it for frequency containment. The intelligence that makes a single home's bill lower is the same intelligence that makes a fleet of homes useful to the grid, provided the aggregation layer is built correctly.

Portfolio-level ML adds another layer: predicting which assets will be available, estimating aggregate flexibility, and routing activations to the assets that can respond at lowest cost. The residential nature of these assets makes this harder than it sounds. A battery sitting at 10% state of charge after an unexpectedly high-consumption morning cannot deliver the upward flexibility it was scheduled for. The aggregator needs to know this in real time, and route around it.

In practice that coordination layer combines three streams of information at once: the physical state of every asset (state of charge, available power, recent dispatch history, any health flags), the live picture of the local grid (feeder loading, voltage, current congestion signals from the DSO), and the live picture of the markets (day-ahead and intraday prices, balancing activations, ancillary service calls). For each upcoming interval the platform decides which subset of assets is best placed to respond, and to which signal - sometimes the answer is to bid into intraday, sometimes to hold reserve for a balancing call, sometimes to stand down because a feeder is already congested. None of that is visible to the individual household, but it is the work that turns thousands of small assets into a single, dispatchable resource.

For independent power producers operating fleets of large scale BESS and PV plants, the coordination problem looks different in scale but identical in structure: route the right asset to the right market at the right moment, given physical state and forecast confidence. We see this with partners like DSG in the Netherlands, where large scale flexibility is routed across intraday, day ahead and congestion markets through a forecast-plan-steer loop tuned to that asset class.

What good optimisation looks like in practice

If you are evaluating whether a PV-battery system is actually being optimised well, there are a few patterns worth looking for:

• Charging follows prices, not the clock. If the battery always charges at the same time regardless of the tariff, it is probably running a fixed schedule, not an optimiser.
• The battery is rarely at 100% before the PV peak. A good optimiser preserves headroom for solar to charge into, rather than filling the battery from the grid and then curtailing midday generation.
• Back-feeding is managed, not maximised. In markets or connection points where injection is constrained or penalised, the optimiser holds or absorbs excess PV rather than pushing it to the grid uncontrolled.
• Intraday corrections are visible. A system with real-time feedback will show schedule adjustments when forecasts are wrong. A static schedule will not.

Asset owners don't need to monitor any of this in real time. The plan evolves on its own as forecasts and measurements update. What is genuinely tricky, even for engineers, is reading a chart after the fact and answering why a particular mode was selected at a particular moment: was it planning ahead for the morning peak, reacting to measured PV coming in lower than expected, or repositioning around higher-than-forecast prices? That interpretability problem is real, and it is one of the things the software has to be designed to support. It is also a customer support problem in disguise because every charge or discharge an end-customer cannot make sense of is a potential ticket landing in the retailer's inbox, so giving operators, and ideally end-customers, clear, after-the-fact explanations of optimiser decisions is as much a product requirement as the optimiser itself.

The role of engineers and software

The division of labour matters here. The models, the objective function, and the constraints are the engineering work. Someone has to decide how to represent battery degradation in the cost function, determine whether a 15-minute or 30-minute control loop is fine enough for the markets the asset is enrolled in, and design logic that handles conflicting constraints gracefully rather than producing infeasible schedules.

Execution and scaling are the software problem. Once the optimisation logic is correct, the platform has to run it continuously, across thousands of assets, with reliable connectivity to meters, inverters, and market APIs, and with the observability to know when something has gone wrong.

Powernaut brings both sides together: the engineering rigour of physical forecasting and market-connected optimisation, and the platform infrastructure to run it at fleet scale; from single residential PV-battery systems through aggregated portfolios to utility-scale, front-of-meter BESS and PV plants. If you are building or aggregating PV-battery portfolios at any scale and want to understand how that translates into control and market access in practice, the team is available to walk through the specifics.

‍