Does it assume battery drain during selling to grid power 0?

[ridax67]

What happened

When it schedules periods of selling to grid with power 0 (exporting solar) there is a constant battery discharge predicted and it seems bess is taking it into account so it makes sure the soc is enough so it doesn't have to run periods of battery charging (losd first) when it planned selling solar.

But is this discharge assumed somewhere or is it measured? Because the discharge is not happening (because I give battery a small portion of the solar charge to cover for the battery self consumtion) so it starts with a high soc unnecessarily. If it is assumed, could it be measured instead?

Debug bundle

Please drag-and-drop bess-debug-2026-07-14-072608.md from your Downloads folder into the editor below before submitting.
The file contains your version, settings, recent logs, and the raw HA discovery dump that the maintainers need to reproduce the issue.

[ridax67]

[ridax67]

Actual soc during grid zer power

[johanzander]

You don't happen to have a debug log? It is very hard to debug without a log.

[ridax67]

This is from that date, not sure what it shows.

bess-debug-2026-07-14-231249.md

[ridax67]

Maybe this should have been better under ideas/discussions rather than issues. The problem is the way growatt account for its own power needs and the way Bess is exporting solar power instead of charging batteries.

When charging batteries from solarin load first, Growatt isn't showing any own consumption, although it of course exists. Therefore the red bars for battery use in the chart are completely empty when doing solar charging.

But when doing solar export instead of charging batteries I think you enter grid first mode with zero battery export. Now, Growatt could have taken energy for self use and sent the rest to grid in a similar way as they do when charging batteries, but instead they use power from batteries to covers its own use and send the major part of ov to grid.

This is really not wanted, harvesting a lot of solar power and still use batteries, not good. This shows up in the graph as the constant red smal dots when selling pv and not charging. This cause Bess, in esrlier versions, to make sure the battery had enough soc for 15 minutes of this drain, but in later versions when it looks at the entire pv export session it wants several %s of soc margin before it starts to export pv. 😬

The solution is simple though, at least with vpp. Instead of exporting with grid first and power 0, you set it to battery first and power 1. It means a small portion of pv will be sent to batteries and the major part will be exported. Growatt is taking its own need from the battery part, so actually the battery will be balanced and there will be no battery loss during pv export.

As I said, I don't know how Bess plans that battery drain iwhike ecporting pv. Is it just historical consumption or is it a fixed amount it knows it has to calculate with during pv export? But Bess must have some way to deduct solar pv frim historical consumption, as the load first charging sessions doesn't show historical consumption. It should use the battery first power 1 fix and deduct pv energy from historical consumption the same way.

[bess-agent]

Thanks for the log and the detailed writeup — I dug into both the debug bundle and the source code to check this.

How BESS actually decides inverter mode during solar export: pure PV export (surplus solar, no battery involved) is dispatched as load_first, not grid_first. grid_first is reserved for BATTERY_EXPORT — an intentional, profit-driven battery discharge the optimizer scheduled because it's economically worthwhile, not a side effect of exporting solar. In this log, every grid_first/BATTERY_EXPORT period has a non-zero discharge rate (5–100%), so the "grid_first + 0% power" combination you described isn't what's happening on the code side.

What the sensors in this specific log show: during the solar-export hours (e.g. 08:15–14:30, 16:00–16:15), the inverter's own lifetime energy counters report battery_charged: 0.0 and battery_discharged: 0.0 — completely flat SOE, no drain. Where the battery did discharge near solar hours, the energy flow balances cleanly (solar_to_grid + battery_to_grid = grid_exported), i.e. it's accounted battery-export activity, not an unexplained loss. The big SOE drops you'd see in a chart of this day (e.g. -2.6 kWh around 20:00, -2.6 kWh around 21:00) are after sunset — intentional evening arbitrage discharges, unrelated to PV export.

Also worth noting: there's no fixed "self-consumption during export" assumption baked into the optimizer — consumption forecasts are built entirely from measured sensor deltas, so if there's no drain in the sensor data, none of it leaks into the SOC-margin planning either.

Quick question: are your observations coming from the inverter/schedule page in the dashboard, or from the actual battery SOC/power sensors? The schedule page's display may be lagging behind modbus/VPP support in places, so if that's where you're seeing this, it's worth double-checking against the raw sensor data separately.

Why this log doesn't settle it either way: it's a low-solar day, and your screenshots look like they're from a different capture window than this bundle's export time (~23:12), so the specific PV-export session you're pointing at isn't really represented here.

What would help: if you can grab a fresh debug log right after you observe the drain happening (ideally with solar production comfortably above ~1 kW at the time), I can check battery_discharged, battery_to_grid, and solar_to_grid for that exact window and confirm or rule out the Growatt self-consumption behavior you're describing. If it turns out to be real, your battery_first + power=1 workaround sounds like a reasonable inverter-side mitigation to explore.

[ridax67]

My charts are from the dashboard. Here are two charts if the same day, one fromearly this morning and one at noon. So it demonstrates Bess' expectation and the final outcome. The issue is not what is measured, but what it expects. Can the expectations be completely driven from histoical consumption data or are there any built in ignoring of history in favour of knowledge of what will happen? I mean during solar charging it is clear that you must surpress the historical consumption when it is surpassed by solar energy and therefore you don't see red bars during solar charge. During solar export on the other hand, you don't do this surpression.

About the inverter modes, I have almost never run it with tou except from in demo mode, but have been running vpp for a week or so. As I recall in tou mode you did run it in grid first with discharge blocked. Later I also saw it running load first with charge blocked, which I prefer as it handles house load better.

But in vpp you don't have this choice really, you can't block charge or discharge (as this is the very reason for vpp). You can select load first (vpp-rc 0) but have way to block charge, so not suitable for solar export before charging. Your only way to achieve this is to use grid first power 0 or battery first power 1. Grid first power 0 is like tou grid first while battery power 1 is like load first with blocked charging.

[ridax67]

bess-debug-2026-07-16-114759.md
This is the log file taken at photo at noon.

[ridax67]

This is just minor details though, in general I am very satisfied with the work. I am testing with soc minimum 5% (it will never drop below 10 inrentionally anyhow) to fool it into emptying more energy so it doesn't have this margin for powering the inverter dureing solar export.