47 lines
3.2 KiB
Markdown
47 lines
3.2 KiB
Markdown
# Refaktor EMS – slabá místa a hranice SQL vs Python
|
||
|
||
Dokument z code review před SQL-first refaktorem. Cíl produktu: maximalizovat ekonomický zisk při rozumném využití zdrojů a **bez** nadměrného cyklování baterie.
|
||
|
||
## Ekonomický cíl a cyklování
|
||
|
||
### Penalizace cyklu v LP
|
||
|
||
- V `docs/04-modules/planning.md` je uvedena symetrická penalizace cyklu (`0.5*(charge+discharge)` v textu účelové funkce).
|
||
- V `solve_dispatch` je v kódu **`0.5 * (bc[t] + bd[t]) * degradation_cost_effective * interval_h / 1000`** – s dokumentací souhlasí.
|
||
|
||
### Další páky proti cyklování
|
||
|
||
- **`degradation_cost_czk_kwh`** na `asset_battery` – jediná explicitní ekonomická cena cyklu v objective.
|
||
- **Slot pre-selection** (`charge_slot_buffer`, `discharge_slot_buffer`) – omezuje množinu slotů pro nabíjení z sítě / vybíjení na export; snižuje mikro-cyklování.
|
||
- **Dynamická arbitrážní podlaha** (`_dynamic_arb_floor_wh_series`, `ARB_LOOKAHEAD_SLOTS = 32` = 8 h) – posouvá ekonomickou podlahu mezi `min_soc_wh` a rezervou podle očekávané FVE energie vpřed; lookahead je **hard-coded** v Pythonu – kandidát na přesun do DB (`planning_config`).
|
||
- **`pv_scarcity_factor`** (0.65–1.0) – mění násobek degradace podle poměru očekávané FVE energie k kapacitě baterie; **úzký rozsah** = slabý signál; možné rozšíření v budoucnu.
|
||
- **Horizont plánu (2026-04):** dynamický konec z OTE (`fn_planning_horizon_end`), žádné váhy 1,0/0,7/0,4 ve solveru; terminal SoC shadow price v LP. Dříve: váhy slotů + 96h predikce ve `planning_engine` (viz `planning-extended-horizon.md` historie).
|
||
|
||
### Zelený bonus (pole B)
|
||
|
||
- Záměrně **není** v účelové funkci LP – bonus se účtuje v auditu (`fn_fill_audit_interval`). Solver neomezuje „výtěžek“ bonusu; riziko přeladění LP je větší než přínos.
|
||
|
||
### Audit cyklování (telemetrie)
|
||
|
||
- `fn_battery_cycle_audit` + `vw_battery_cycle_daily` – ekvivalent plných cyklů z `telemetry_inverter` pro monitoring a ladění `degradation_cost_czk_kwh`, **ne** nový hard constraint v LP.
|
||
|
||
## SQL vs Python (stav před / během refaktoru)
|
||
|
||
| Oblast | Problém |
|
||
|--------|---------|
|
||
| `planning_engine` | `_load_slots` / `_load_site_context` / `_save_planning_run` jdou přes `fn_*` (horizont přes `fn_planning_horizon_end`). Zůstává: PuLP, korekce FVE v Pythonu, slot boundary pokud ještě není ve fn |
|
||
| `control_exporter` | `DISTINCT ON` journal, interpolace SQL pro plán slotu, pack hodin/TOU v Pythonu |
|
||
| Routery | Mnoho po sobě jdoucích dotazů (`site_configuration`, `full_status`), running sumy v Pythonu (`economics`), split FVE A/B v Pythonu |
|
||
| `price_importer` | Mix `::date` vs den v `Europe/Prague` u statistik OTE |
|
||
|
||
## Cílová hranice po refaktoru
|
||
|
||
- **Python:** PuLP solver, orchestrace jobů, Modbus/HTTP/Discord, pvlib forecast.
|
||
- **PostgreSQL:** čtení/zápis dat přes `ems.fn_*` a `ems.vw_*`; read-modely jako JSONB bundles; **žádné vlastní JOINy v Pythonu** nad tabulkami — viz **`CLAUDE.md` (SQL-first)**.
|
||
|
||
## Odkazy
|
||
|
||
- Plánování: `docs/04-modules/planning.md`, `docs/04-modules/planning-extended-horizon.md`
|
||
- Architektura: `docs/02-architecture.md`
|
||
- Pravidla agenta: `CLAUDE.md` (sekce o `fn_*`)
|