Demand response v Home Assistantu: buď součástí chytré sítě

Hele, přiznám se – ještě před pár lety jsem na slova "demand response" a "grid flexibility" reagoval otočením očí. Znělo to jako marketingový blábol velkých energetických korporací. Ale pak jsem začal kopat hlouběji a zjistil jsem, že tahle věc je vlastně perfektně kompatibilní s tím, co my kutilové děláme dlouho – jen jsme tomu říkali jinak. Říkali jsme tomu "automatizace podle ceny elektřiny". A teď se ukazuje, že přesně tohle distributori a operátoři sítě zoufale potřebují.

Co je demand response a proč by tě to mělo zajímat

Demand response (DR) je v principu jednoduchá věc: distributor nebo agregátor ti pošle signál "hele, teď je síť přetížená, můžeš na hodinku snížit spotřebu?", a ty za to dostaneš finanční kompenzaci nebo slevu na elektřině. V průmyslu tohle funguje desítky let – velké továrny za to berou slušné peníze. Teď se to konečně posouvá i do domácností.

Proč teď? Protože obnovitelné zdroje mají povahu, která s distribucí trochu zamává – fotovoltaika zuří v poledne a vítr fouká kdy chce, ne kdy potřebuješ. Výsledkem jsou prudké výkyvy na síti, které se řeší buď drahými záložními plynovými elektrárnami, nebo právě flexibilitou na straně spotřeby. Podle dat Precedence Research je segment "smart grid a demand response integrace" nejrychleji rostoucím segmentem celého trhu chytrých termostatů a mezi roky 2026 a 2035 poroste nejvýrazněji ze všech kategorií.

A tady přichází ta sladká část pro nás – uživatele Home Assistantu. My máme lokální logiku, plnou kontrolu nad tím, co se smí a co nesmí změnit, a hlavně: nikomu nedáváme přímý přístup k našim zařízením. Přesně tohle popisoval i zástupce energetické společnosti ve vlákně na Home Assistant komunitním fóru, kde navrhoval integraci DR do HA. Cituju: "Z našeho pohledu chceme být co nejneviditelnější – pokud uživatele negativně ovlivníme, prostě přepíše změnu ručně a celý účel je ztracen." Tohle mě upřímně potěšilo. Konečně někdo z utility světa mluví naším jazykem.

Jak to celé zapojit do Home Assistantu – bez cloudu a bez odevzdání klíčů

Základní princip je elegantní: Home Assistant přijme DR signál (webhook, MQTT zpráva, nebo v budoucnu standardizované API), vyhodnotí ho podle tvých pravidel a podle nastavených "guardrails" – minimální a maximální teploty, na které nesmí sáhnout – a teprve pak upraví chování termostatu nebo jiných zátěží.

Pojďme si to rozbastlit krok za krokem.

1. Přijímání DR signálu

Nejjednodušší varianta dnes: webhook trigger v HA automatizaci. Agregátor nebo distributor pošle HTTP POST na tvůj HA endpoint s payloadem obsahujícím dobu trvání a požadované snížení. Domácí instance HA to zpracuje lokálně, ven neodesílá nic.

trigger:
  - platform: webhook
    webhook_id: "demand_response_event"
    allowed_methods:
      - POST
    local_only: false  # pokud agregátor volá zvenčí

action:
  - variables:
      dr_duration: "{{ trigger.json.duration_minutes | int(60) }}"
      dr_reduction_kw: "{{ trigger.json.requested_reduction_kw | float(1.0) }}"
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.demand_response_active
  - delay:
      minutes: "{{ dr_duration }}"
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.demand_response_active

2. Guardrails – tvoje červené čáry

Toto je klíčové. Nikdy nechceš, aby DR event přepsal teplotu pod nebo nad tvoji komfortní hranici. Definuješ si input_number entity jako mantinely:

Entita	Výchozí hodnota	Popis
input_number.dr_min_temp	19 °C	Minimum při DR eventu (vytápění)
input_number.dr_max_temp	22 °C	Maximum při DR eventu (chlazení)
input_number.dr_normal_temp	21 °C	Normální žádaná teplota
input_boolean.demand_response_active	off	Příznak aktivního DR eventu

Samotná automatizace termostatu pak vypadá takto:

trigger:
  - platform: state
    entity_id: input_boolean.demand_response_active

action:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_boolean.demand_response_active
            state: "on"
        sequence:
          - service: climate.set_temperature
            target:
              entity_id: climate.obyvak
            data:
              temperature: >
                {{ [states('input_number.dr_min_temp') | float,
                   (states('input_number.dr_normal_temp') | float) - 1.5]
                   | max }}
      - conditions:
          - condition: state
            entity_id: input_boolean.demand_response_active
            state: "off"
        sequence:
          - service: climate.set_temperature
            target:
              entity_id: climate.obyvak
            data:
              temperature: "{{ states('input_number.dr_normal_temp') | float }}"

Snížíš teplotu o 1,5 °C, ale nikdy ne pod své minimum. Tohle je přesně ten "invisible" přístup, co distributor chce – komfort moc neutrpí, ale síť pocítí úlevu.

3. Tepelná setrvačnost jako superschopnost

Tady přichází fyzika, která hraje pro nás. Správně izolovaný dům je obrovský tepelný zásobník. Pokud víš, že DR event přijde v 17:00, můžeš dům předehřát na 22 °C do 16:45 a pak na hodinu vytápění kompletně vypnout – a teplota klesne třeba jen o 0,8 °C. Tohle je princip, který ENEPAQ popisuje u svého Smart AI Thermostatu – budovy jako "thermal energy buffers". Jenže my si to uděláme sami, lokálně, zadarmo.

Pre-heating automatizaci nasadíš přes calendar trigger nebo podmíněně na základě tarifu (Nordpool integrace ti dá cenový výhled), čímž kombinuješ DR s time-of-use optimalizací v jednom.

Reálné výsledky a kde je tahle věc teď

Podle případové studie z energy-solutions.co přineslo AI řízení termostatu s DR signály a TOU tarifem 18% úsporu na části účtu za HVAC a 30–40% pokles špičkového příkonu během DR eventů. To jsou čísla, která se počítají. Americký pilotní projekt zahrnující 500 domácností s AI demand shapingem snížil špičkové zatížení sítě o 14 %, uvádí Congruence Market Insights.

Co se týče standardizace – na fóru HA komunity zazněl zajímavý návrh na formalizovanou DR integraci přímo v platformě. Zatím nic merged, ale diskuze nabrala momentum. V tuhle chvíli je webhook přístup, který jsem popsal výše, nejrobustnější DIY řešení bez závislosti na externím cloudu.

Největší výzva? Najít agregátora nebo distributora, který tohle v Česku reálně nabízí domácnostem. ČEZ a E.ON mají pilotní programy flexibility, ale zatím hlavně pro větší odběratele. Nicméně – infrastruktura na HA straně je hotová, guardrails máš nastavené, čekáš jen na ten webhook. A to je přesně ta pozice, ve které chceš být, až to distributor konečně spustí naplno.

Otázka na závěr: dal bys agregátorovi přístup k webhook endpointu své HA instance výměnou za finanční kompenzaci, nebo raději zůstaneš plně autonomní a DR eventy budeš sledovat manuálně? Rád si přečtu váš pohled v komentářích.