# 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&lt;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; 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`  
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).
