Prioritize battery before load during low price periods

[pra]

Hi, first of all, thanks for all the hard work. Installed BESS today, and it was super easy.

If I understand the doc and behaviour correct, there is no optimisation for prioritising loading the battery with solar before house. Is that true, and what is the reason? Say price is 0.5 kr for three hours, and then 1 kr. Then I would like the battery to fill up with free solar, at the same time I want to be able to for example charge the car, or run AC, during the 0.5 kr, and use the battery for load during 1 kr. This requires battery first during that period, but I could not see that as an option. Any thoughts?

[johanzander]

Hi Peter!

Thanks for using BESS!

That scenario is certainly supported, but the actual Growatt battery_first mode is actually never used, it is modelled via load_first with discharge_rate = 0 for a variety of reasons.

You can check how the algorithm maps intents to modes here:
https://github.com/johanzander/bess-manager/blob/main/docs/SOFTWARE_DESIGN.md#tou-schedule-generation

[johanzander]

Or wait, battery_first is used when charging from grid, it is explained above.

[pra]

Thanks for the super quick reply. I should have read the design document first. However, as far as I can tell, the strategy you have implemented do not support the scenario I described, i.e. make sure to fill the battery from sun during the lowest cost period during the day to use later through a battery first strategy:

# Home load priority - consume solar directly first
# Remaining solar allocated to battery then grid
# Grid fills remaining consumption and battery charging

I will have to look deeper into to the algorithm, and see how it operates to understand if the algorithm will instead use grid to charge the battery, with the same result (i.e. battery consuming from grid instead of home). I admit I might be thinking the wrong way about it, but mentally it feels better to fill the battery with free energy, and pay for the direct consumption I happen to use (owen, heater, ac) or intentionally put on to capture excess energy after covering base load and charging the battery (such as car charging).

Curious on your perspective on it if you have time.

[pra]

Here’s an illustration of a scenario where I would have expected the battery to be charged, excess solar to go to home and peak consumption to be from grid, instead the battery goes in to discharge mode.

[johanzander]

Good question — this turns out to be economically neutral, not a missing feature. Here's why, with a simple example:

Setup: Home needs 1 kWh in the cheap hour (0.5 kr) and 1 kWh in the expensive hour (1 kr). Solar produces 1 kWh during the cheap hour, none during the expensive hour. The battery needs to carry energy from the cheap hour to the expensive hour to avoid that 1 kr purchase.

Scenario A — load-first (how the system works today): Solar covers the home's 1 kWh directly, so the home pays nothing. The battery still needs to be charged to cover the expensive hour, so it buys that energy from the grid at 0.5 kr. In the expensive hour, the battery covers the home, avoiding the 1 kr purchase.
→ Total spent: 0.5 kr (grid purchase for the battery), plus the battery's wear cost.

Scenario B — battery-first (your proposal): Solar charges the battery instead, so the battery's charge is "free." The home now has no solar, so it buys its 1 kWh from the grid at 0.5 kr instead. The expensive hour plays out the same as before.
→ Total spent: 0.5 kr (grid purchase for the home), plus the same wear cost.

Same total cost, down to the fraction of an öre, once run through the real numbers (including battery efficiency and wear). The reason: solar is fungible in a single-price window — whichever "bucket" (home or battery) doesn't get the solar just buys the identical amount from the grid at the identical price instead. You're not gaining or losing the free solar either way, just relabeling which purchase it offset. And the same amount of energy cycles through the battery in both scenarios, so wear and charge/discharge efficiency losses are identical too — they don't tip the balance either way.

This only holds because the price is uniform across the whole cheap window. If it weren't — or if your grid connection had a capacity limit that made simultaneous home + battery charging infeasible — the two strategies could genuinely differ. But for the scenario you described, the current load-first design already reaches the same outcome your battery-first proposal would, via the optimizer's own grid-charging decision.

[pra]

Agree in principle, but as far as I have seen (but need to study behaviour more over time) that is not the actual behaviour. It might be from a "plan" perspective, but a not planed spike for example does not seem to be treated in that way. I see the battery actually not being charged to full capacity or even discharge (and in that sense misses the cheep window) so no excess energy exist to cover the expensive period, the spike "steals" low cost energy from the battery, even though both battery and load could get low cost energy from sun and grid. But if you say it is the way it should actually work, that is great, and I will both observe the real behaviour and continue analyse and understand the code more. Thanks so much.

[johanzander]

Sure, this is theory - if you find that BESS does not behave this way, just post a debug log and I can have a look at it!

[pra]

Thanks for engaging. Now I have tested to implement my idea in two different ways with Claude, and the conclusion is: there is no blind spot. BESS's existing behavior is already optimal! Great work Johan! Very happy BESS exists so I finally can get what I want from my Growatt installation. Sorry for the doubt.

[johanzander]

No worries :-).

I took the time to let Claude document the algorithm if you are curious. Found a few issues where the documentation wasn't updated with the implementation along the way:
https://github.com/johanzander/bess-manager/blob/main/docs/ALGORITHM_EXPLAINED.md

https://github.com/johanzander/bess-manager/blob/main/docs/SOFTWARE_DESIGN.md

All the best,
Johan