ems/docs/06-open-questions.md

Otevřené otázky a nedořešené body

Tento soubor slouží jako živý seznam věcí které je potřeba rozhodnout před nebo během implementace.

---

Kritické (blokují implementaci)

• Teltonika API vs OCPP – Jaký protokol použít pro komunikaci s EV nabíječkami? OCPP 1.6 je standardní, Teltonika REST API je jednodušší. Rozhodnout před implementací control.md EV části.

• Kurz EUR/CZK – Fixní hodnota v konfiguraci nebo denní stahování z ČNB API? Ovlivňuje price_importer.py.

• Azimut a sklon FVE polí – Ověřit hodnoty v seedu pro home-01 (pv-a 184°/22°, pv-b 184°/35°). Nutné pro forecast_service.py; konvence je kompasově/pvlib 0=N, 90=E, 180=S, 270=W.

• GPS souřadnice lokality home-01 – V seedu jsou vyplněné; ověřit proti skutečné instalaci, protože jsou vstupem pro Open-Meteo API.

---

Důležité (neblokují, ale řeší se brzy)

Plánování — neg sell, termika, flexibilní zátěže

Kompletní návrh: docs/04-modules/planning-neg-sell-strategy.md.

Rozhodnuto (home-01, 2026-05)

Téma	Rozhodnutí
v35 — bod T, rampa SoC	soc_detach a rampa jen odvozené z forecastu PV B zpět od tail (100 %). Fixní 80 % v LP pro home-01 zrušit (sloupce V083 mohou zůstat pro legacy/KV1, ale solver home-01 je neřídí).
TČ před sell < 0	V ranních slotech pre-neg export (v33) netopit — energii raději prodat do site.
Spirála	Ovládání přes Loxone (signál / virtuální vstup). Samostatný model v EMS až ve fázi v38.
Bazén — filtrace	Min. 4 h/den, za dne více, pokud je přebytek (E_surplus_after_t) a „nic to nestojí“. Rozložení dynamicky dle cen / přebytku / slunce, ne pevné 09–17.
Bazén — přitop	Mimo automatiku plánovače na začátku; sezónní nahřátí ručně. Automatický přitop až později, pokud vůbec.
Bazén — exekuce	Shelly (zapínání filtrace) — napojit až po v37 (asset + LP), ovládání z EMS.

Otevřeno před implementací

• TUV — večerní doklep — 19:00 Europe/Prague (rozhodnuto 2026-05); implementace v v36; doplnit tuv_comfort_temp_c / tuv_preheat_temp_c do konfigurace site.
• Vizualizace flexibilních zátěží v UI — probrat a navrhnout před v37+ (neimplementovat bazén/TČ sink do FE naslepo). Viz planning-neg-sell-strategy.md § 9.1. Návrhy k diskusi: pásma dne (pre-neg / sell<0 / bod T), rozpočet hodin bazénu vs. E_surplus_after_t, slotový rozpad hp / EV / (budoucí pool), srovnání běhů plánu.
• v35 implementace — rampa B, t_detach, E_surplus_after_t (2026-05-28-neg-sell-b-ramp-v35).
• v36 prep okno — oprava T, pre-neg per den (cushion A+B), večerní výboj před neg dnem; kotva reserve_soc večer D−1 (2026-05-28-neg-prep-window-v36d, slack max 400 Wh — v36b měl neomezený slack → ~50 % SoC).
• v36 termika — blok TČ v pre-neg exportu, TUV po T, doklep 19:00 (zatím jen plán).

Roadmap (pořadí)

1. v35 — hotovo
2. v36 prep okno — hotovo (T, pre-neg per den, večer D−1)
3. Workshop UI — flexibilní zátěže (viz výše)
4. v36 termika — TČ / TUV v sell < 0
5. v37 — bazén (Shelly + LP), až po UI dohodě
6. v38 — spirála (Loxone)

• Arbitráž baterie — 1. vlna (před solve): charge_acquisition_buy_czk_kwh + cutoff před 1. allow_discharge_export; LP +ge_bat×acquisition v exportních slotech. Zbývá iterace po solve a více charge slotů — planning-arbitrage-accounting.md §6, docs/05-todo.md.

• Dvě úrovně min SoC v DB – Dnes jedno min_soc_percent (provozní podlaha pro LP i TOU PASSIVE). Budoucí oddělení „tvrdé BMS minimum“ vs „plánovací minimum“ by vyžadovalo nový sloupec nebo politiku per site.

• TUV výkon – Je TUV výkon měřitelný zvlášť nebo jen ON/OFF? Pokud jen ON/OFF, použijeme asset_heat_pump.rated_heating_power_w jako aproximaci.

• Pole B (ongridový) – Zahrnout do auditu jako "neřízená výroba"? Nebo ignorovat úplně? Komplikuje audit ale zpřesňuje ho.

• PostgREST autentikace – Jaký model? JWT tokeny? Row-level security? (Anon role ems_anon je nastavena – viz Vyřešeno; produkce může vyžadovat JWT/RLS navíc.)

• Backup a obnova – Jak se zálohuje PostgreSQL? pg_dump cron? Replikace? Nutné pro produkci.

---

Fáze 2 (zatím neřešíme)

• Více lokalit – správa (admin CRUD site v UI, šablony migrací pro novou lokalitu) — základ UI je: combobox aktivních lokalit (GET /api/v1/me/sites), PostgREST dotazy filtrované podle výběru; autorizace per user/site a RLS u PostgREST stále otevřené, viz níže.
• Solcast jako alternativa k Open-Meteo
• Intraday OTE ceny
• Sezónní korekce predikce spotřeby
• Mobile app / PWA notifikace
• Integrace s dodavatelem elektřiny pro automatický reporting

---

Vyřešeno

• PostgREST anon role: ems_anon, read-only na vybrané views a tabulky (migrace V009__postgrest_roles.sql + repeatable R__072_z_postgrest_ems_anon_grants.sql kvůli pořadí Flyway); zápisy přes FastAPI. Compose / .env: POSTGREST_ANON_ROLE=ems_anon, PostgREST PGRST_DB_ANON_ROLE.

• Multi-site (částečně): OTE import jednou pro celý systém do market_interval_price; frontend výběr lokality (SiteSelectionContext, persist ems.selected_site_id), API GET /api/v1/me/sites (zatím všechny aktivní site). Chybí: mapování uživatel → site, JWT/RLS u PostgREST (viz otevřená otázka výše).

TUV ochlazování v LP možná 60× podhodnocené (jednotky °C/min vs °C/15min)

Nález při idle-skip auditu (2026-06-12): avg_temp_delta_c v tuv_usage_stats je fakticky °C/min (per-row delta 1min telemetrie; po idle-skip fixu explicitně normalizováno na /min), ale solver dělá tuv_pred += delta * INTERVAL_H (0.25), tj. zachází s ní jako s °C/h — ochlazení zásobníku v look-ahead je ~60× menší než realita. Důsledek: solver podceňuje potřebu dohřevu TUV (možná část GAPu?). Náprava mění ekonomiku → nutný eval + golden gate + přepočet fn_update_tuv_usage_stats/solveru najednou. Ověřit proti reálné křivce chladnutí zásobníku, až poteče TČ telemetrie (MIM-B19N reg +25).

Tesla patch přepisuje uživatelský target session VYŘEŠENO (03b7396)

Limit auta nově funguje jen jako strop (target se sníží, jen pokud je limit pod ním); cíl drží kaskáda fn_ev_session_defaults. Zbývá ověřit vedlejší otázku: proč apply_patch posunul deadline na +36 h.

(původní zápis) Tesla patch přepisuje uživatelský target session (2026-06-13 ~01:00)

_patch_session_from_tesla při příjezdu nastavil target_soc_pct = 100 (charge_limit_soc LFP) a přepsal kaskádu fn_ev_session_defaults (vozidlo má default 30). Session #2 ručně patchnuta na 30. Fix: Tesla limit používat jen jako STROP (min(limit, default/weekly)), ne jako target. Ověřit též, proč patch deadline skočila na +36 h (2026-06-14T10:00Z).