Files
ems/docs/refactor-weaknesses.md
Dusan Vojacek 93f883f5e0
Some checks failed
CI and deploy / migration-check (push) Successful in 5s
CI and deploy / deploy (push) Failing after 20s
sql first refactor
2026-04-19 20:02:20 +02:00

3.0 KiB
Raw Blame History

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.651.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 a váhy slotů (SLOT_WEIGHT_FULL/MEDIUM/LOW = 1.0 / 0.7 / 0.4) hard-coded; vzdálenější sloty mají menší váhu v objective → konzervativnější chování k predikovaným cenám.

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 refaktorem)

Oblast Problém
planning_engine Velké inline SELECT (_load_slots, _load_site_context), compute_correction_factor, _save_planning_run, f-string CTE pro slot boundary
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.

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_*)