Správa SOC baterie lokálně: ESPHome, load balancing bez cloudu

Jeden z nejčastějších dotazů, co dostávám, zní takhle: "Davide, mám baterii, mám solár, ale jak to celé skutečně provázat dohromady, aby se to chytře rozhodovalo, kdy nabíjet, kdy vybíjet a kdy nechat přebytek téct do auta?" Odpověď je samozřejmě Home Assistant — ale tentokrát se podíváme na konkrétní přístup: automatizace řízená stavem nabití (SOC) s lokálním load balancingem přes ESPHome. Žádný cloud, žádné předplatné, žádné předávání dat na cizí servery.

SOC jako řídicí proměnná: čtyři zóny, jasná logika

Základ celého systému je jednoduchý nápad: rozděl stav nabití baterie do zón a podle zóny rozhoduj, co smí nebo musí dělat ostatní spotřebiče. Tohle není žádná raketová věda — je to klasická stavová logika, která funguje spolehlivě i v okamžiku, kdy Home Assistant chvíli odpojíte nebo rebootujete.

Inspiraci beru mimo jiné z komunitního projektu Solar Energy Management (SEM), kde autoři propracovali tzv. 4-zónovou strategii baterie:

Zóna	SOC	Chování systému
1	pod 30 %	Vše ze solárů jde do baterie. EV nabíjení zakázáno.
2	30–70 %	Pouze solární přebytek. Baterie EV nepomáhá.
3	70–90 %	Baterie může pomoci EV při výpadcích soláru.
4	nad 90 %	EV startuje i bez solárů. Baterie plně asistuje.

Všechny prahy jsou konfigurovatelné — to je zásadní. Každý systém je trochu jiný: jiná kapacita baterie, jiné spotřebiče, jiné tarify. Rigidní hodnoty napevno zakódované ve skriptu jsou antipattern; správně to chceš mít jako input_number helpery v HA.

Prakticky to v YAML automaci vypadá třeba takhle (zjednodušeně pro zóny 1 a 4):

alias: "SOC Load Balancer - Battery Zones"
trigger:
  - platform: state
    entity_id: sensor.battery_soc
condition: []
action:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.battery_soc
            below: input_number.soc_zone1_threshold
        sequence:
          - service: switch.turn_off
            target:
              entity_id: switch.ev_charger_enable
          - service: number.set_value
            target:
              entity_id: number.battery_max_charge_current
            data:
              value: 40
      - conditions:
          - condition: numeric_state
            entity_id: sensor.battery_soc
            above: input_number.soc_zone4_threshold
        sequence:
          - service: switch.turn_on
            target:
              entity_id: switch.ev_charger_enable
mode: single

Klíčový detail: mode: single — nikdy nechceš, aby se tato automace spustila vícekrát souběžně a přepsala sama sebe. Tohle je přesně ten composite automation pattern, o kterém píše Tim Wiegand na The Candid Startup — všechny akce, které ovlivňují stejný zdroj (v jeho případě Alpha ESS baterii), slučuje do jediné automace. Výsledek: žádné race conditions, žádné překrývající se triggery.

ESPHome jako lokální brána k invertoru: Deye a Modbus registry

Aby celá logika fungovala, potřebuješ spolehlivě číst SOC přímo z bateriového systému — lokálně, bez cloudu. Tady přichází na scénu ESP32 s ESPHome a Modbus RTU komunikace.

Komunitní projekt pro připojení Deye invertoru přes ESPHome ukazuje přesné registry, které potřebuješ číst. Tady jsou klíčové pro battery management:

Entita	Jednotka	Modbus registr
Battery SOC	%	0x00B8
Battery Voltage	V	0x00B7
Battery Current	A	0x00BF
Battery Power	W	0x00BE
Max Charge Current	A	0x00D2
Max Discharge Current	A	0x00D3
Battery Shutdown %	%	0x00D9
Total Load Power	W	0x00B0

GPIO zapojení pro RS-485 adaptér na ESP32 (UART2):

ESP32 pin	RS-485 modul	Poznámka
GPIO16 (RX2)	RO	Receive
GPIO17 (TX2)	DI	Transmit
GPIO5	DE/RE	Direction control
3.3V	VCC	Napájení
GND	GND	Zem

V ESPHome konfiguraci to pak vypadá takto:

uart:
  id: uart_modbus
  tx_pin: GPIO17
  rx_pin: GPIO16
  baud_rate: 9600
  stop_bits: 1

modbus:
  id: modbus_deye
  uart_id: uart_modbus
  flow_control_pin: GPIO5

modbus_controller:
  - id: deye_inverter
    address: 0x01
    modbus_id: modbus_deye
    update_interval: 10s

sensor:
  - platform: modbus_controller
    modbus_controller_id: deye_inverter
    name: "Battery SOC"
    register_type: holding
    address: 0x00B8
    unit_of_measurement: "%"
    accuracy_decimals: 0

ESP32 takto každých 10 sekund stáhne aktuální SOC z invertoru a pošle ho do Home Assistantu přes nativní API — bez jediného bajtu dat putujícího na internet.

Novinkou v ESPHome 2026.2.0 je také nová komponenta SY6970 pro battery management — pokud bastlíš vlastní BMS nebo měřicí uzel, tohle se hodí. A Home Assistant 2026.5 přinesl navíc serial proxy přes ESPHome: ESP32 teď umí převést fyzický sériový port na síťový — takže invertor nemusí být metr od Raspberry Pi, stačí mu být v dosahu WiFi.

Load balancing bez závislosti na cloudu: praktické tipy

Samotný load balancing — tedy dynamické přizpůsobování odběru domácnosti aktuální dostupné energii — je oblast, kde amatérské řešení může překonat komerční produkt. Proč? Protože ty víš, co se děje v tvé domácnosti. Cloud to neví.

Pár zásad, které jsem si ověřil:

1. Pomalé změny jsou lepší než skokové. Pokud měníš nabíjecí proud EV nebo limit výkonu baterie, dělej to postupně — třeba po 5 A každých 30 sekund. Chrání to relátka i samotné baterie. V automaci použij delay nebo lépe repeat smyčku s postupným navyšováním hodnoty.

2. Fallback logika je základ. HA Load Balancer pro belgický trh má krásně udělané ošetření situace, kdy senzor vrátí unknown nebo unavailable — systém automaticky přepne na bezpečné výchozí hodnoty místo toho, aby udělal nesmyslné rozhodnutí. Tohle si zkopíruj do svých automací.

3. Composite pattern zabraňuje chaosu. Jak jsem zmínil výše — mít jednu řídící automaci pro baterii, která reaguje na změnu input_number.target_soc (nastavenou jinou automací počítající předpověď), je správný přístup. Žádné dvě automace by neměly zapisovat do stejného registru najednou.

4. Maintenance dashboard HA 2026.5 sleduje zdraví senzorů. Nový přehled baterií v HA ti zobrazí, které senzory mají slabou baterii nebo přestaly hlásit — to oceníš, jakmile máš v systému desítky entit.

Co z toho vzít

Lokální řízení SOC přes ESPHome a Home Assistant není žádná magie — je to vrstvená architektura: ESP32 čte Modbus registry → Home Assistant dostává entity → automace rozhoduje podle zón → výsledek zapíše zpátky přes Modbus. Celé to běží na tvém hardwaru, tvoje data nikam neodcházejí a výpadek internetu ti nezastaví ani nabíjení auta.

Největší výzva není technická — je to disciplína v návrhu automací. Jedna automace na jeden zdroj, jasné zóny, fallback hodnoty a pomalé přechody. Jakmile tohle máš, máš systém, který funguje spolehlivě rok co rok.

Tak co — zkusíš zónovou strategii na svém systému, nebo máš jiný přístup k load balancingu, který ti funguje líp? Rád si přečtu v komentářích.