No description
b4d895224b
The LP was producing visually unintuitive schedules: when several surplus
hours had identical cost benefit (true with constant export_rate), the
solver picked an arbitrary subset, which the user couldn't read as 'this
is the battery doing its job'. Worse, the daily-LP variant drained to 0
every midnight because it placed zero value on next-day SoC.
Replaced oracle_daily_schedule() with a one-pass greedy dispatcher that
matches what every plug-in battery in the catalog (Marstek, Zendure,
EcoFlow, HomeWizard) actually does in 'self-consumption mode':
for each hour:
if exporting at meter: charge as fast as power+capacity allows
if importing at meter: discharge to cover net demand
Trade-offs:
- Greedy doesn't do grid arbitrage (charge cheap → discharge expensive
without a surplus source). The LP would; real plug-in firmware
doesn't, so greedy is more honest about what dad's battery would do.
- Charts now show 'fill in the morning, overflow at midday' which is
what users expect to see.
- Updated tests: dropped LP-arbitrage assertion, added a greedy-fills-
from-surplus-then-overflows test that locks the new behaviour in.
|
||
|---|---|---|
| data/raw | ||
| docs | ||
| scripts | ||
| src/pluginbattery | ||
| tests | ||
| .env.example | ||
| .gitignore | ||
| CLAUDE.md | ||
| Dockerfile | ||
| Procfile | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
pluginbattery
Backtest the actual ROI of a home battery against real historical electricity prices and solar irradiance.
Answers: "If I had owned this battery (plug-in or installed) over the last N years, what would it have actually saved me?"
See CLAUDE.md for project intent, open decisions, and assumptions.