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>
Seed přiřadil asset_heat_pump KV1; V096/V101 s where code='home-01' byly
tiché no-opy a endpoint .17 se nikdy nezapsal. KV1 navíc plánoval s TČ,
které nemá. Endpoint TČ nastaven na 172.16.1.17:502 unit 5.
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>
V100 rozšířil view i logiku, ale SELECT v collectoru zůstal bez nového
sloupce — row['deye_zero_export_mode'] padal každou minutu od deploye
287353b (~33 min výpadek inverter telemetrie; EV/pool jely dál v heartbeat
rytmu).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Překročení rezervovaného exportu na fakturačním elektroměru (home-01
13.5 kW) = pokuta v řádu desítek tisíc Kč/kW. Invariant: reg 143
(svorky) <= max_export_power_w (ulice) VŽDY; feed-forward navyšování
o měřenou spotřebu mezi střídačem a CT ZAKÁZÁNO (výpadek spotřeby =
přestřelení ulice). Návrh feed-forwardu z 2026-06-12 večer zavržen
před implementací na pokyn uživatele.
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>
TeltoCharge po připojení kabelu sám rozjede nabíjení svým defaultem; EMS ho
dosud dohnal až exportem setpointů (do 15 min). _on_ev_arrival nyní před
replanem zapíše přes journal telto_amps_to_use=0 (write_ev_arrival_hold),
replan+export vzápětí nastaví plánované ampéry. Watchdog (300 s → failsafe
8 A) zachován — výpadek EMS auto nenechá na 0 A.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Default zůstává vynulování otevřených EV sessions (historické okno bez
session); --keep-ev je zmrazí pro EV scénáře (deadline, měkký cíl, min.
výkon wallboxu). meta.keep_ev ve fixture dokumentuje způsob pořízení.
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>
- 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>
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>
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>
Větev 'slabý úsvit (forecast<1500 W) → reg 340 neposílat' zastínila větev
'buy<0 a sell<0 + pole B → pv_a_allowed=0' — při hluboce záporných cenách
za úsvitu by se pole A nezavřelo. Prohozeno pořadí; opravuje pre-existing
fail test_neg_buy_and_sell_with_pv_b_forces_pv_a_off (293 passed, 4 xfail).
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>
_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>
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>
- list poll 5→10 min; vehicle_data JEN při přechodu asleep→online nebo
max 1×/15 min (data /usr/bin/zsh.002/req); wake nikdy (gate na online)
- otevřená ev_session = auto u wallboxu → ŽÁDNÉ API cally (při AC nabíjení
auto nespí — bez gatu by data tekla celou noc nabíjení)
Odhad: </měsíc (online okna mimo wallbox jsou krátká).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
všechny deploye od ~13:40 (R__082 OTE fix, V094, bot fallback ve frontě).
V093 nebyla aplikována (transakční rollback) — úprava failed migrace je
legitimní (immutability platí pro APLIKOVANÉ); na serveru nutný jednorázový
'flyway repair' (smaže failed záznam z historie).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Všechny site webhook URL jsou NULL a env DISCORD_WEBHOOK_URL nebyl nastaven
→ send_discord vždy skončil na 'not configured, skipping' (uživatel: 'nikdy
mi nic nepřišlo'). Fix: fallback přes bota (REST POST do DISCORD_EV_CHANNEL_ID
— token už v .env, žádný webhook netřeba); webhook má přednost, kdyby ho
uživatel později nastavil per site. Bot navíc při startu pošle '✅ online'
(viditelný důkaz, 1× per deploy).
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>
400 invalid_grant = spálený token rotací NEBO ~10min výpadek po revokaci
souhlasu (Tesla) — místo tracebacku log s návodem a return None (EMS jede
dál na defaultech). deploy/tesla/reauth.sh: authorize URL → výměna → DB →
ověření v jednom kroku (žádná příležitost pro rotační past).
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>
Postřeh uživatele — pásma nízkého výkupu před zápornými okny: mechanismus
měkkého cíle to už řeší (opp 1 Kč/kWh > sell 0.3 → auto vyhraje), test
to dokládá: plná domácí baterka + 9 kW PV → ~17 kWh do auta, minimální export.
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>
Model Y 2025 Standard RWD s LFP: menší pack, ale pravidelné 100 % je žádoucí
(balancování). Kapacita vstupuje do energy_needed a EV usage statistik.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
