deye_battery_charge_discharge_amps: v PASSIVE+PV_SURPLUS reg 108 = max když plán
chce nabíjet (bat_w>0) místo tvrdé 0; baterka nabere co zvládne, přebytek nad
nabíjecí rychlost do sítě. + kalibrace: SoC u maxima → dojet na 100% (BMS). Sell
beze změny. Vědomě přepsán test starého chování. 365 passed. Všechny Deye lokality.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
11000 W / (3x230) = 15.94 A; int() useklo na 15 A (~10.35 kW), round da
spravnych 16 A (~11 kW). Strop 32 A drzi horni mez. 74 control testu zelenych.
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 (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>
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>
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>
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>
_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>
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>
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>
