7decfebdbd
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>
71 lines
3.9 KiB
Markdown
71 lines
3.9 KiB
Markdown
# Teltonika TeltoCharge — Modbus registry (EMS)
|
||
|
||
Zdroj: oficiální „TeltoCharge Modbus RTU Communication protocol" rev 0.5
|
||
(2024-07-23). Připojení: sdílená RS485 sběrnice → Waveshare RS485 TO POE ETH (B) **172.16.1.16:502** (V097; 9600 8N1, Modbus TCP↔RTU; WB1 = unit 1, WB2 = unit 2, plánovaný Chint = unit 3) → Modbus TCP (endpoint
|
||
`site_endpoint`, FC 3 čtení, FC 6/16 zápis). Wallbox musí být v aplikaci
|
||
nastaven jako *secondary (server)*.
|
||
|
||
## Čtení (telemetry_collector, blok 0–40 jedním FC 3)
|
||
|
||
| Reg | Význam | Formát |
|
||
|-----|--------|--------|
|
||
| 0–2 | Napětí L1–L3 | int16, V |
|
||
| 3–5 | Proud L1–L3 | int16, ×10 A |
|
||
| 6 | **EVSE status (DLM)** | 0=C nabíjí · 1–3=B1–B3 připojeno · 4=D1 stop od EV · 5–6=D2–D3 zákaz · 7=A bez EV · 8=F chyba · 9=E |
|
||
| 27 | Charge point state | 0–9 (informativní) |
|
||
| 33 | IEC61851 stav | 0–8 |
|
||
| 34/35 | Warning / Error bity | bitfield |
|
||
| 38 | Okamžitý výkon | uint16, W |
|
||
| 39 | Energie session | uint16, kWh×100 |
|
||
| 40 | Trvání session | uint16, s |
|
||
| 41–44 | Celková energie (FW ≥1.13) | uint64, kWh×100 |
|
||
|
||
Mapování stavů v EMS (`TELTO_STATUS_MAP` v `telemetry_collector.py`):
|
||
7→`available`, 0→`charging`, 1–3→`preparing`, 4→`suspended_ev`,
|
||
5–6→`suspended_evse`, 8→`faulted`, 9→`unknown`. Detekce příjezdu/odjezdu
|
||
(`fn_ev_session_transition`) stojí na přechodu `available` ↔ ≠`available`.
|
||
|
||
**Při selhání čtení se vzorek NEzapisuje** — fabrikovaný `available` by falešně
|
||
ukončil session a EV výkon 0 by špinil bazál (pravidlo 15).
|
||
|
||
## Zápis (control exporter — `write_ev_setpoints`, `write_ev_arrival_hold`)
|
||
|
||
| Reg | R/W | Význam | Hodnoty | EMS zapisuje |
|
||
|-----|-----|--------|---------|--------------|
|
||
| 15 | R/W | **Amps to use** (limit proudu) | 0 = stop, 6–32 A | hodnota z plánu (`ev{1,2}_current_a`); příjezd EV → hold 0 A |
|
||
| 16 | R/W | Start/Stop session | 0 nic · 1 stop · 2 start | ne |
|
||
| 19 | R/W | Communication timeout (watchdog) | 0–600 s (0 = vypnuto), default 30 | `TELTO_WATCHDOG_TIMEOUT_S` = **300** |
|
||
| 20 | R/W | Failsafe current | 0, 6–32 A, default 6 | `TELTO_WATCHDOG_FAILSAFE_A` = **8** |
|
||
|
||
Všechny čtyři registry jsou dle oficiálního protokolu (wiki *External control
|
||
RS485* / protokol rev 0.5) **R/W** — verify job je čte zpět standardní FC 3
|
||
větví (žádný write-only registr v této sadě).
|
||
|
||
### Write-on-change — POVINNÉ (EEPROM wear)
|
||
|
||
Export tick běží ~8×/hod (control_export `:14,:29,:44,:59` + rolling replan
|
||
`*/15` s exportem). Zápis do wallboxu se proto provádí **jen při skutečné
|
||
změně hodnoty**: `write_ev_setpoints` i `write_ev_arrival_hold` filtrují
|
||
registry přes `_drop_registers_matching_last_verified` proti
|
||
**`ems.fn_modbus_device_state_map`** (nejnovější řádek journalu per registr
|
||
se stavem `written` **nebo** `verified`). Důsledky:
|
||
|
||
- **reg 15** se zapíše jen při změně plánovaného proudu (0 ↔ 6–32 A) — to je
|
||
legitimní zápis;
|
||
- **reg 19/20** se zapíší jednou po nasazení / po výpadku zařízení (nejnovější
|
||
řádek `failed`/`mismatch` ⇒ registr v mapě chybí ⇒ znovu se zapíše) a pak
|
||
už nikdy, dokud se hodnota nezmění;
|
||
- čekání na verify **neblokuje** skip — `written` (TCP ack) stačí, mismatch
|
||
z verify stav mapy zneplatní a vynutí nový zápis.
|
||
|
||
### Watchdog — sytí ho i čtení
|
||
|
||
Protokol definuje timeout jako *„if no **valid communication** is present
|
||
after a configurable time interval…"* — timer resetuje **jakákoli** validní
|
||
Modbus komunikace s unit ID wallboxu, **včetně FC 3 čtení**. Telemetrie čte
|
||
blok 0–40 každých **60 s**, takže watchdog 300 s je trvale sycen čtením a
|
||
**periodické zápisy k udržení spojení nejsou potřeba**. Failsafe (omezení na
|
||
8 A, reg 20 „max allowed current on comm timeout") nastane až po 5 min bez
|
||
jakéhokoli pollingu = skutečný výpadek EMS; auto se pak přes noc dobije
|
||
pomalu místo stání na 0 A.
|