'Idle' models exports to grid, but actual behaviour is to battery first

[pookey]

Opening an issue for a better place to discuss the topic rather than email/PRs, as I can attached logs etc here easier!

On a MIN inverter, when in the default mode 'on grid mode (load first), excess power goes to the battery. However, BESS's 'idle' mode assumes it goes to the grid. This causes the battery to charge far quicker than modelled, leading so solar slipping when you have an over sized array.

Screenshot and debug log attached. Ref #17

bess-debug-2026-04-19-084608.md

[johanzander]

Summary of Analysis

Ok, this one was a beast go debug. Claude Code needed several attempts to get it right, but I think it is solved now. Below the conclusion from Claude...

---

What was happening

The DP optimizer uses a profitability check to decide whether discharging the battery makes economic sense. This check compares the value of discharge (avoiding grid purchase or earning export revenue) against the cost basis of the stored energy. The problem was that the cost basis during the backward DP induction was stuck at the initial value of cycle_cost_per_kwh (0.02 GBP/kWh) — far below the actual economic value of the stored energy. This caused two types of wasteful cycling:

• Solar displacement cycling: During peak solar hours, the optimizer would discharge the battery to export at sell price (0.12), then let solar refill it. With cost basis at 0.02, the export looked highly profitable (0.114 vs 0.02), when in reality the round-trip efficiency losses (~8%) and cycle wear made it a net loss. The solar used to refill the battery could have been exported directly instead.
• Grid arbitrage micro-cycling: When sell > buy (e.g., sell=0.12, buy=0.09), the optimizer would discharge to export and then grid-charge at the lower price. The actual profit per cycle was ~0.001 GBP/kWh — economically meaningless but enough to pass the profitability check against a 0.02 cost basis.

The root cause is architectural: the cost basis array in the DP is written forward (C[t+1]) but the DP runs backward, so C[t] always reads the initial value during optimization. The cost basis correctly propagates in the forward simulation (for display), but can't influence the backward DP decisions.

---

What was changed

Rather than restructuring the DP to propagate cost basis backward (which would require adding cost basis as a state dimension), we fixed the profitability check to use the sell price as a floor for the effective cost basis in two cases:

1. When sell > buy: Discharge-for-export is always unprofitable because $sell \times efficiency_discharge < sell$. The round-trip efficiency loss eats any spread. This blocks grid arbitrage micro-cycling.
2. When excess solar exists and the discharge would create battery capacity: The displaced solar has an opportunity cost equal to the sell price (it could have been exported). This blocks solar displacement cycling, even when the battery starts at max SOE (the check evaluates capacity after the proposed discharge, not before).

Legitimate discharge is unaffected — self-consumption during expensive evening periods (buy=0.30) easily passes the check since $buy \times efficiency_discharge = 0.285 \gg sell = 0.12$.

Additional changes:

• IDLE periods now correctly model passive solar charging with charge rate clamping.
• IDLE periods with battery absorption are classified as SOLAR_STORAGE (not IDLE).
• Strategic intent classification consolidated into a single function.

---

Result with your scenario

The optimizer now produces a clean schedule:

• 08:45: Brief discharge (buy=0.13 > sell, self-consumption justified).
• 09:00–09:45: IDLE (sell > buy, discharge blocked).
• 10:00–12:45: SOLAR_STORAGE (passive solar charging).
• 13:00–14:15: GRID_CHARGING at buy=0.08 (fills battery to max).
• 14:30–15:45: IDLE (battery full).
• 16:00–19:00: LOAD_SUPPORT (evening discharge at buy=0.30+).

No more charge/discharge cycling. The battery charges steadily and holds for evening use.

Note on charge rate during solar hours: You may notice the battery charges slowly from solar (~0.1 kWh per 15-min period) while exporting excess. This is actually optimal for your tariff: your sell price (0.12) exceeds the midday buy price (0.08), so exporting solar at 0.12 and grid-charging later at 0.08 earns more than storing solar directly. The optimizer correctly exploits this spread.

---

Disclaimer

This is a significant change to the profitability logic in the DP optimizer. The behaviour should be financially optimal, but battery optimization with dynamic pricing is inherently complex. It would be great if you could test this on your system and report back whether the schedule looks sensible over a few days. In particular, watch for:

• Whether the evening discharge timing matches peak prices.
• Whether any unexpected cycling appears with different price patterns.
• Whether the overall savings look reasonable compared to before.

This will be included in v8.3.0.

[pookey]

So far, this looks like a significant improvement!

Before and after below. I'll see how it goes thought out the day.

bess-debug-2026-04-20-073347.md
bess-debug-2026-04-20-072155.md

[ehrw]

I've also seen some idle exports even though the schedule says it's not supposed to export. I was asking copilot/claude here on github and it claims to have found a bug. Tried to create an issue from the conversation but it failed.
Not sure if it is related or not. Pasting the chat for someone with more knowledge to take a look.

https://github.com/copilot/share/822900ae-4a04-8c80-8002-840344524824

[johanzander]

@ehrw , what copilot found is not an issue. ill fix the logging.
If you believe there is an error, you can export the debug log for me (or Claude) to review, or you can do it with the bess-analyst skill.

[ehrw]

@johanzander thanks for checking.
I'll see if it happens again and report back.

If I remember correctly, I've seen twice that it exports when it has not planned to. Once it was while idle, like this issue reports. The other time it was during powering home. Both times it had been running for 24h+ without restarting and it was in the evening when the price spiked. Restarting BESS solved it as it remakes the schedule and instantly stopped exporting.

I'll make a new issue and report back if I see it happening again.

[johanzander]

@pookey - can we close this issue?

[pookey]

@johanzander sorry, really slow reply/feedback!

I have just put the latest version of BESS onto my setup (rolling back my own patch set) to test properly.

[johanzander]

Great, I hope the growatt cloud integration works better for you and the SPH devices because as of today the plant/list endpoint is not returning any devices for me and many other MIN users!

[pookey]

Great, I hope the growatt cloud integration works better for you and the SPH devices because as of today the plant/list endpoint is not returning any devices for me and many other MIN users!

I'm a MIN user too , and I'm also broken! Nice to see it's not just me though :)

[pookey]

I'll close this as a lot changed since I opened it, and it's likey sorted! will re-open/open new issue if something seems off. I'm updating my fork to v9.