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, bazén

Kompletní návrh: docs/04-modules/planning-neg-sell-strategy.md. Implementace v35+ čeká na doplnění:

• v35 — bod T a rampa SoC z PV B — potvrdit, zda soc_detach_wh = odvozené z rampy, nebo ponechat konfigurovatelné % jako strop (náhrada 80 %).

• TUV teploty — tuv_comfort_temp_c, tuv_preheat_temp_c pro předehřát v bodu T; čas večerního doklepu před sprchou (fixní hodina vs. uživatelský profil).

• Bazén — filter_hours_per_day (kolik hodin filtrace), okno slunce (Prague 09–17?), jen filtrace 1 kW nebo i přitop TČ vody.

• Spirála — je ovladatelná z EMS/Loxone? Samostatný asset vs. signál; priorita oproti TČ v dnech bez sell < 0.

• TČ v pre-neg exportu — potvrdit zákaz plánovaného topení ve slotech pre_neg_pv_export_ts (v36).

• 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).