Monitoring zasilania awaryjnego: Modbus, Home Assistant i niezależne zabezpieczenia

Lokalny monitoring Modbus udostępnia dane falownika bez chmury producenta, o ile falownik, bramka, sieć i Home Assistant nadal mają zasilanie. Możliwe jest wtedy obserwowanie stanu sieci, naładowania baterii i ograniczeń mocy. Home Assistant nie zastępuje gwarantowanego przełączenia zasilania awaryjnego ani elektrycznej ochrony przed przeciążeniem.

Potrzebny jest podział dwóch zadań. Fachowo zaprojektowana instalacja realizuje odłączenie od sieci, zasilanie rezerwowe i wymagany zrzut obciążenia niezależnie od serwera automatyki. Home Assistant dodaje wizualizację, historię i powiadomienia. Komunikacja lokalna zmniejsza zależność od usług zewnętrznych, ale nie gwarantuje reakcji w czasie rzeczywistym.

1. Najpierw tor zasilania awaryjnego

Nie każdy falownik PV potrafi utworzyć sieć wyspową po zaniku zasilania. Potrzebna jest obsługiwana funkcja rezerwowa, odpowiednia bateria lub dostępna generacja oraz układ przełączania przewidziany przez producenta. Moc ciągła, krótkotrwała przeciążalność, prądy rozruchowe, podział faz i ograniczenia baterii określają dopuszczalne odbiorniki. Sam poziom naładowania nie opisuje tych granic.

Projektowanie i uruchamianie rozdzielnicy wymaga wykwalifikowanego elektryka. Styczniki przełączają obciążenia, a RCBO chronią przed określonymi prądami różnicowymi i przetężeniami. Takie elementy nie tworzą automatycznie odseparowania od sieci ani bezpiecznej logiki awaryjnej. Dobór, okablowanie i zachowanie przy uszkodzeniu muszą odpowiadać instalacji. Pompa ciepła nie zawsze jest odbiornikiem niekrytycznym: ochrona przed zamarzaniem, sterowanie i wymagania producenta mogą zmieniać priorytety.

Jedna z możliwych architektur zasila z toru rezerwowego wyłącznie wcześniej wybrane obwody. Inne instalacje wymagają zarządzania obciążeniem zapewnianego przez producenta lub odpowiednio zaprojektowanego niezależnego sterownika. Konieczne jest ustalenie i sprawdzenie, które odbiorniki odłączają się po zaniku napięcia sterowania oraz kiedy dozwolone jest ponowne załączenie. Pojedynczy przekaźnik lub polecenie przełączania z Home Assistant nie potwierdza tych właściwości.

2. Transport Modbus a mapa rejestrów

Modbus RTU zwykle korzysta z szeregowego połączenia RS485. Modbus TCP używa innego formatu komunikatu przez TCP. Bramka tłumacząca może udostępniać Modbus TCP, natomiast przezroczysty serwer portu szeregowego przenosi niezmienione komunikaty RTU przez TCP. W Home Assistant odpowiadają temu type: tcp i type: rtuovertcp. Samo złącze Ethernet nie rozstrzyga wyboru.

Adresy rejestrów i kody stanów zależą od urządzenia oraz firmware. Stan sieci nie znajduje się uniwersalnie pod adresem 33000, a naładowanie baterii pod 37000. Home Assistant używa adresów liczonych od zera. Oznaczenie 40001 w instrukcji może oznaczać pierwszy rejestr holding pod adresem 0; przeliczenie musi wynikać z dokumentacji mapy.

Interwały odpytywania określają żądany rytm aktualizacji. Odpowiedź urządzenia, transmisja szeregowa, inne zapytania, przekroczenia czasu i ponowienia wydłużają rzeczywiste wykrycie. Nawet interwał dwóch sekund nie gwarantuje reakcji w ciągu dwóch sekund. Niezmienione lub odtworzone wartości mogą być nieaktualne; wiarygodna kontrola aktualności wymaga na przykład udokumentowanego sygnału heartbeat urządzenia lub znacznika udanego odczytu.

3. YAML tylko do odczytu z jawnymi założeniami

Poniższy szablon jest celowo niekompletny. Wpisy !secret wymagają uzupełnienia ze sprawdzonej mapy urządzenia; adresy są w ten sposób centralnie skonfigurowane, a nie poufne. Szablon pasuje wyłącznie do urządzenia z 16-bitowym rejestrem input stanu sieci i 16-bitowym rejestrem holding naładowania w całych procentach. Inne typy rejestrów, kolejność słów, skalowanie lub kody błędów wymagają zmian. Gotowa obsługiwana integracja urządzenia może uprościć ręczne mapowanie.

# configuration.yaml: incomplete until documented addresses are supplied
modbus:
  - name: inverter_local
    type: tcp
    host: !secret inverter_host
    port: 502
    sensors:
      - name: Grid Status Raw
        unique_id: inverter_grid_status_raw
        device_address: !secret inverter_unit_id
        address: !secret inverter_grid_status_address
        input_type: input
        data_type: uint16
        scan_interval: 5
      - name: Battery SoC
        unique_id: inverter_battery_soc
        device_address: !secret inverter_unit_id
        address: !secret inverter_soc_address
        input_type: holding
        data_type: uint16
        unit_of_measurement: "%"
        scan_interval: 30

Interwały pięciu i trzydziestu sekund są jedynie punktem wyjścia dla monitoringu i muszą odpowiadać zaleceniom producenta oraz obciążeniu magistrali. Oba sensory tylko odczytują; odczyt rejestru holding nie zapisuje wartości. Rzeczywista nazwa encji może różnić się od oczekiwanej sensor.grid_status_raw i wymaga sprawdzenia przed użyciem automatyzacji.

4. Zgłoszenie stanu bez deklarowania odłączenia

Przykład wymaga wcześniej potwierdzonej interpretacji kodów urządzenia: 0 oznacza brak sieci, 1 oznacza obecność sieci. Inne kody, unknown i unavailable oznaczają tutaj stan niejasny. Automatyzacja stanowi pojedynczy wpis w trybie YAML edytora automatyzacji. Lista w automations.yaml wymaga dodatkowo odpowiedniego wcięcia elementu listy.

# Jedna automatyzacja w trybie YAML edytora automatyzacji
alias: Stan telemetrii zasilania rezerwowego
triggers:
  - trigger: state
    entity_id: sensor.grid_status_raw
  - trigger: homeassistant
    event: start
  - trigger: time_pattern
    seconds: "/30"
actions:
  - action: persistent_notification.create
    data:
      notification_id: backup_telemetry_status
      title: Telemetria zasilania rezerwowego
      message: >-
        {% set raw = states('sensor.grid_status_raw') %}
        {% if raw in ['0', '0.0'] %}
          Zgłoszony brak sieci. Wymagana kontrola zasilania rezerwowego i obciążenia.
        {% elif raw in ['1', '1.0'] %}
          Zgłoszona obecność sieci. To nie potwierdza dostępności zabezpieczeń.
        {% else %}
          Stan sieci nieznany lub nieprawidłowy: {{ raw }}. Brak potwierdzenia zaniku sieci.
        {% endif %}
mode: restart

Zmiany stanu, start Home Assistant i cykl trzydziestu sekund aktualizują to samo lokalne powiadomienie. Wskazanie nie zależy więc wyłącznie od jednorazowego przekroczenia progu liczbowego. Stale wiarygodna, lecz zamrożona wartość sensora nadal nie zostanie wykryta. Komunikat nie potwierdza pracy wyspowej ani fizycznego położenia stycznika.

Dodatkowy zrzut obciążenia dla wygody wymaga osobnego projektu dopasowanego do instalacji: dopuszczonego interfejsu lokalnego, jednoznacznej polaryzacji przełączania, informacji zwrotnej o rzeczywistym położeniu styków i uzgodnionych warunków ponownego startu. Podstawowa funkcja elektryczna musi pozostawać niezależna od tego dodatku podczas awarii Home Assistant, bramki lub sieci.

5. Celowe sprawdzanie awarii

• W kontrolowanych testach porównać udokumentowane kody i pomiary z wyświetlaczem urządzenia, uwzględniając wartości błędne oraz utratę komunikacji.
• Sprawdzić restart Home Assistant i przeładowanie automatyzacji. Wskazanie stanu musi ponownie oceniać istniejące wartości; funkcja elektryczna pozostaje niezależna.
• Zweryfikować zasilanie Pi, sieci i bramki w przewidywanym trybie pracy. Bramka odłączana wraz z siecią nie dostarczy telemetrii podczas awarii.
• Testy elektrycznego przełączania i obciążenia wykonuje właściwy specjalista według procedury producenta. Testy oprogramowania nie zastępują uruchomienia instalacji.
• Ograniczyć dostęp Modbus do wymaganego segmentu lokalnego. Klasyczny Modbus TCP nie zapewnia automatycznie szyfrowania ani uwierzytelniania; Modbus Security jest osobnym rozszerzeniem wymagającym obsługi po obu stronach.