Files
ems/docs/06-open-questions.md
Dusan Vojacek 96b16b9ff9
Some checks failed
CI and deploy / migration-check (push) Failing after 26s
CI and deploy / deploy (push) Has been skipped
oprava vecerniho nevybijei
2026-05-26 14:34:39 +02:00

83 lines
5.8 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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é 0917. |
| **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 D1 (`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 D1)
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).