ev_vehicle_obs.trigger += 'geofence_arrival' (V109); presence cesta zapíše příjezd
i bez píchnutí (za flagem EV_GEOFENCE_ARRIVAL_OBS_ENABLED, default OFF); fn_ev_build_trips
páruje. Constraint name ověřen živě. Worktree agent.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fn_pool_schedule_slot: nejlevnější souvislé okno denního runtime budgetu
(fn_pool_daily_runtime_min) z vw_site_effective_price + dump-load při sell<=0.
fn_pool_control_tick: každých 15 min spočte stav a zařadí POOL_PUMP_ON (jen když
existuje signal_route → bezpečné před aktivací). lifespan job pool_control.
Shelly přes signal_service, žádné Modbus. Bazál odečet (R__003) se tím stává
správným (řízená+plánovaná zátěž). Aktivace provozně: daily_runtime_min=480,
schedulable, signal_route.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
needed_wh i headroom z live_soc (soc_at_connect + integrál power_w), ne ze
zamrzlého soc_at_connect. energy_delivered_wh se během session nikdy nezapisoval
(→ needed konstantní, plánovač slepý k pokroku), counter energy_kwh (Telto reg 39)
je rozbitý (17.4 kWh nabito → counter 0.18). Nový fn_ev_session_delivered_wh
integruje power_w (dt cap 120 s), clamp 99 %, fallback drží staré chování bez
telemetrie. Ověřeno živě: needed_wh 18750→1329, live_soc 97.9 %.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fn_planning_site_context (R__039) a fn_load_planning_slots_full (R__063) mely
natvrdo 'ev-charger-1/2' a 'deye-main'. Uzivatel prejmenoval wallboxy na
'vt-ev-charger-1/2' -> ctx.vehicles=[], ev_sessions=[null,null], ev1/ev2_connected
vzdy false -> planovac nevidel auto -> ZADNE nabijeni ani v zapornych cenach
(Tesla 70%, potrebuje 90% do Po 7:00, okno -0.32 Kc ve 13:45 nevyuzite).
Fix: vyber wallboxu DYNAMICKY podle site_id, ev1=nejnizsi ch.id, ev2=druhy
(stabilni, odolne prejmenovani). Inverter pro gen_cutoff pres controllable=true
misto code='deye-main'. Konzistentni R__039 (vehicles order by id, sessions
dynamicke kody) + R__063 (ev1/ev2 connected). Pure SQL, 363 testu zelenych.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Zivy incident home-01: aktivni plan mel ev_sessions:0, ac session bezela
(target 70 %). Planovac neviděl ~6 kW zatez auta a spatne rozvrhl baterii
(zbytecny vecerni import).
Root cause (dve pasti):
- fn_planning_site_context vracela session jako null, kdyz needed_wh=0
(auto nad targetem) i kdyz target_deadline is null.
- _ev_session_from_json (Python) zahazovala session bez deadline.
Fix:
- R__038 fn_ev_session_planning_json: session se vyradi (null) JEN bez tvrdych
dat (kapacita vozidla / soc_at_connect). target_deadline smi byt NULL --
solver hard deadline constraint aplikuje jen pri needed>0; oportunisticka
vrstva bezi i bez deadline. Auto nad targetem zustava v planu jako znama
zatez i s headroomem k levnemu doplneni. R__039 vola helper (deduplikace
dvou inline poddotazu, SQL-first).
- _ev_session_from_json si NULL deadline ponecha (energy_needed_wh default 0).
- testy test_ev_session_parse.py; docs ev-charging + planning-changelog;
CLAUDE.md funkce.
Navrh agresivnejsiho oportunistickeho algoritmu (P50 levnych oken z
market_price_stats misto konstanty 1 Kc/kWh) -- NEnasazeno, k rozhodnuti,
sepsano v docs/04-modules/planning.md (EV oportunismus); riziko regrese
golden ekonomiky, nutny EV fixture + eval.
Overeni: pytest -q 362 passed; golden replay gate 7 passed; solver_v2_eval
beze zmeny (fixtures bez EV session).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Patch po příjezdu přepisoval target_soc_pct limitem auta (LFP 100 %) a
zahazoval kaskádu fn_ev_session_defaults (default vozidla 30 %) — auto by
se v noci tlačilo do plna ze sítě proti vůli majitele (session #2 dnes).
Nově se target snižuje jen pokud je limit auta POD ním;
fn_tesla_arrival_context vrací i target_soc_pct session.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Wallbox dostával zápisy 15/19/20 každý export tick (~8x/hod: control_export
:14,:29,:44,:59 + rolling replan */15 s exportem), protože drop-unchanged
stál na fn_modbus_last_verified_map — dokud verify čtení nedoběhlo/selhalo,
mapa byla prázdná a celá trojice se psala pořád dokola. write_ev_arrival_hold
navíc psal trojici nepodmíněně při každém píchnutí kabelu (docstring lhal).
- nová ems.fn_modbus_device_state_map (R__100): nejnovější řádek journalu
per registr, hodnota jen pro written/verified; failed/mismatch => registr
chybí => po výpadku se konfigurace obnoví jedním zápisem
- write_ev_setpoints + write_ev_arrival_hold filtrují přes tuto mapu:
reg 15 jen při změně plánu, watchdog 19/20 jednou po startu/po výpadku
- verify job EV chargery ověřuje už dnes (fn_modbus_written_command_ids bez
filtru asset_type); registry 15/19/20 jsou dle oficiálního protokolu R/W
- watchdog Telto sytí jakákoli validní komunikace vč. FC3 čtení telemetrie
(60 s << 300 s) — periodické zápisy k udržení spojení nejsou potřeba,
failsafe 8 A nastane jen při skutečném výpadku EMS
- testy: tests/test_ev_write_on_change.py (drop, setpoints, arrival hold)
- docs: modbus-registers-teltocharge.md (sekce Zápis už není "NEimplementováno",
R/W tabulka, watchdog sémantika), modbus-command-journal.md (sekce EV
wallbox), CLAUDE.md (fn_modbus_device_state_map)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fakturační elektroměr ~8 kW vs Deye 13.5 kW: hlavní okruhy domu (vč. wallboxu,
EV 10.5 kW při load 164 W) visí MEZI střídačem a CT u elektroměru — reg 625
(svorky) ani 653 (UPS port) je nevidí. home-01 bylo chybně vedeno jako bez CT.
V100: deye_zero_export_mode=2 (reg 142 → zero export to CT, propíše exporter),
sloupce inverter_grid_port_w + ups_load_w, komentáře se změnou sémantiky.
Collector: grid_power_w z reg 619 (instalace s CT; fallback 625),
load_power_w = pv + baterie + grid = celkový dům. R__049 +2 parametry,
R__052 + deye_zero_export_mode. Audit/baseline od teď počítají se skutečnou
ulicí; historie (do 2026-06-12) nese svorky střídače — přepočet ekonomiky po
faktuře. Baseline rebuild doporučen po týdnu nových dat.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Hloubková diagnóza EV potvrdila: oportunitní ekonomika via-baterie je v LP
správně, ale okraje lhaly nebo byly nevykonatelné:
- V099 + R__039: ems.ev_session.opportunistic_value_czk_kwh (NULL = zdědit
z asset_vehicle, 0 = vypnout pro session); headroom_wh z max(target_soc,
soc_at_connect) — „nenabíjet" (nízký target) už paradoxně NEzvětšuje
oportunistickou vrstvu; vehicles JSON nese min_power_w wallboxu.
- R__015: patch klíč opportunistic_value_czk_kwh (validace >= 0).
- solver_v2: (a) deadline suma range(t_dl) — slot začínající v deadline už
nepatří „do deadline"; (b) Σ ev_direct <= gi + PV (fyzikální split);
(c) binárka ev_on → setpoint ∈ {0} ∪ [min_power_w, max] (konec 400–900 W
nevykonatelných setpointů); (d) bez session EV == 0 (stop-session i golden
fixtures — žádné pumpování při buy<0); dekompozice total == needed − unmet
+ opp i pro needed = 0; (e) battery_arbitrage_czk = via_bat kWh × oportunitní
cena (min sell exportního slotu téhož pražského dne, jinak terminal value)
místo konstantní 0. Oportunismus PO deadline zůstává POVOLENÝ (rozhodnutí:
auto často doma, odjezd řeší rolling replan).
- R__033: fn_plan_current_bundle.intervals + ev1/ev2_via_bat_w (UI nemá cenit
EV kWh z baterie slotovým buy).
Golden gate beze změny snapshotů (v1 nedotčen, fixtures bez EV sessions);
solver_v2_eval před/po identický (CELKEM −1283.5 Kč, Δ −221.9 vs v1);
tests/test_solver_v2.py +7 testů; plná sada 310 passed / 4 xfailed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tabulka ems.ev_weekly_requirement (dow 0=pondělí..6, target_soc_pct,
deadline_hour Europe/Prague, enabled; unique per vozidlo+den) se seedem
tesla-my pondělí 07:00 → 90 %. Nová ems.fn_ev_session_defaults(vehicle,
arrival) → jsonb {target_soc_pct, deadline, source}: kaskáda týdenní
požadavek (výskyt do 48 h) → forecast z ev_usage_stats
(target_soc_forecast_enabled, chování V089 beze změny) → defaulty vozidla
(deadline = příští výskyt default_deadline_hour). fn_ev_session_transition
ji volá při založení session (SQL-first, Python beze změny); comment
funkce sjednocen na styl bez parametrů.
Docs: ev-charging.md sekce Týdenní požadavky + kaskáda, CLAUDE.md seznam fn.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- fn_fill_audit_interval: EV a TČ agregace sum(power_w)/15 místo avg přes
přítomné řádky — avg by při řídké telemetrii nadhodnotil aktivitu části
slotu; chybějící minuta = 0 W (idle). TČ drží NULL bez power_w (MIM-B19N).
- fn_update_tuv_usage_stats: delta TUV normalizovaná na °C/min délkou mezery
mezi řádky (gap_min), mezery > 30 min vyloučeny; pro hustá 1min data
numericky identické s původním LAG.
- vw_pool_pump_day_energy: komentář — on_minutes drží invariant „zapnuté
čerpadlo se ukládá každou minutu".
Pro hustá 1min data beze změny výsledků; připravuje idle-skip zápisů
v telemetry_collector (navazující commit).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Skutečná příčina 600k buffers: CTE factor/factor_raw (single-ref) PG inlinuje
do projekce with_factor → fn_pv_forecast_correction_factor (48 ms / 1.9k
buffers) se vyhodnocovala ~300× per výstupní slot. Plan cache s tím neměl nic
společného (dřívější count(*) měření projekci zahodilo, proto vycházelo
0.42 s). Faktor se teď počítá jednou do v_rolling_factor a vkládá jako
literál (13. argument format).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
set plan_cache_mode=force_custom_plan na SQL funkci v PG 18 nezabral (stále
generický plán, 4.5-9 s / 600k buffers). plpgsql EXECUTE s literály = vždy
čerstvý plán: tělo s konstantami změřeno 0.42 s / 34k buffers. Signatura,
chování i výstup beze změny.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1) full_status._iso_utc dostával z JSONB bundle stringy → AttributeError → 500
celého /status/full; nyní parsuje přes _parse_ts.
2) /plan/compare: NameError — 'comparison = _bundle_from_current(compare_raw)'
se nikdy nesestavilo (smazaný řádek), endpoint vždy 500.
3) fn_forecast_pv_slots_range_canonical_ab: PG 18 cachuje plány SQL funkcí →
generický plán 4.5 s / 607k buffers; set plan_cache_mode=force_custom_plan
→ 0.4 s / 34k (změřeno explain analyze na živé DB). Táhne /plan/current,
/plan/compare i rolling plánovač.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Endpoint GET /sites/{id}/forecast/pv-slots-corrected (dashboard) volal těžkou
fn_pv_forecast_delta_profile inline (~44 s/site na prod) — uživatel: 45 s
response, telemetry endpoint vyhladověl. Kanonická plánovací řada (R__088) už
cache používala, R__079 ne. Cache je pro všechny 4 lokality naplněná, čtenář
po HOTFIX 2/2 nikdy nepočítá.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Od uživatele po 42883 incidentu (R__018 comment na staré signatuře shodil
2 deploye): odkaz přes signaturu se rozbije při každé změně parametrů.
R__018 převeden na bez-parametrovou formu, pravidlo v CLAUDE.md Konvencích.
Zbylých 51 parametrizovaných comment on / 6 dropů v repu funguje (míří na
aktuální signatury) — normalizovat při dotyku.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Throttle commit změnil signaturu fn_refresh_site_pv_delta_profile_cache na
(int, boolean default false), ale comment on function dál mířil na (int) →
repeatable migrace selhala (function does not exist), oba deploye (7da7205
i 18bf93a) spadly — na produkci NENÍ nic z delta hotfixů. PATCH kalibrace
nově volá refresh s p_force=true (throttle nesmí zadržet přepočet po změně
parametrů).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Postřeh uživatele odhalil druhou půlku problému: _cached getter měl
max_age 30 min s INLINE fallbackem na plný 44s přepočet — dosud to maskoval
15min refresh; po throttlu refresh jednou za 6 h by KAŽDÉ čtení po
vystárnutí cache (plan/current, canonical sloty plánovače) spouštělo 44 s.
Čtenář teď vrací cache bez ohledu na stáří; počítá výhradně refresh
(throttle 6 h + denní catch-up). Inline jen first-run/analytická okna.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OTE import dnes spadl (InvalidParameterValueError: unrecognized format()
type specifier '.') — denní cenové signály poprvé trefily větev s %.3f/%.2f;
PG format() zná jen %s/%I/%L. Náhrada %s + round(x, N) ve všech 7 výskytech.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Uživatel: 'potřebuju do X % (tvrdý), ale klidně dobij na 100 % když je to
skoro zadarmo; při záporných cenách radši do auta než nechat na střeše'.
- V094 asset_vehicle.opportunistic_value_czk_kwh (default 1.0; = hodnota
ušetřeného BUDOUCÍHO nabíjení — auto neumí zpět, žádný noční prodej)
- R__039 ev_sessions: + headroom_wh ((100−target) % kapacity) + opp value;
session se nenuluje po dosažení targetu, dokud má headroom
- solver_v2: dekompozice Σ(EV) == needed − unmet + opp, opp ∈ [0, headroom],
odměna opp×value; zároveň FIX latentního bugu — při buy<0 chyběl strop
celkové energie do auta (model mohl pumpovat bez limitu)
- 3 testy (neg ceny sají nad target po strop; běžné ceny ne; cap při opp=0);
eval fixtures beze změny (sessions null)
Víkend (pátek nízký tvrdý cíl + víkendová negativa → samo doplní do 100 %)
vyplývá z mechanismu, žádná speciální logika.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
KV1 pozorování uživatele: ráno baterie na 11 % (min 10), prodává se do sítě
— nenadálý odběr/mrak by se kupoval za fixních 6.35. v1 mělo denní rampu
(safety_soc_target_wh z R__063: reserve 30 % ráno → reserve+noc večer,
6-19 h, flag planner_daytime_charge_target_enabled) — v2 ji ignoroval.
Mechanismus (vzor nočního polštáře): deficit pod rampou platí za KAŽDÝ slot
nájem buy×faktor (V091 asset_battery.planner_safety_soc_risk_factor,
default 0.05; 0=vypnuto) → ráno se nejdřív doplní rezerva (4 h deficitu
1 kWh při buy 6.35 ≈ 5.1 Kč > sell ~2.5), extrémní sell špička smí deficit
racionálně podstoupit. R__039 + db_io + 2 testy (KV1 scénář, spike).
Eval fixtures beze změny (sloupec v context_json fixtures není → 0);
živá produkce dostane faktor přes fn_planning_site_context.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
v1 to řešil rampou (plný výkon než se řeže pole A — zelený bonus B, riziko
večerního mraku). v2 byl k načasování v okně sell<0 indiferentní (PV zdarma
kdykoliv) a směl nabíjení odložit — odklad ale spoléhá na predikci.
Mechanismus: malá prémie za držení energie dřív (objective −= soc[t] ×
frontload v neg slotech). Rozbíjí indiferenci směrem k front-loadu, nikdy
nepřebije skutečné ceny. Velikost z DB: asset_battery.
planner_pv_risk_frontload_czk_kwh (V090, default 0.01; 0 = vypnuto),
přes fn_planning_site_context (R__039). Test: 4 sloty plným tempem od startu.
Eval fixtures beze změny (sloupec v nich není → 0).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pravidlo 15: měřená řízená zátěž nesmí špinit bazální křivku — dosud se
odečítalo jen EV a TČ. Ruční chod čerpadla (vysávání…) i plánovaná filtrace
se nyní přiřazují zařízení, ne bazálu.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- services/tesla_client.py: access token s cache + ROTACE refresh tokenu do
ems.tesla_token (env jen seed — Tesla refresh token je jednorázový),
vehicles → vehicle_data?endpoints=charge_state, 408 (spící auto) = tiché
přeskočení, výběr vozidla dle VIN / jediného na účtu (VIN se auto-naučí)
- hook _patch_session_from_tesla v _on_ev_arrival: PŘED replanem doplní
soc_at_connect_pct (+ target z charge_limit_soc) do otevřené session přes
fn_ev_session_apply_patch (rozšířena o soc_at_connect_pct) — energii si
odvodí fn_planning_site_context (SQL-first); selhání neblokuje replan
- V086: asset_vehicle.vin, api_type='tesla' pro tesla-my (Model Y, home-01),
singleton ems.tesla_token; R__095: fn_tesla_token_get/upsert,
fn_tesla_arrival_context, fn_vehicle_set_vin
- config: TESLA_CLIENT_ID/SECRET/REFRESH_TOKEN (prázdné = vypnuto)
- testy parserů; plná sada beze změny
Aktivace: env do /opt/ems-deploy/.env + recreate backendu (docs/tesla-fleet-api.md §Stav).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bod 1 — write_ev_setpoints reálně (konec TODO stubu):
- reg 15 (0=stop, 6–32 A) z plánu přes _current_limit_for_charger; plná
journal pipeline (create_modbus_commands → execute, verify job 2 min generic)
- watchdog reg 19=300 s + reg 20=8 A: výpadek EMS → wallbox po 5 min failsafe
8 A (auto se přes noc nabije); drop-unchanged → zapisuje se jen při změně
- fn_modbus_last_verified_map: + p_asset_type (drop 2-arg; dosud hardcoded
'inverter' — pro chargery vracela {})
- verify: SELF_SUSTAIN fallback explicitně jen pro asset_type='inverter' —
mismatch wallboxu nesmí degradovat režim celé site
- journal register_name: mimo inverter platí jméno od volajícího
Bod 2 — telemetry_collector: přechod available→connected spustí fire-and-forget
run_rolling_replan(triggered_by=ev_arrival:<code>) + export_setpoints přes BG
pool — reakce na příjezd ~60 s místo až 15 min.
Bod 3 (Tesla API SoC) čeká na developer credentials.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
poll_ev_chargers četl placeholder ('available'/0 W) — EV spotřeba se nikdy
neodečítala z bazálu a session detekce nefungovala. Nyní: blok registrů 0-40
jedním FC 3 (oficiální protokol rev 0.5), parse_teltocharge_frame (status z
reg 6 → available/preparing/charging/..., výkon reg 38, energie session reg 39,
proud max L1-L3 reg 3-5). Při selhání čtení se vzorek NEzapisuje (fabrikovaný
available by falešně ukončoval session).
fn_telemetry_ev_charger_sample: + p_current_a (drop staré 7-arg signatury).
6 nových testů parseru; plná sada beze změny. Docs: modbus-registers-teltocharge.md.
Po deployi: home-01 ev-charger-1/2 začnou posílat reálná data; bazál se začne
čistit od EV (EMA 00:30); rebuild stats má smysl až po ~2 týdnech čisté historie.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Force PASSIVE/no-export when sell is negative or export_mode is NONE,
and alert NEG_SELL_EXPORT in plan_actual_slot_guard when export still occurs.
Co-authored-by: Cursor <cursoragent@cursor.com>
SoC continuity now deducts only bd (ge_bat was double-counted via energy
balance), which stopped the plan from draining ~2× faster than BMS during
evening BATTERY_SELL. Also ships dynamic evening push budget + rolling
hysteresis (v38), drops unused fn_soc_tracking_bundle, and adds tests/docs.
Co-authored-by: Cursor <cursoragent@cursor.com>
