Chytrá baterie pod kontrolou: automatizace nabíjení krok za krokem

Máš solární panely, máš baterii, ale baterie se nabíjí a vybíjí tak nějak sama od sebe bez ladu a skladu? Přesně tenhle stav mě štvál nejdéle. Solárky chrlí proud přes poledne, baterie se nabije na sto procent ve dvě odpoledne, zbytek výroby letí do sítě za směšnou výkupní cenu — a večer kupuju drahou elektřinu ze sítě. Přitom stačí pár chytrých automatizací v Home Assistantu a celá logika se otočí ve tvůj prospěch. Pojďme na to.

Proč nestačí „chytrá" aplikace od výrobce baterie

Tohle je první věc, kterou kutilům vysvětluju. Aplikace od Growattu, GivEnergy nebo třeba SAX battery umí základní věci — ukáže ti SOC (state of charge), nastaví časové okno nabíjení. Ale jakmile chceš reagovat na více proměnných najednou — aktuální cenu elektřiny, solární předpověď na zítřek, přítomnost lidí doma, nebo jestli zrovna běží pračka — cloudová appka prostě nestačí. A navíc: spoléháš na to, že výrobcův cloud funguje. Spoiler: občas nefunguje.

Home Assistant tohle řeší lokálně. Žádný cloud, žádné předplatné, žádné odesílání dat kamsi do světa. Vše běží na tvém Raspberry Pi nebo mini PC doma.

Integrace baterií přes HACS nebo Modbus

Záleží na tom, co máš doma za baterii. Dobrou zprávou je, že v HACS (Home Assistant Community Store) najdeš integrace pro většinu běžných systémů:

• Alpha ESS — oficiální integrace, nabízí akci alphaess.setbatterycharge pro přímé nastavení nabíjecích oken a cílového SOC
• GivEnergy — přes HACS, exponuje entity jako select.givenergy_charge_mode a sensor.givenergy_battery_percent
• Zendure SolarFlow 2400 AC+ — oficiální HACS integrace exponuje stav baterie, výkon a power manager napojitelný na P1 metr
• SAX Battery — komunitní integrace přes Modbus TCP, trochu víc bastlení, ale funguje skvěle a jsi úplně offline

Pro Modbus TCP připojení (SAX a podobní) to vypadá v configuration.yaml zhruba takto:

modbus:
  - name: SAX_Battery_A
    type: tcp
    host: 192.168.1.50
    port: 502

A pak píšeš přímo do registrů přes modbus.write_register. Trochu víc low-level, ale máš absolutní kontrolu.

Kompozitní automatizace: jeden celek místo chaosu

Tady je klíčový koncept, který mi osobně hodně věcí zjednodušil. Pokud máš víc automatizací, které sahají na stejný zdroj — třeba nastavení nabíjecího okna baterie — může dojít k závodním podmínkám (race conditions). Jedna automatizace nastaví SOC na 80 %, druhá ho vzápětí přepíše na 60 %. Výsledek? Nečekané chování, které se špatně debuguje.

Řešení je kompozitní automatizace — sloučíš všechny triggery do jedné automatizace s větvenou logikou choose. Tady je reálný příklad pro Alpha ESS baterii:

automation:
  - alias: "Alpha ESS - Kompozitní řízení nabíjení"
    trigger:
      - trigger: state
        entity_id: input_boolean.dispatched_off_peak_electricity
        to: "on"
        id: off_peak_on
      - trigger: state
        entity_id: input_boolean.dispatched_off_peak_electricity
        to: "off"
        id: off_peak_off
      - trigger: state
        entity_id: input_number.alpha_ess_target_soc
        to: null
        id: update_soc
    actions:
      - choose:
          - conditions:
              - condition: trigger
                id: off_peak_on
            sequence:
              - action: alphaess.setbatterycharge
                data:
                  cp2start: "05:30"
                  cp2end: "23:30"
                  chargestopsoc: "{{ states('input_number.alpha_ess_target_soc') }}"
          - conditions:
              - condition: trigger
                id: off_peak_off
            sequence:
              - action: alphaess.setbatterycharge
                data:
                  enabled: true
                  cp2start: "00:00"
                  cp2end: "00:00"
                  chargestopsoc: "{{ states('input_number.alpha_ess_target_soc') }}"
          - conditions:
              - condition: trigger
                id: update_soc
            sequence:
              - if:
                  - condition: state
                    entity_id: input_boolean.dispatched_off_peak_electricity
                    state: "on"
                then:
                  - action: alphaess.setbatterycharge
                    data:
                      cp2start: "05:30"
                      cp2end: "23:30"
                      chargestopsoc: "{{ states('input_number.alpha_ess_target_soc') }}"
                else:
                  - action: alphaess.setbatterycharge
                    data:
                      enabled: true
                      cp2start: "00:00"
                      cp2end: "00:00"
                      chargestopsoc: "{{ states('input_number.alpha_ess_target_soc') }}"

Všimni si: cílový SOC není pevně daný. Je to input_number helper, jehož hodnotu mění jiná automatizace — například na základě solární předpovědi ze Solcastu na příští den. Takhle si oddělíš logiku výpočtu od logiky ovládání baterie.

Adaptivní nabíjení: solární předpověď jako mozek celého systému

Statické časové okno „nabíjej od 2:00 do 6:00" funguje, ale je to hrubé řešení. V létě při jasné obloze baterii dobije samo slunce do deseti dopoledne. V zimě možná sluneční předpověď ukáže, že zítra bude zataženo, a dává smysl nabít baterii v levném nočním tarifu na maximum.

Tohle řeší adaptivní přístup — každou hodinu přepočítáváš cílový nabíjecí proud a cílový SOC podle aktuální předpovědi. Solcast API (zdarma pro dvě střechy) ti dá hodinové předpovědi výroby. Šablona pak spočítá, kolik energie ještě do baterie nalít:

# Příklad výpočtu max. nabíjecího proudu (zjednodušeno)
{% set allocation = states('sensor.solcast_forecast_remaining_today') | float %}
{% set time_fraction = (states('sensor.hours_until_sunset') | float) %}
{% set battery_voltage = 48.0 %}
{% set min_charge_current = 5 %}
{% set max_charge_current = states('sensor.abc_max_chg_rate') | float %}
{% set charge_current_raw = (allocation * 1000 / time_fraction / battery_voltage) | round(0) %}
{% set charge_current = [[charge_current_raw, min_charge_current] | max, max_charge_current] | min %}
{{ charge_current }}

Šablona vezme předpovídanou zbývající výrobu dne, vydělí ji počtem hodin do západu slunce a napětím baterie — a dostaneš ideální nabíjecí proud v ampérech. Výsledek pak předáš jako příkaz inverteru. V praxi to znamená, že v létě nabíjíš pomalu a solárka pokryje zbytek sama, zatímco v zimě jdeš na plný nabíjecí výkon ze sítě v levném tarifu.

Parametr	Entita	Typ
Zbývající solární výroba dnes	sensor.solcast_forecast_remaining_today	Sensor (Solcast)
Hodiny do západu	sensor.hours_until_sunset	Template sensor
Max. nabíjecí proud inverteru	sensor.abc_max_chg_rate	Sensor (inverter)
Cílový SOC	input_number.alpha_ess_target_soc	Input number helper
Stav levného tarifu	input_boolean.dispatched_off_peak_electricity	Input boolean helper

Závěr: základ máš, teď přidávej vrstvy

Tahle architektura — kompozitní automatizace + adaptivní výpočet na základě předpovědi — je solidní základ, na kterém se dá stavět dál. Podle reálných zkušeností dokáže koordinované řízení baterie zlepšit finanční návratnost solárního systému o 20–40 % oproti pasivnímu provozu bez automatizace.

Jako další krok mě láká dynamické přepočítávání cílového SOC během dne — třeba každé dvě hodiny — na základě aktuálního stavu baterie a zbývající části denní předpovědi. V létě pak může baterie začít vybíjet dřív, pokud je na sto procentech a slunce stále svítí naplno.

Máš doma jiný typ baterie nebo inverteru? Napiš do komentářů — rád pomůžu s konkrétním YAML nebo Modbus konfigurací.