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>
Zrcadlo sekce 3 (buy: min(buy) != cena zásoby) na prodejní straně: baterie se
nevyprodá do jednoho slotu (strop 13.5 kW = 3.4 kWh/15min), rozloží se přes
více slotů s klesající cenou. Rozhodnutí drzet vs vybit = proti MARGINÁLNÍ
ceně (nejnizsi pouzity slot), ne spicce. Konkrétní příklad večer 2026-06-14
+ caveat terminal value za horizontem (jeden skalár, ne marginální).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Prioritizovany backlog (TL;DR, Tier 1-3, rozdelane, rizika, dozraje casem).
Nejzavaznejsi nalez: golden gate NEbeztzi v CI (deploy.yml = jen migrace+validate+
deploy) -> ochrana solveru je v nasazeni iluzorni. K review uzivatelem.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Faze 0 (battery guard + EV reg15/session, V106) zustala na serveru nenasazena
(V105) — prazdny re-trigger commit se neprojevil. Tento neprazdny commit na main
(unikatni SHA, ref=main) spusti realny deploy.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
_apply_export_plan_guard / _build_setpoints: kdyz slot CHARGE / importuje na
nabiti baterie (grid_sp>0 & bat>0), guard vrati sp beze zmeny a export_ban se
nenastavi. Opravuje, ze se baterie nedobila v zapornych cenach (CHARGE+17kW
prekloplen na PASSIVE -> Deye nenabijel ze site). Diagnoza: agent a599eecc.
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>
Zivy incident home-01 (TeltoCharge .16): od ~22:45 UTC 12.6. nevznikl zadny
telto journal radek (ani failed), auto jelo failsafe 8 A misto planovanych 0 A.
Root cause: reg 15 (amps) byl write-on-change proti journalu
(fn_modbus_device_state_map). Jakmile mel reg 15 radek "0 verified" a plan
dal chtel 0, NIKDY nevznikl novy prikaz -- a TeltoCharge si po vypadku
komunikace sam prepsal reg 15 na failsafe (reg 20) BEZ journal radku. Verify
cte zpet jen 'written' radky, takze tichy drift 0 -> 8 A nikdo nevidel ani
neopravil.
- reg 15 (amps to use) se zapisuje VZDY (re-asert) -- volatilni ridici
registr, ne EEPROM; drzi verify jobu cerstvy written radek -> drift se
zachyti a hned opravi. _split_amps_and_watchdog odděluje 15 od 19/20.
- reg 19/20 (watchdog config, EEPROM) zustavaji write-on-change.
- per-charger failsafe/timeout: asset_ev_charger.watchdog_failsafe_a /
watchdog_comm_timeout_s (V106; default 8 A / 300 s). "Zakaz nabijeni" =
reg 15 = 0 (protokol rev 0.5 nema samostatny enable registr).
- testy test_ev_write_on_change.py; docs teltocharge + journal + data-model.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dle dotačních podmínek WB2 řídí elektroměr; EMS na něj přestane sahat
(poll i zápisy) — uvolní RS485 bránu. Zpětné zapnutí = 2 UPDATE
(komentář migrace + teltocharge doc).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Calendar-bound filozofie (majitel): parametr = šumový floor, ne plná cena
cyklu. Odemyká mělčí arbitráže na malých packech. Detail v changelogu.
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>
scripts/harness/hu1_realistic_eval.py — realistická simulace BESS 128 kWh/36 kW
na spotu místo perfect hindsight: D−1 plán přes solve_dispatch_v2 (informační
množina = ceny zítřka z OTE D−1 13:30), SoC řetězené mezi dny, parametry
baterie/grid z DB site 5 (fn_planning_site_context). Scénáře fix/spot ×
bez/s baterií, Kč/den po měsících a sezónách, roční projekce, citlivosti
(degradace 0.15/0.5/1.0, spread compression −30 %), GAP vs 7denní hindsight.
Varianty běží paralelně (ProcessPoolExecutor). HU1 nemá telemetrii →
parametrizovaný průmyslový odběr (konstanty v hlavičce, přepsat čísly
od majitele); fixní cena = proxy BA81 (--fix-buy).
Výsledky (788 dní 2024-04-14…2026-06-12, 2 zimy): D−B (přechod na spot
s baterií) −163,6 tis. Kč/rok base, konzervativně −110,1 tis.; léto −629,
zima −254 Kč/den, nejhorší měsíc (12/2024) −41 Kč/den — stále úspora.
GAP realistic vs hindsight ≈ 0 (ceny jsou D−1 známé) → dřívější horní mez
byla nadhodnocená sezónností, ne neznalostí budoucnosti.
Doc: docs/studies/hu1-spot-realistic.md (generuje skript, opakovatelné);
README harness doplněn.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Rozchozeno po třech vrstvách: protokol převodníku Modbus TCP to RTU
(byl None), parita EVEN, adresa MIM 5 (seed měl 1). První živé čtení:
EHS typ 115, comm ready, mode heat, prostor 20 °C, voda 54.4 °C, TUV
zásobník 46.6 °C, bez chyb. Defrost reg: 0 i 0xFF znamená OFF (manuál),
bool() by 255 četl jako zapnuto.
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>
Arrival zpráva má dva persistent Selecty (custom_id ev:<site>:<charger>:dep
a :tgt, obsluha on_interaction + regex → přežijí restart):
„Kdy odjíždíš?" za 2 h | za 4 h | dnes večer 18:00 | zítra ráno 7:00 |
zítra poledne 12:00 | pondělí ráno 7:00; „Kolik potřebuješ?" 30/50/70/100 %
| Nenabíjet. Každý výběr okamžitě PATCHne session přes
fn_ev_session_apply_patch jen ve své dimenzi (absolutní deadline
Europe/Prague, nejbližší budoucí výskyt; pevná volba smí přes 48 h),
druhý rozměr zůstává z fn_ev_session_defaults. Pak replan + export a edit
zprávy přepočteným plánem (build_ev_plan_summary) + potvrzením. Whitelist
DISCORD_ALLOWED_USER_IDS i bot-first/webhook fallback beze změny; legacy
tlačítka h2/h4/morning/full/stop starších zpráv dál obsloužená.
Testy: mapování výběr→patch, absolutní deadline z voleb (půlnoc, pondělí
z pátku >48 h, pondělí ráno v pondělí), parse, legacy akce — bez DB/sítě.
Docs: discord-ev-interaction.md (nové UI, no-click = pohotovostní režim
30 % + oportunismus).
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>
Slabý server: dict (tabulka, asset_id) → (signature, last_stored_at);
_idle_skip ukládá vždy při změně signature, aktivitě, po startu procesu
a heartbeat po > 840 s (každý 15min bucket má ≥ 1 řádek).
- telemetry_ev_charger: aktivní = status != 'available' nebo power > 50 W;
signature (status, výkon na 100 W)
- telemetry_pool_pump: aktivní = is_on nebo power > 5 W (ON řádky 1/min
kvůli on_minutes); signature (is_on, výkon na 10 W)
- telemetry_loxone_sensor: jen změna hodnoty ≥ 0.1 / heartbeat
- telemetry_heat_pump: aktivní = mode != 'off' nebo defrost; signature
(mode, teploty na 0.2 °C)
- telemetry_inverter: beze změny — NIKDY se nepřeskakuje (audit Wh split,
baseline, SoC plánovače)
Detekce příjezdu/odjezdu EV: previous_status přesunut z posledního řádku DB
do in-memory _EV_LAST_STATUS (po startu seed z vw_latest_ev_charger —
přechod během výpadku se pozná, prázdná DB nevystřelí falešný příjezd);
fn_ev_session_transition se volá jen při změně statusu.
PoolCard: staleness práh 5 → 16 min (> heartbeat 840 s).
Docs: telemetry.md sekce „Idle-skip zápisů" (pravidla pro nové čtecí dotazy:
sumy/gapfill, ne avg přes řádky), planning-changelog (TUV °C/min).
Testy: tests/test_telemetry_idle_skip.py — _idle_skip jednotkově + EV
arrival/departure přežije skip i restart procesu (303 passed).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nahrazuje placeholder IP 192.168.1.101/.102 ze seedu; sdílená sběrnice
s plánovaným Chint elektroměrem (unit 3). Teltonika strana čeká na povolení
Modbusu v aplikaci.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
_apply_export_plan_guard při export_mode=NONE (plán nabíjí baterii, neexportuje)
vynucoval _passive_no_export_guard s export_ban=True + deye_gen_cutoff_enabled=True
bez ohledu na cenu -> reg 178 bity 0-1=3 (MI cutoff) + reg 145=0 a mikroinvertory
(pole B) fyzicky stály i při sell +1.36 Kč (BA81 dnes: gen port ~0 W od 12:16Z,
SoC 64 %, stringy 4.2 kW do baterie). Tvrdý ban nově JEN při záporné vykupní;
při kladné guard dál drží PASSIVE/143=0/baterie nevybíjí do sítě, ale MI jedou
(absorbce do baterie, přetok se prodá). Plánový z_gen_cutoff se respektuje.
Pre-existing fail test_neg_buy_and_sell_with_pv_b_forces_pv_a_off padá i na main
(pv_a_allowed_w None != 0) — nesouvisí, řešit zvlášť.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
V dev portálu je registrováno https://ems.vojacek.eu/t-auth — docs i setup
skript diktovaly /tesla/callback (mismatch = invalid_auth_code / chybné
návody). Caddy blok nově servíruje callback stránku na /t-auth (rewrite).
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>
- R__097: vw_latest_pool_pump + vw_pool_pump_day_energy (denní kWh z delty
čítače, minuty běhu) + ems_anon granty
- PoolCard na Dashboardu: stav/W/dnešní kWh+hodiny/7denní mini sloupce
- _notify_ev_arrival_plan: po příjezdu EV Discord souhrn (SoC auta → cíl,
deadline, nabíjecí okna shlukovaná ze slotů aktivního plánu, ø cena)
- docs/discord-ev-interaction.md: fáze B (bot s tlačítky přes gateway —
žádný veřejný endpoint; čeká na DISCORD_BOT_TOKEN od uživatele)
- docs: pool-shelly + ev-charging aktualizovány (pravidlo docs 1:1)
První commit na dev větvi (nová kadence: deploy až s milníkovým merge).
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>
Doména slouží jen jako veřejná vizitka pro Tesla: Caddy blok vystavuje POUZE
.well-known public key a statickou OAuth callback stránku (zobrazí ?code=,
nic neodesílá), vše ostatní 404 — EMS zůstává na VPN. Certifikát Let's Encrypt
řeší hostovský Caddy automaticky.
deploy/tesla/setup_tesla_domain.sh (spustit NA SERVERU): EC keypair prime256v1
(privátní do /opt/ems-deploy/secrets 0600), public do .well-known, callback,
vypíše Caddy blok. docs/tesla-fleet-api.md: developer portál, partner
registrace, OAuth flow, plán EMS integrace (tesla_client + hook v _on_ev_arrival).
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>
Klíčová oprava (postřeh uživatele): při sell<0 lokality škrtí výrobu
(reg 340 / GEN cutoff) — telemetrie ukázala 357 kWh, predikce 1879 kWh
(96 % minut v derating). Studie nyní používají max(skutečnost, kanonický
forecast per pole) v sell<0 slotech.
Nové výsledky (horní meze): BA81 32 kWh +35/+46 Kč/den (výkon 6.25/12 kW);
KV1 25 kWh +20/+22 Kč/den (stará smlouva); HU1 fixní: 75 Kč/den bez sdílení,
149 Kč/den s EDC sdílením @1.5 Kč distribuce (sdílitelných ~49 kWh/den!);
HU1 spot: 372 Kč/den, sdílení +0. + docs/onboarding-wallbox-tc-2026-06.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- docs/refactor-clean-planner.md: plán Fází 0-4, stav, závazná pravidla
(golden gate), návod nasazení v2 (shadow → vyhodnocení → přepnutí)
- docs/planning-changelog.md: záznam 2026-06-11 (Fáze 0-3 kompletní)
- docs/04-modules/planning.md: sekce Verze enginu v1/v2 + env flagy
- docs/audits/*: stav implementace FE fixů
- .claude/skills/ems-delta-triage: postup triáže neekonomického chování
(realita vs plán vs shadow peer vs oracle, verdikt s Kč)
- CLAUDE.md: ukazatele na refaktor, solver_v2 a delta-triage v 'Kde hledat co'
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
