Home Assistant i fotowoltaika: automatyka domowa okiem sysadmina

Ten wpis jest bardziej osobisty niż zwykle — nie ma tu klienta ani zespołu, jest własny dach, własny inwerter i własna ciekawość, co da się zautomatyzować, kiedy dane o produkcji energii są dostępne w czasie rzeczywistym. Ale mimo hobbystycznego charakteru, instalacja PV w domu nauczyła mnie o monitoringu więcej niż niejeden produkcyjny incydent w pracy — bo tu obserwowałem system przez rok, w każdych warunkach pogodowych, z konsekwencjami wprost przekładającymi się na rachunek za prąd.

Punkt wyjścia — integracja inwertera i liczników

Instalacja PV sama w sobie ma własną aplikację producenta, ale te aplikacje z reguły są zamknięte, pokazują dane z opóźnieniem i nie dają żadnej możliwości automatyzacji poza tym, co producent z góry przewidział. Home Assistant zmienia to całkowicie — inwerter (u mnie z lokalnym API po Modbus TCP w sieci LAN, bez zależności od chmury producenta) i licznik energii (dwukierunkowy, żeby widzieć osobno pobór i oddanie do sieci) trafiają do jednej, spójnej bazy danych czasowych, dostępnej do dowolnej automatyzacji.

# configuration.yaml — fragment integracji przez Modbus
modbus:
  - name: inwerter_pv
    type: tcp
    host: 192.168.10.50
    port: 502
    sensors:
      - name: "Moc produkcji PV"
        address: 40100
        input_type: holding
        unit_of_measurement: W
        scale: 1
        data_type: uint32

Zanim automatyzacja miała jakikolwiek sens, kilka tygodni po prostu patrzyłem na wykresy — profil produkcji w słoneczny dzień kontra pochmurny, jak szybko chmura potrafi zrzucić moc produkcji o 80% w ciągu kilku sekund, jak wygląda krzywa poboru domu bez żadnej ingerencji. To był dokładnie ten sam odruch, co przy wdrażaniu nowego systemu w pracy — najpierw obserwacja baseline, dopiero potem reguły alertujące czy automatyzacje na tej podstawie.

Automatyzacje sterowane nadwyżką produkcji

Sedno automatyki PV to jedna zasada: energia wyprodukowana i zużyta na miejscu jest tańsza niż energia oddana do sieci i odkupiona z powrotem wieczorem (przy aktualnym rozliczeniu net-billing w Polsce różnica jest odczuwalna). Stąd automatyzacje, które przesuwają zużycie energii w stronę godzin nadwyżki produkcji:

automation:
  - alias: "Bojler: załącz grzanie przy nadwyżce PV"
    trigger:
      - platform: numeric_state
        entity_id: sensor.nadwyzka_pv
        above: 2000
        for:
          minutes: 5
    condition:
      - condition: numeric_state
        entity_id: sensor.temperatura_bojlera
        below: 55
    action:
      - service: switch.turn_on
        target:
          entity_id: switch.grzalka_bojler

Warunek for: minutes: 5 na wejściu trigger jest tu celowy — bez niego przelotna chmura na 20 sekund załączałaby i wyłączała grzałkę w kółko, co ani nie oszczędza energii, ani nie wydłuża żywotności przekaźnika. Dokładnie ten sam mechanizm, którego uczy się przy strojeniu reguł w SIEM — próg i okno czasowe chronią przed reagowaniem na szum, nie na sygnał. Podobne automatyzacje działają u mnie dla ładowania samochodu (throttling mocy ładowania proporcjonalnie do nadwyżki, nie prosty on/off) i pralki uruchamianej automatycznie w oknie najwyższej produkcji w ciągu dnia.

Dashboard i to, czego nauczyłem się o observability

Home Assistant z dodatkiem InfluxDB + Grafana dał mi dokładnie ten sam stack, którego używam do monitoringu infrastruktury w pracy — tylko że metryki to nie CPU i pamięć, tylko wolty, waty i procent naładowania. I paradoksalnie to własny dom nauczył mnie kilku rzeczy o dobrym monitoringu wyraźniej niż praca zawodowa:

• Retencja danych ma znaczenie od pierwszego dnia — domyślna retencja InfluxDB w Home Assistant była zbyt krótka, żeby porównać produkcję rok do roku. Zmiana retencji po utracie danych z pierwszych miesięcy była lekcją, którą łatwiej było zignorować w pracy (bo tam ktoś inny to skonfigurował dawno temu), a we własnym projekcie zapłaciłem za nią osobiście.
• Alert bez kontekstu jest bezużyteczny — pierwsza wersja alertu „produkcja PV = 0” budziła mnie fałszywie każdej nocy, bo w nocy produkcja rzeczywiście wynosi zero. Dopiero warunek ograniczający alert do godzin dziennych i porównanie z oczekiwaną krzywą dla danej pory roku (nie z sztywną wartością) zrobiło z tego użyteczny sygnał zamiast szumu.
• Dashboard, na który nikt nie patrzy, jest bezwartościowy — dokładnie ta sama lekcja co z SIEM-em. Wykres, który ogląda się raz i zapomina, nie różni się niczym od braku wykresu. Dopiero jeden ekran z najważniejszymi liczbami (produkcja dziś, autokonsumpcja, saldo z siecią) wyświetlany stale na tablecie w kuchni sprawił, że dane faktycznie wpływają na decyzje — np. świadome przesunięcie prania na południe zamiast wieczora.

Różnica między monitoringiem produkcyjnym a hobbystycznym jest mniejsza, niż się wydaje — te same zasady (baseline przed alertem, histereza zamiast sztywnego progu, kontekst zamiast gołej wartości) sprawdzają się identycznie, niezależnie od tego, czy monitorujesz klaster serwerów, czy własny bojler.

Co dalej

Kolejny krok, który dopiero testuję, to integracja prognozy pogody z planowaniem automatyzacji z wyprzedzeniem — jeśli jutro zapowiadane jest pełne słońce, bojler może poczekać z grzaniem nocnym do rana, ufając nadwyżce z PV zamiast taryfy nocnej. To zbliża się coraz bardziej do tego, co w pracy nazwalibyśmy predykcyjnym skalowaniem zasobów na podstawie prognozowanego obciążenia — tylko że tu zasobem jest energia słoneczna, a obciążeniem pralka i bojler.