ems/docs/ev-improvement-plan-2026-06-14.md

# EV plán zlepšení — konsolidace (2026-06-14)

Triáž z živého provozu home-01 (Tesla na TeltoCharge). Sjednocuje pět propojených
pozorování do jednoho prioritizovaného plánu. Cílem je odstranit phantom nabíjení,
fragmentaci a slepotu plánovače k reálnému stavu auta — **bez nové „přežvykovací"
vrstvy nad plánem** (bolístka z v1). Veškerá logika zůstává v solveru / SQL,
control vrstva je hloupý vykonavatel.

## Průřezové zásady (platí pro všechny body)

- **Nebudit auto.** Tesla `vehicle_data` (SoC/odometer/poloha) se čte jen když je
  auto vzhůru z vlastní vůle — `get_vehicle_api_state` (`tesla_client.py:183`,
  online/asleep/offline, nebudí) gatuje budicí `get_charge_state`
  (`tesla_client.py:125`). Výjimka bez buzení: **auto, které aktivně nabíjí, je
  vzhůru** → během session lze SoC číst bezpečně.
- **SQL-first.** Živé SoC i „full" stav musí být v DB sloupci/tabulce; čte je
  `fn_ev_session_planning_json` / `fn_ev_session_defaults`. Žádné skládání v Pythonu.
- **Golden gate.** Cokoliv mění `planning_interval` (solver, needed_wh) musí projít
  golden gate. Solver změny za DB flagem s default = no-op, pak kalibrace harnessem.
  Pozor: golden fixtures dnes EV **nulují** → nutná EV fixture z home-01 (chce DB).
- **Žádné hardcoded kódy zařízení.** Vybírat podle `site_id` + `id`.
- **Import/export tvrdé limity** (§7/§19): control nesmí jednostranně zvednout EV
  výkon nad plán (rozbilo by garanci `import ≤ max_import`).

---

## 1. Živé SoC auta do plánovače — ✅ IMPLEMENTOVÁNO na dev (2026-06-14)

> **KOREKCE po ověření na živé DB:** plánovaný coulomb z `vw_latest_ev_charger.energy_kwh`
> NEFUNGUJE — ten counter (Telto reg 39) je **rozbitý** (17.4 kWh reálně nabito →
> counter stál na 0.18). Fix proto integruje **`power_w`** (spolehlivý signál), ne counter.
> Hotovo v `R__038`: nový `fn_ev_session_delivered_wh` (time-weighted integrál power_w,
> dt cap 120 s) + přepočet needed_wh/headroom z `live_soc = soc_at_connect + delivered/cap`
> (clamp 99 %), fallback `coalesce(live, energy_delivered_wh, 0)`. **Ověřeno živě:**
> needed_wh 18750 → **1329 Wh**, live_soc 97.9 %. **Nenasazeno na prod** (čeká deploy).
> Detail: `docs/planning-changelog.md` 2026-06-14.

**Pozorování:** auto na 99 %, ale plán do rána ukazuje 4× 11 kW okna (phantom).

**Příčina (ostrá, z workflow `wqikxa47f` — horší, než vypadala):** plánovač počítá
`needed_wh` i headroom **výhradně ze zamrzlého `soc_at_connect_pct`** (zapsán jednou
při příjezdu) mínus `energy_delivered_wh` — JENŽE **`energy_delivered_wh` se během
session NIKDY nezapíše** (V006:53, NOT NULL DEFAULT 0; `fn_ev_session_transition` jen
otevře/zavře, `telemetry_collector` píše kumulativní energii jen do
`telemetry_ev_charger.energy_kwh`, ne do session). Takže delivered je **trvale 0** →
**`needed_wh = (target − soc_at_connect)/100 × cap` je KONSTANTA po celou session,
neklesá jak auto nabíjí.** Plánovač je k pokroku nabíjení **úplně slepý** → rolling
replan každých 15 min znovu emituje plný deficit (4× 11 kW okno). (R__038:37–61.)

**Klíč: živý progres už v DB MÁME** — `telemetry_ev_charger.energy_kwh` (Teltonika
reg 39, kumulativní kWh per session, reset na novou session, poll 60s), vystavený přes
`vw_latest_ev_charger.energy_kwh`. **Hardwarově měřený, funguje pro všechna auta
(i Zoe), bez Tesla API, bez buzení.**

**Fix #1 (primární — čistě SQL, žádná nová vrstva/tabulka/job, žádné buzení):**
v `fn_ev_session_planning_json` (R__038) nahradit zamrzlý `coalesce(es.energy_delivered_wh, 0)`
**živým** `coalesce((select energy_kwh from vw_latest_ev_charger … otevřená session) × 1000,
es.energy_delivered_wh, 0)`. Odvodit `live_soc = soc_at_connect + delivered/(cap_wh)×100`,
**clamp 99 %** (taper ignorujeme). `needed_wh = greatest(0, (target − live_soc)/100 × cap_wh)`
a `headroom = greatest(0, (99 − live_soc)/100 × cap_wh)` z živého SoC. → needed i headroom
klesají s nabíjením a **kolabují na 0 při plném autě** → phantom okna zmizí.
- **Fallback `coalesce(vw, es.energy_delivered_wh, 0)`** drží staré golden fixtures
  beze změny (bez WB telemetrie = delivered 0 = soc_at_connect = dnešní chování) →
  **golden gate zůstane zelená by-construction.** Tj. #1 lze nakódovat a lokálně
  dokázat ne-regresi **bez živé DB**; DB chce jen živé ověření na home-01.

**Komplement — ne-Tesla (Zoe):** dnes se session při `soc_at_connect_pct IS NULL`
**úplně vyřadí z LP** (R__038:29). Změkčit: startovní SoC z kaskády (ruční UI patch
přes R__015 → zděděný `soc_at_disconnect` minulé session → konzervativní default ~20 %),
pak coulomb delta dá použitelné absolutní SoC. *(samostatný krok po ověření #1.)*

**Odloženo (Fix #3, opt-in):** mid-session Tesla refresh živého SoC — JEN když coulomb
counter nestačí (auto nabito mimo WB / chybí WB telemetrie). Budí auto (vampire drain,
proti dnešní zásadě) → nedělat, dokud se coulomb fix neukáže jako nedostatečný. Wallbox
`charging_state` „full" je univerzální brzda zdarma navrch (auto přestalo brát → needed
spadne i kdyby coulomb plaval).

**Soubory:** `R__038_fn_ev_session_planning_json.sql` (jádro), `R__015` (Zoe patch),
`docs/04-modules/ev-charging.md`, `docs/planning-changelog.md`. **Golden:** ANO (mění
needed_wh) — fallback drží fixtures bez EV telemetrie identické; fixtures s nenulovou WB
telemetrií se přegenerují (phantom byl bug, nová čísla správná). **Roll-forward deficitu**
vyjde emergentně: nenabito dnes → SoC nízký → další deadline dožene.

**Ověřit na živé DB (chce IP):** že `vw_latest_ev_charger.energy_kwh` sedí na AKTUÁLNÍ
session (counter per connector — spolehlivě resetuje na session?); reálná AC→DC účinnost
(~8–12 % ztrát → live SoC mírně optimistické, žádoucí směr — méně phantom); porovnat
odvozené `live_soc` vs 99 % na displeji auta a že needed_wh/headroom spadnou na ~0.

---

## 2. Předehřev / 0 A logika — PRIORITA Č. 2 (control, bez golden)

**Princip:** wallbox neumí oddělit „proud na topení" od „proudu na nabití".

- **SoC ≥ target → NEřezat na 0 A.** Pusť proud → Tesla se předehřeje z WB (levná
  síť/baterka) místo z vlastní (vožené, drahé) baterie; protože je na targetu,
  baterku stejně nenabije → nulové riziko. Hlavní zimní případ.
- **SoC < target → řídí plán** (nabít v levných, 0 A v drahých). Konflikt
  předehřevu v drahém slotu je vzácný (auto obvykle dosáhne targetu přes noc) →
  nepřekomplikovávat.
- **Operačně:** odpojení → **jednorázové 0 A** (auto pryč, failsafe je jedno,
  žádné periodické psaní); připojení → notifikace → plán + amps; po dobu připojení
  → re-assert amps každý tick (Fáze-0 oprava proti driftu WB watchdogu na failsafe).
- **Fáze z DB** (`asset_ev_charger.phases`), ne hardcoded 3/1 (`setpoints.py:185-186`).

**Závisí na #1** (potřebuje znát SoC ≥ target). **Soubory:** `setpoints.py`,
`outputs.py`, `docs/04-modules/ev-charging.md`. **Golden:** NE (jen překlad
watt→amp při zápisu; control nečte/nepíše planning_interval).

---

## 3. Anti-fragmentace + plný výkon v solveru — PRIORITA Č. 3 (za flagem)

**Pozorování:** nabíjení rozsekané přes 21:15 / 1:30 / 1:45 / 5:30 / 6:00, navíc
dílčí 1,3–1,4 kW. „Z baterky je solveru jedno kdy" (uživatel) = indiference →
náhodný scatter.

**Příčina:** EV je v solveru spojitá energie po slotech bez jakéhokoliv časového
členu — žádná start/stop ani commitment penalta (tu má jen baterie). Pro LP je
souvislý i roztříštěný profil ekonomicky identický (`solver_v2.py:292-337`).
Dílčí výkon = marginální slot dolitý na zbytek (spojitá proměnná, `:162-175`).

**Fix (jeden člen v objektivu, žádná nová vrstva):**
- **Block-start penalta:** `ev_start[t] ≥ on[t] − on[t-1]`, objektiv
  `+ Σ ev_start × planner_ev_start_penalty_czk`. Min počet startů = jedna várka.
  Protože scatter z baterie je čistá remíza, **malá penalta slepí blok zadarmo** a
  **nikdy nepřebije reálný cenový spread** (auto-splnění obavy „ať to nehrne přes
  extrémní cenu"). DB param na `asset_ev_charger`, default 0 = no-op.
- **`min_power_w` → třífázový floor** (6 A × 3 × 230 ≈ 4140 W) místo jednofázových
  1380 → zruší sub-6 A drobky i tiché shození pod minimem (`outputs.py:49` je
  správně, problém je nefyzikální setpoint z plánu).

**Soubory:** `solver_v2.py`, `db/migration/V1xx__asset_ev_charger_ev_start_penalty.sql`,
`R__039`, `db_io.py`, golden fixtures, `docs/04-modules/planning.md`,
`docs/planning-changelog.md`. **Golden:** ANO (za flagem default 0 → no-op).
**Odloženo zvlášť:** explicitní round-trip cena EV-z-baterie v LP (citlivé na
arbitráž §8; na scatter nemá vliv).

---

## 4. Trip/usage forecast — aktivace (PRIORITA Č. 4, většinou jen config)

**Stav: postaveno** (V089 + R__096), chytřejší než původní nápad:
- `ev_vehicle_obs` (Tesla obs při příjezdu/odjezdu), `ev_trip` (km z odometru,
  kWh z ΔSoC, `charged_away` vyloučí nabíjení cestou), `ev_usage_stats` (týdenní
  DOW rytmus), job 00:50 (`lifespan.py:276 fn_update_ev_usage_stats`).
- `fn_ev_required_soc` = **P80 spotřeby toho DOW + 10 p.b.**, clamp
  `[min_target_soc_pct, 100]`; `fn_ev_next_departure` = typický odjezd.
- Model je **DOW-based, ne GPS-route** — GPS okruhy zatím nedělá (refinement,
  nízká priorita; DOW na dojíždění většinou stačí).

**Co dotáhnout:**
- Ověřit **objem dat** (≥4 vzorky/DOW; telemetrie od ~3/2026 → po 3 měsících by
  mělo stačit) — chce živou DB.
- Zvážit zapnutí `asset_vehicle.target_soc_forecast_enabled` (default false =
  sbírá, ale session jede na defaultech).

**Golden:** NE (jen nastaví target/deadline session). **Soubory:** žádné nové,
jen verifikace + flag.

---

## 5. Geofence arrival trigger — PRIORITA Č. 5 (schváleno uživatelem)

**Motivace:** dnes je celý arrival/trip ukotvený na **píchnutí do wallboxu**.
Když uživatel nepíchne (zaparkuje doma bez nabíjení), wallbox nevidí nic → žádný
trip, žádná obs. Presence cesta (V095) přitom „je doma" **detekuje přes GPS
geofence** i bez píchnutí (`telemetry_collector.py:840-849 at_home`).

**Fix:** přechod `at_home` false→true (auto vzhůru, nepíchnuté) brát jako
**arrival home event**:
- zapsat obs pro trip-building (i bez píchnutí), s `trigger` rozlišujícím zdroj
  (wallbox vs geofence);
- umožnit proaktivní notifikaci (bod #6) i bez píchnutí.

**Caveaty:** oportunistické (jen když je auto vzhůru → ne instantní); **debounce**
(2–3 vzorky); **dedup s wallbox arrival** (když píchneš, wallbox je autoritativní,
geofence se nepočítá dvakrát); trip se páruje s nejbližším relevantním
odjezd-eventem. **Soubory:** `telemetry_collector.py` (presence cesta),
`R__096` (`fn_ev_build_trips` přijme geofence arrivals), případně nový `trigger`
enum ve `V089` schématu (nová migrace). **Golden:** NE (jen sběr dat/notifikace).

---

## 6. Proaktivní notifikace „doma + nenabito + levné" — PRIORITA Č. 6

**Datový základ existuje** (`ev_presence_obs`: `at_home`, `charging_state`, SoC,
vše bez buzení). Logika: `at_home=true` ∧ nepíchnuto (`charging_state` disconnected)
∧ SoC < target ∧ (přebytek PV NEBO záporná/levná cena) → Discord nudge „píchni ho,
je levno". Oportunistické (čeká, až je auto vzhůru). Napojí se na #5 (geofence
arrival) a stávající `ev_notify` / `discord_bot`. **Golden:** NE.

---

## Pořadí nasazení

1. **#1 živé SoC** — odstraní phantom okna a plýtvání; enabler pro #2. (golden)
2. **#2 předehřev/0 A** — control, hned po #1, bez golden.
3. **#3 anti-fragmentace** — za flagem default 0, kalibrace harnessem + EV fixture.
4. **#5 geofence arrival** + **#6 notifikace** — sběr/notifikace, samostatné PR.
5. **#4 forecast aktivace** — až je dat dost (verifikace na DB).

**Blokery:** #1, #3, #4 chtějí **živou DB** (EV fixture, objem dat, ověření) —
potřebuju IP serveru (`frank` se neresolvuje). Lokálně umím dokázat jen
ne-regresi (golden default off) + unit testy.

## Rozhodnutí (z rozhovoru 2026-06-14)

- 3 fáze (ne 1f surplus — pokryje velká baterka).
- Anti-fragmentace = malá ekonomická penalta v solveru, ne tvrdá priorita ani nová
  vrstva; control zůstává hloupý (žádný max-amps override — rozbil by §7).
- Geofence arrival ANO (robustnost bez píchnutí).
- DOW forecast stačí; GPS-route clustering odloženo.