# 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`](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í - [x] **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](04-modules/planning-neg-sell-strategy.md). 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. - [x] **v35 implementace** — rampa B, **t_detach**, `E_surplus_after_t` (`2026-05-28-neg-sell-b-ramp-v35`). - [x] **v36 prep okno** — oprava **T**, pre-neg **per den** (cushion A+B), večerní výboj před neg dnem (`2026-05-28-neg-prep-window-v36b`, kotva **reserve_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` 4. **v37** — bazén (Shelly + LP), až po UI dohodě 5. **v38** — spirála (Loxone) - [x] **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`](04-modules/planning-arbitrage-accounting.md) §6, [`docs/05-todo.md`](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).