baterie pri sell neklesne pod 20% ale pri normalnim provozu muze jit az k 10%, mame tak rezervu a neohrozime si nahly propad procent battery packu

docs/03-data-model.md

@@ -110,8 +110,8 @@ CREATE TABLE asset_battery (
     inverter_id              INT REFERENCES asset_inverter(id),
     code                     TEXT NOT NULL,
     usable_capacity_wh       INT NOT NULL,         -- 64000
-    min_soc_percent          NUMERIC(5,2) DEFAULT 10,   -- absolutní podlaha LP
-    reserve_soc_percent      NUMERIC(5,2) DEFAULT 20,   -- ekonomická podlaha (export/arbitráž)
+    min_soc_percent          NUMERIC(5,2) DEFAULT 10,   -- provozní spodní mez LP + clamp; u paralelních packů často 11–12
+    reserve_soc_percent      NUMERIC(5,2) DEFAULT 20,   -- ekonomická podlaha; MILP export (ge≥1 W) drží soc[t] ≥ tato rezerva (arb_base_wh)
     max_soc_percent          NUMERIC(5,2) DEFAULT 95,
     charge_efficiency        NUMERIC(5,4) DEFAULT 0.95,
     discharge_efficiency     NUMERIC(5,4) DEFAULT 0.95,

docs/04-modules/control.md

@@ -109,6 +109,8 @@ def apply_overrides(plan, overrides) -> Setpoints:
 
 ## Zápis do Deye (Modbus)
 
+**TOU (time points, reg. 166+):** SOC závisí na fyzickém režimu z `get_deye_mode` — **SELL** zapisuje ekonomickou rezervu (`reserve_soc_percent`), **PASSIVE** a neaktivní řádky **3–6** provozní minimum (`min_soc_percent`). Viz [`modbus-registers.md`](modbus-registers.md).
+
 ```python
 async def write_inverter_setpoints(site_id: int, setpoints: Setpoints, db):
     inverters = await db.fetch(

docs/04-modules/modbus-command-journal.md

@@ -30,7 +30,9 @@ Implementace: `services/control_exporter.py` — `verify_modbus_commands`, `_swi
 
 ## Střídač (Deye)
 
-`write_inverter_setpoints` přidá do journalu mimo **62–64** (čas) a **time pointy 148–177** také řádky pro **108** (max charge A), **109** (max discharge A), **141** (energy mode, vždy 0), **142** (limit control), **178** (pevné hodnoty 32 / 48 podle fyzického režimu, bez read-modify-write), **143** (export limit W). Každý řádek daného exportního běhu má vyplněný **`deye_physical_mode`** (**PASSIVE** / **SELL** / **CHARGE**) pro audit přepínání. **Reg 191** EMS nezapisuje (SolarmanApp). Převod výkonu baterie na proud: `battery_watts_to_amps` viz `modbus-registers.md`. Všechny zápisy journalu jdou přes **`write_registers`** (FC **0x10**), ne FC 0x06. Detail režimů a registrů: `docs/04-modules/modbus-registers.md`.
+`write_inverter_setpoints` přidá do journalu podle potřeby **62–64** (čas — ne každý export) a **time pointy 148–177** (bloky 3–6 typicky jednou denně; viz `modbus-registers.md`), dále **108**, **109**, **141**, **142**, **178**, **143**. Každý řádek daného exportního běhu má **`deye_physical_mode`** (**PASSIVE** / **SELL** / **CHARGE**). **Reg 191** EMS nezapisuje (SolarmanApp). Převod výkonu: `battery_watts_to_amps` v `modbus-registers.md`.
+
+**Dávky:** `execute_modbus_commands` slučuje souvislé adresy do jednoho **`write_registers`** (FC **0x10**). `verify_modbus_commands` čte zpět po souvislých blocích (`read_holding_registers`, FC 0x03). Detail režimů: `modbus-registers.md`.
 
 ## APScheduler
 

docs/04-modules/modbus-registers.md

@@ -23,7 +23,7 @@ EMS zapisuje řídící hodnoty přes journal (`modbus_command`) a **`write_regi
 | 190 | GEN peak shaving | 0–16000 | 1 W | Peak shaving na GEN portu |
 | 191 | Grid peak shaving power | 0–16000 | 1 W | **EMS NEZAPISUJE** – nastavit **manuálně v SolarmanApp**. Hodnota určuje výkon peak shavingu v **W**. |
 
-`control_exporter.write_inverter_setpoints` zapisuje přes **`modbus_command`** (journal + verifikace) po řadě: **62–64** (čas), **time points 148–177**, **108, 109, 141, 142, 178, 143**. Popisné názvy registrů v DB bere `DEYE_REGISTER_NAMES` v `control_exporter.py`. **Reg 191** do journalu nepatří – EMS ho nezapisuje.
+`control_exporter.write_inverter_setpoints` zapisuje přes **`modbus_command`** (journal; jeden řádek na registr) a **`execute_modbus_commands`** odesílá **souvislé bloky jedním FC 0x10** (např. 62–64, 148–159, 166–177, 108–109, 141–142 podle toho, co je ve frontě). Pořadí v journalu: **62–64** (čas, viz níže), **time points 148–177** (jen řádky zařazené do daného běhu), **108, 109, 141, 142, 178, 143**. Popisné názvy v DB bere `DEYE_REGISTER_NAMES`. **Reg 191** EMS nezapisuje.
 
 ### Reg 191 (výkon grid peak shaving)
 
@@ -68,7 +68,7 @@ Všechny limity (`max_charge_a`, `max_discharge_a`, `max_export_power_w` / reg 1
 
 ## Time Points – řízení podle fyzického režimu
 
-Deye má 6 časových bloků. EMS přepisuje **bloky 1–2** při každém `control_export` (cron např. :14, :29, :44, :59).
+Deye má 6 časových bloků. EMS přepisuje **bloky 1–2** (TOU index 0–1) při každém `control_export`. **Bloky 3–6** (neaktivní výplň, čas **2355**) zapisuje **nejednou častěji než jednou za kalendářní den v Europe/Prague** a **okamžitě znovu**, pokud se změní **podpis** `deye_tou_inactive_signature` (`HHMM|min_soc|reserve_soc|tp_discharge_w`) — metadata v `asset_inverter` (V028 + V029 komentář).
 
 **Výběr aktivního segmentu na invertoru:** platí poslední časový bod, jehož **HH:MM ≤ aktuálnímu času** na hodinách střídače (po synchronizaci 62–64). Proto **nesmí** zůstat jako jediný „minulý“ bod např. **00:00** s pasivním profilem, zatímco profil s nabíjením ze sítě je až u budoucího času – mezi půlnocí a tím budoucím časem by invertor celou dobu používal špatný segment.
 
@@ -76,7 +76,7 @@ Deye má 6 časových bloků. EMS přepisuje **bloky 1–2** při každém `cont
 |------|---------------------------|-------------|------|---------|-------------|
 | 1 | **`current_slot_hhmm()`** – začátek **probíhajícího** 15min slotu | `planning_interval` pro **aktuální** slot (`_fetch_plan_row_for_slot_offset(..., 0)`) | PASSIVE / SELL / CHARGE dle `_deye_tou_params` | viz tabulka níže | viz tabulka níže |
 | 2 | **`next_slot_hhmm()`** – začátek **následujícího** 15min slotu | `planning_interval` pro **další** slot (`_fetch_plan_row_for_slot_offset(..., 1)`) | Přechod na další čtvrthodinu | viz tabulka níže | viz tabulka níže |
-| 3–6 | **23:55** (2355) | — | Neaktivní (rezerva); ne 23:59 — firmware Deye často 2359 neuloží → verify mismatch | `reserve_soc` (DB) | NE |
+| 3–6 | **23:55** (2355) | — | Neaktivní (pasivní profil); ne 23:59 — firmware Deye často 2359 neuloží → verify mismatch | **`min_soc_percent`** (DB) | NE |
 
 **Registry 108 / 109 / 142 / 178 / 143** odpovídají **aktuálnímu** plánu (okamžitý výstup; `setpoints_now` v `write_inverter_setpoints`). TOU řádky 1–2 doplňují stejnou logiku pro časové segmenty (`_deye_tou_params`).
 
@@ -84,23 +84,25 @@ Příklad v 14:18: blok 1 má čas **1415**, blok 2 čas **1430** – mezi 14:15
 
 ### Fyzické režimy Deye – parametry jednoho time pointu (bloky 1–2)
 
-| Režim | Výkon (W) | SOC min | Grid charge |
-|-------|-----------|---------|-------------|
-| **PASSIVE** | `max_discharge_a × 51,2` | rezerva z DB | NE |
-| **SELL** | `max_discharge_a × 51,2` | rezerva z DB | NE |
+| Režim | Výkon (W) | SOC min (reg 166+) | Grid charge |
+|-------|-----------|---------------------|-------------|
+| **PASSIVE** | `max_discharge_a × 51,2` | **`min_soc_percent`** z DB | NE |
+| **SELL** | `max_discharge_a × 51,2` | **`reserve_soc_percent`** z DB | NE |
 | **CHARGE** | `battery_watts_to_amps(battery_w, max_charge_a) × 51,2` | min(95, cíl SoC z plánu nebo 80) | ANO |
 
-Bloky 3–6 zůstávají na **23:59** s pasivním profilem (`reserve_soc`, grid charge = NE).
+Bloky 3–6 používají čas **2355** a stejnou **SOC** hodnotu jako PASSIVE (`min_soc_percent`, grid charge = NE).
 
 ### Synchronizace času
 
-Registry **62–64** se při každém `control_export` nastaví na aktuální čas v **Europe/Prague**:
+Registry **62–64** nastavují invertoru čas v **Europe/Prague**. **EMS je do fronty nezařadí**, pokud ještě neuplynula **nová kalendářní minuta** oproti poslednímu úspěšnému zápisu (sloupec `asset_inverter.deye_last_system_time_sync_minute`). Jinak platí:
 
 - reg **62:** `(rok - 2000) << 8 | měsíc`
 - reg **63:** `den << 8 | hodina`
 - reg **64:** `minuta << 8 | sekunda`
 
-Zápis time pointů i systémového času prochází stejným **`modbus_command`** journal jako registry 108 / 109 / 141 / 142 / 178 / 143 (FC 0x10 po jednom registru).
+Zápis prochází journal jako každý jiný registr; na sběrnici jde souvislý blok **FC 0x10**.
+
+**Před vytvořením journalu:** pokud je navrhovaná hodnota **shodná s posledním `verified`** záznamem daného registru v `modbus_command`, EMS **řádek nevytvoří** a na Modbus neposílá (žádný „X → X“ zápis jen kvůli periodickému exportu). Výjimky řeší stávající logika (nová minuta u 62–64, denní TOU 3–6 + meta sloupce na `asset_inverter`).
 
 ### Mapování registrů (time point *i*, i = 0…5)
 

docs/04-modules/planning.md

@@ -13,8 +13,9 @@
 - **Runtime guard v exportu setpointů:**
   - při `AUTO` + `is_predicted_price=true` se na exportní vrstvě vynutí PASSIVE/no-export chování.
 - **Ekonomika baterie:**
-  - `min_soc_percent` = tvrdá spodní mez SoC v LP (typicky 10 %),
-  - `reserve_soc_percent` = ekonomická („arbitrážní“) podlaha – pod ní MILP s binární proměnnou omezuje vybíjení tak, aby export z baterie nečerpal hluboké pásmo (typicky 20 %; migrace V027 může vrátit hodnotu po V026),
+  - `min_soc_percent` = nejnižší SoC v LP a runtime clamp telemetrie; u **více paralelních stringů** držet **nad** holým BMS minimem (typicky **11–12 %**; migrace **V029** + komentář v DB, u `home-01` cílený UPDATE z 10 %),
+  - `reserve_soc_percent` = ekonomická („arbitrážní“) podlaha – pod ní MILP s `w_arb` omezuje vybíjení podle začátku slotu a FVE lookahead (`arb_floor_series`; typicky 20 %),
+  - **Export ze site:** binárka `z_export[t]` – pokud `grid_export ≥ 1` W, musí být **koncové** `soc[t] ≥ arb_base_wh` (fixní z DB, **ne** dynamicky snížená `arb_floor_series`),
   - `degradation_cost_czk_kwh` (např. 0.15) / penalizace cyklu v objective symetrická (`0.5*(charge+discharge)`).
 - **PV-aware nejistota:**
   - objective používá `pv_scarcity_factor` (0.65..1.0), odvozený z forecastu slunce,
@@ -184,10 +185,13 @@ soc[0] == current_soc_wh  # počáteční podmínka z telemetrie
 
 ### SoC limity
 ```python
-soc_min_wh <= soc[t] <= soc_max_wh   # min_soc_percent z DB (např. 10 %)
+soc_min_wh <= soc[t] <= soc_max_wh   # min_soc_percent z DB (provozní podlaha, často 11–12 %)
+
+# Ekonomická podlaha (reserve_soc_percent): w_arb[t] + arb_floor_series[t] –
+# bd omezeno podle soc na začátku slotu (žádné „nadbytečné“ vybíjení z hlubokého pásma při exportu z AKU).
+
+# Při grid_export[t] >= 1 W: soc[t] >= arb_base_wh (rezerva z DB, ne časová řada arb_floor).
 
-# Ekonomická podlaha (reserve_soc_percent, např. 20 %): binární w_arb[t] v MILP –
-# pod touto hranicí je bd omezeno na load+EV+TČ+bc (žádné „nadbytečné“ vybíjení pro export z baterie).
 # Měkký buffer na konci 24h dál přes soc_deficit_24h.
 ```
 

docs/06-open-questions.md

@@ -18,6 +18,8 @@ Tento soubor slouží jako živý seznam věcí které je potřeba rozhodnout p
 
 ## Důležité (neblokují, ale řeší se brzy)
 
+- [ ] **Dvě úrovně min SoC v DB** – Dnes jedno `min_soc_percent` (provozní podlaha pro LP i TOU PASSIVE). Budoucí oddělení „tvrdé BMS minimum“ vs „plánovací minimum“ by vyžadovalo nový sloupec nebo politiku per site.
+
 - [ ] **TUV výkon** – Je TUV výkon měřitelný zvlášť nebo jen ON/OFF? Pokud jen ON/OFF, použijeme `asset_flexible_device.max_power_w` jako aproximaci.
 
 - [ ] **Pole B (ongridový)** – Zahrnout do auditu jako "neřízená výroba"? Nebo ignorovat úplně? Komplikuje audit ale zpřesňuje ho.