Bezpieczeństwo instalacji PV z magazynem: co widać w sieci LAN

Sześć usług, które nie pytają, kim jesteś

W tej instalacji sześć usług odpowiada w sieci lokalnej każdemu, kto zapyta — bez hasła i bez sprawdzania, kto się zgłasza. Dwie kolejne, SSH i SNMP, są zamknięte. To nie jest lista przepisana z poradnika. To zestawienie zrobione na działającym systemie: tym samym, który opisuje reszta serii. Venus OS v3.79 na Cerbo GX, trójfazowy ESS, licznik Carlo Gavazzi EM24 na przyłączu, falownik Fronius Symo 3.7-3-S. Patrzyliśmy od 30.08.2026 22:07 do 05.09.2026 23:41. Jedno zastrzeżenie trzyma cały ten artykuł: to są ustawienia domyślne producentów, a nie czyjeś zaniedbanie.

Kreska w kolumnie z portem znaczy tylko tyle, że numeru nie ma w naszym pomiarze — nie zgadujemy go. Usługi zamknięte trafiły do tabeli celowo: zestawienie, które pokazuje wyłącznie to, co otwarte, kłamie przez pominięcie.

Tę tabelę trzeba czytać jako całość. Nie ma tu jednego zamka, który ktoś zapomniał zamknąć. Jest coś innego: pytanie „kto pyta?” w ogóle nie pada. Te urządzenia powstały do sieci, w której o uprawnieniach rozstrzygał dostęp do kabla.

Dlaczego nikt tu niczego nie zaniedbał

Modbus — język, którym te urządzenia rozmawiają ze sobą po kablu — nie sprawdza, kto się do niego odzywa. Nie dlatego, że ktoś to wyłączył. W wiadomości, którą jedno urządzenie wysyła do drugiego, nie ma na to miejsca. Jest w niej adres urządzenia, kod funkcji (czyli o co pytamy), adres rejestru — numer komórki, w której siedzi wartość — i same dane. Nic więcej.

Wzięło się to stąd, że Modbus powstał do sieci przemysłowej. Do szafy sterowniczej, w której granicą był kabel, a nie hasło: kto miał dostęp do kabla, ten miał prawo pytać. Innego zabezpieczenia nikt wtedy nie potrzebował — i to założenie zostało w tych urządzeniach do dziś.

Konsekwencję trzeba wypowiedzieć wprost: do Modbusa nie da się „dodać hasła”, bo nie ma czego dodać. Możesz postawić coś przed nim — wydzielić osobną sieć, wstawić bramkę, dopisać regułę na ruterze. Sam Modbus nigdy nie zapyta. Wszystko, co nazywa się „zabezpieczeniem Modbusa”, ogranicza to, kto w ogóle może się do niego odezwać.

Najostrzej widać to na liczniku. EM24 czytamy wprost, bez pośrednictwa Cerbo — to nasze trzecie i niezależne źródło danych. Wygląda to tak: tcp/502, unit ID 1, funkcje 3 i 4 (obie działają). Nikt nas przy tym o nic nie pyta. Poza portem 502 licznik nie odpowiada na nic: nie ma strony w przeglądarce, nie ma SNMP, nie ma SSH. To sprzęt zbudowany pod jedno założenie: granicą jest kabel.

Ta sama otwartość, dzięki której w ogóle wiemy, co się dzieje

Uczciwość wymaga drugiej połowy. Odczyt licznika wprost daje więcej niż odczyt przez Victrona: moc bierną i pozorną osobno dla każdej fazy, cosφ, napięcia międzyfazowe, kolejność faz. Falownik oddaje przez Solar API — swoją stronę z danymi, w formacie JSON i bez pytania o hasło — wartości bieżące oraz archiwum 5-minutowe. To 288 próbek na dobę, potwierdzone wstecz do 01.09.2025. Ta sama otwartość jest warunkiem niezależnego pomiaru. Dlatego odpowiedź „zamknąć wszystko” jest tak samo bezmyślna jak „zostawić, jak jest”.

Otwartość, która nic nie może zmienić

Nie każde otwarte drzwi są tym samym rodzajem drzwi. Solar API tylko oddaje dane — nic się przez nie nie ustawia. Falownik pracuje w trybie produce-only: nie ma po swojej stronie ani Smart Metera, ani baterii, więc P_Grid i P_Load są null, czyli puste. Najwięcej, czego ktoś obcy się stąd dowie, to ile instalacja wyprodukowała. Modbus na Cerbo to zupełnie inna kategoria. Tu też nikt nie pyta o hasło, ale funkcje zapisu (6 i 16) sięgają setpointów sieci i przekaźników. Podejrzenie cudzej produkcji i przestawienie pracy instalacji nie są pozycjami tej samej listy — i dalsza część artykułu jest o tej różnicy.

To samo ustawienie: u nas do przyjęcia, u klienta nie

Tabela z pierwszego rozdziału opisuje sieć pokazową: naszą instalację, nasze dane, naszą sieć. W tej roli jest to ryzyko do przyjęcia i przyjmujemy je świadomie. Ta sama konfiguracja w budynku klienta przestaje być do przyjęcia. W oprogramowaniu nie zmienia się przy tym ani jedno ustawienie. Zmienia się to, kto jeszcze ma dostęp do tej sieci i czyje to są dane.

1. Czyje to są dane

Tunel VRM two-way jest włączony, więc dane instalacji idą do chmury producenta. U nas jest to decyzja o własnym profilu zużycia: właściciel uznał, że swoich danych o energii nie ukrywa. U klienta to samo ustawienie znaczy co innego. Dane budynku wychodzą spod jego kontroli, a razem z nimi otwiera się kanał, który już w nazwie jest dwustronny. Jest to przy tym połączenie wychodzące: zapora, która blokuje ruch przychodzący, nie dotyka go w żaden sposób. To nie jest argument przeciw chmurze producenta. To argument za tym, żeby właściciel tę decyzję podjął, zamiast zastać ją włączoną.

2. Jak daleko sięga skutek

Zapisywalny Modbus to nie jest „ktoś zobaczy, ile produkujesz”. To zmiana pracy instalacji: setpointy sieci, przekaźniki. W naszej sieci pokazowej najgorszy scenariusz kończy się na naszym rachunku za prąd i naszej nocy nad wykresem. W budynku klienta ten sam scenariusz dotyczy cudzej instalacji, cudzych umów i cudzego bezpieczeństwa pracy. O tym, czy ryzyko wolno przyjąć, decyduje waga skutku, a nie samo prawdopodobieństwo.

Wniosek jest niewygodny, bo nie wskazuje winnego. Producent nie popełnił błędu: Venus OS jest w obu przypadkach ten sam, w tej samej wersji, z tymi samymi ustawieniami domyślnymi. Różnica jest wyłącznie w tym, kto ma dostęp do tej sieci i czyje to są dane. A tego nie da się przeklikać w urządzeniu — to trzeba zaprojektować w sieci.

Sam pomiar bywa ryzykiem

Najciekawszej rzeczy, jaką tu zmierzyliśmy, nie ma w tabeli otwartych usług. Jest nią to, że sam odczyt potrafi zabrać magazynowi energii licznik sieci. Bez jednego zapisu, bez jednej zmienionej nastawy.

Licznik rozmawia naraz tylko z kilkoma, a jedno miejsce zajmuje sterowanie magazynem

EM24 oddaje dane przez Modbus TCP, ale obsługuje naraz tylko kilka rozmów. Każda taka rozmowa to jedno otwarte połączenie; w Modbusie nazywa się je sesją. Jedno z tych połączeń trzyma Cerbo — i na tym odczycie opiera pracę magazynu. Sterowanie musi wiedzieć, co dzieje się na przyłączu; innego zmysłu nie ma.

Teraz wyobraź sobie zwyczajny, staranny monitoring. Osobne połączenie na każdą grupę odczytów. Kilka pytań naraz, żeby wszystkie wartości pochodziły z tej samej chwili. Połączenie trzymane otwarte między cyklami, żeby nie tracić czasu na łączenie od nowa. Po błędzie natychmiastowa kolejna próba. W zwykłym systemie informatycznym każdy z tych nawyków to dobra praktyka. Tutaj każdy zajmuje jedno z niewielu miejsc przy liczniku — i tyle wystarczy, żeby wypchnąć stamtąd to należące do Victrona.

Skutek nie wygląda na awarię monitoringu. Wygląda na awarię instalacji: magazyn traci licznik sieci, a ESS reguluje, nie wiedząc, co dzieje się na przyłączu. Narzędzie, które miało wyłącznie patrzeć, staje się przyczyną zdarzenia, które opisuje.

Nie badaj tego na żywej instalacji

Wiemy, że licznik przyjmuje co najmniej dwa połączenia naraz, bo tyle sami utrzymujemy: jedno Cerbo, drugie nasz odczyt. Ile ich wytrzyma maksymalnie — nie sprawdzamy i nie zamierzamy. Próba, która by to ustaliła, jest dokładnie tą próbą, która zabiera magazynowi licznik. To luka w naszej wiedzy wpisana w projekt, a nie przeoczenie.

Stąd zasada dla każdego, kto zbiera dane z takiego licznika — my trzymamy się jej tak samo:

• Jedno krótkie połączenie na cykl. Otwórz, przeczytaj komplet, zamknij. Połączenie trzymane otwarte „dla wydajności” jest połączeniem odebranym komuś, kto potrzebuje go bardziej.
• Nie pytaj o kilka rzeczy naraz. Grupy rejestrów czytaj po kolei, w tym jednym połączeniu. Zyskujesz na tym ułamek sekundy, o który próbka jest bardziej spójna. Płacisz ryzykiem dla sterowania.
• Błąd znaczy „poczekaj do następnego cyklu”, a nie „połącz się jeszcze raz”. Lawina ponowień dobija urządzenie, które i tak już czegoś nie wyrabia.

Ta dyscyplina ma drugi, niezależny powód — siedzi on w samym Modbusie. Licznik przyjmuje maksymalnie 64 rejestry na jedno pytanie, a przy 100 odpowiada wyjątkiem 0x02 — illegal data address. „Przeczytam wszystko jednym strzałem” i tak nie jest opcją. Ta sama praca, którą wykonujesz, żeby zmieścić się w tym limicie, mieści Cię w rozsądnej liczbie połączeń.

Drugi rodzaj ryzyka: pomiar, który wymyśla awarię

W liczniku EM24 pod adresem 0x000B (11) siedzi kod identyfikacyjny 1648 — tym numerem urządzenie przedstawia się jako EM24. Ale tylko wtedy, gdy pytasz o ten jeden rejestr osobno. W każdym dłuższym pytaniu pod tym samym adresem jest już co innego. Jeżeli 1648 wpadnie do tabeli pomiarów jako zwykła wartość, napięcie międzyfazowe L3–L1 podnosi się z około 420 V do ponad 10 MV.

To nie jest błąd, który wygląda na błąd odczytu. To błąd, który wygląda na awarię instalacji. Podpięty pod alarmowanie wyśle kogoś w nocy do instalacji, z którą wszystko jest w porządku. Przy okazji nauczy go, że alarmy z tego systemu to szum. Rozwiązanie musi być świadome: o ten rejestr pytaj osobno, zapytaniem o długości 1, a kodu identyfikacyjnego nie wpuszczaj do tabeli pomiarów.

Trzeci rodzaj: odpowiedź, która wygląda na poprawną

Lokalne archiwum Froniusa oddaje najwyżej 16 dni na jedno zapytanie. Jeśli poprosisz o dłuższy zakres, falownik nie zgłosi ani wyjątku, ani błędu HTTP. Zwróci Status.Code=255 w sekcji Head, z komunikatem Query interval is restricted to 16 days, więc odpowiedź wygląda na poprawną — po prostu nie ma w niej danych. Program, który sprawdza wyłącznie „czy odpowiedziało”, zapisze w historii dziurę, której nigdy nie było. Miesiąc trzeba pobierać w dwóch kawałkach.

Wszystkie cztery pułapki w tym rozdziale są ryzykiem narzędzia pomiarowego, a nie instalacji. Dlatego monitoring traktujemy jak część instalacji, a nie jak obserwatora stojącego obok. Obserwator, który zajmuje jedno z połączeń, jest uczestnikiem.

Nasz monitoring tylko czyta, a zapis idzie jedną drogą

Zasada, której się trzymamy, brzmi tak: monitoring wyłącznie czyta, a nasz kod nigdy nie pisze po Modbus. Jedyny zapis, jaki wykonujemy, idzie przez jeden autoryzowany flow w Node-RED. To nie jest ostrożnościowy zwyczaj, tylko sposób, w jaki ten monitoring jest zbudowany. Różnica między jednym a drugim jest zasadnicza.

Zwyczaj mówi: „uważamy, żeby niczego nie zapisać”. Budowa mówi: „w tej części, która czyta, nie ma czym zapisać”. Pierwsze zależy od tego, kto pisał kod w piątek po południu. Drugie nie zależy od niczego.

Dlaczego narzędzie, które umie pisać, w końcu napisze

Nie z premedytacji. Z powodów, które w każdym innym systemie kończą się jednym wpisem w logu:

• pomylony adres rejestru w tabeli, w której odczyt i zapis leżą obok siebie;
• odwrócona kolejność argumentów w funkcji przyjmującej adres i wartość;
• ustawienia skopiowane ze środowiska testowego, gdzie zapis był potrzebny;
• pętla ponowień, która robi drugi raz to, co miało wykonać się raz.

Każdy z tych scenariuszy wymaga jednego warunku: żeby funkcja zapisu w ogóle była pod ręką. Usunięcie tego warunku kosztuje zero, dopóki jej w kodzie nie ma. Kosztuje instalację wtedy, kiedy już jest.

Drugi powód doceni każdy, kto utrzymywał cudzy system. Kiedy w instalacji coś się zmieni — a zmieni się — chcesz móc powiedzieć z pewnością: to nie my. Monitoring, który teoretycznie mógł coś zapisać, zostawia to pytanie otwarte na zawsze i każe dowodzić, że się nie zapisało. Monitoring, który nie ma czym pisać, odpowiada na nie jednym zdaniem.

Jedna droga zapisu, pilnowana jak kod

Zapis w tej instalacji istnieje — regulacja salda nocnego nie zrobi się sama — ale ma dokładnie jedno miejsce: autoryzowany flow w Node-RED. Prowadzimy go w dwóch krokach, żeby po każdej zmianie było wiadomo, co dokładnie jest wgrane:

1. Źródło leży w repozytorium jako plik. Flow nie powstaje przez klikanie w edytorze i nie zostaje tam. Edytor pokazuje stan bieżący, a nie prawdę o tym, co miało być wgrane.
2. Wgranie idzie przez POST /flows. Dzięki temu zostaje kopia sprzed zmiany, a każda zmiana ma datę i autora. Kiedy instalacja zachowa się inaczej niż zwykle, wiadomo, co dokładnie było wtedy wgrane — bez odtwarzania z pamięci. „Cofnij” w cudzym edytorze nie jest drogą powrotną.

Po czym poznasz, że ta droga naprawdę jest jedna. Dla każdej zmiany w sterowaniu wskazujesz plik w repozytorium, jego datę i autora. Nie musisz do tego otwierać edytora. Nie wyszło: żeby powiedzieć, co jest teraz wgrane, musisz zajrzeć do edytora i przeczytać, co tam stoi.

Pułapka: to, co wygląda na automatykę, nią nie jest

Zastany „Flow 1” miał 26 węzłów, a mimo to nie sterował niczym. Wszystkie połączenia między klockami były puste poza jednym, które prowadziło donikąd. Żaden odczyt nie docierał do żadnego wyjścia: to była tablica z odczytami, a nie sterowanie. Wcześniejsze założenie brzmiało „nie dotykać, tam działa automatyka ESS”. Liczy się to, co z czym jest połączone, a nie to, ile klocków widać na ekranie. Zanim rozstrzygniesz, co steruje i co wolno wyłączyć, przeczytaj połączenia.

Warto wiedzieć, czym jest edytor stojący pod https://<adres-cerbo>:1881/ — uwaga, to HTTPS i port 1881, nie 1880. Moduł @victronenergy/node-red-contrib-victron daje odczyt i zapis całego dbus, czyli wewnętrznej listy wszystkich wartości w Venus OS. W trybie no-auth znaczy to tyle: każdy w tej sieci dostaje do ręki dokładnie to narzędzie, którym my wykonujemy jedyny autoryzowany zapis.

Jedyna droga zapisu jest zarazem jedynym miejscem, którego awaria zatrzymuje sterowanie. Dlatego ma być najnudniej napisanym kodem, jaki masz. Przykład stąd: po deploy kontekst zostaje z poprzedniej wersji flow, więc nowy klucz jest undefined i funkcja pada — choć „nic nie zmienialiśmy”. Kontekst trzeba czyścić albo czytać z wartością domyślną.

Sprawdź u siebie — pięć odczytów, kwadrans

Nie twierdzimy, że u Ciebie jest tak samo: zmierzyliśmy jedną instalację i nie mamy danych, żeby mówić o rynku. Ale wszystko powyżej to ustawienia domyślne, a nie czyjeś zaniedbanie. Jeśli po montażu nikt ich świadomie nie zmieniał, u Ciebie są takie same. Możesz to sprawdzić sam i przestać zgadywać.

Zanim zaczniesz: sprawdzaj wyłącznie własną instalację. Wszystkie punkty niżej to odczyty — żaden z nich niczego nie przestawia. I jedna rzecz z naszego pomiaru: nie sprawdzaj, ile jednoczesnych połączeń wytrzyma licznik energii. Jedno z nich trzyma sterownik i opiera na nim pracę magazynu. Wypchnięcie go zabiera magazynowi licznik sieci. Sam pomiar bywa ryzykiem i to jest dokładnie ten przypadek.

Przy każdym odczycie piszemy, jak wygląda wynik „otwarte”, a jak „zamknięte”. Wyniku pośredniego tu nie ma: albo usługa odpowiada bez pytania o hasło, albo pyta.

1. Konsola zdalna — czy w ogóle zapytała o hasło? Usiądź przy komputerze podłączonym do tej samej sieci i wpisz w przeglądarce adres sterownika. Jeśli go nie znasz, znajdziesz go na liście urządzeń w routerze — wrócisz do niej w punkcie piątym.

   Otwarte: pulpit instalacji pojawia się od razu i możesz klikać ustawienia. To znaczy, że może to zrobić każdy, kto jest w tej sieci: domownik, gość po Wi-Fi, telewizor, kamera i każde urządzenie, które ktoś kiedyś tu wpiął. Tak jest u nas.

   Zamknięte: przeglądarka najpierw pyta o hasło i bez niego nie pokazuje pulpitu.

2. Node-RED — czy działa u Ciebie i czy wpuszcza bez logowania? Node-RED to edytor, w którym rysuje się automatykę instalacji. Wpisz w przeglądarce ten sam adres co przed chwilą, dopisując na końcu :1881 — całość wygląda tak: https://<adres-sterownika>:1881/.

   Otwarte: otwiera się edytor i od razu widzisz gotowe przepływy. Wtedy każdy w tej sieci może zmienić sterowanie, a nie tylko podejrzeć dane.

   Zamknięte: pod tym adresem nie odpowiada nic — usługa jest wyłączona i tego problemu nie masz.

   Wynik mylący: ostrzeżenie przeglądarki, że połączenie nie jest zaufane, znaczy, że coś tam jednak odpowiada. Adres bez https albo port 1880 zamiast 1881 nie odpowie nawet wtedy, gdy usługa działa.

3. Modbus i MQTT — czy oddają dane bez pytania o hasło. Zajrzyj w ustawieniach sterownika do listy usług (u Victrona: Settings/Services) i zobacz, czy Modbus TCP (port 502) i MQTT (port 1883) są włączone.

   Otwarte: obie pozycje włączone. Odpowiadają wtedy w typowej instalacji każdemu w tej sieci, kto zapyta — hasła w nich nie ma, a Modbus nie ma nawet jak o nie zapytać. Sam podgląd produkcji i zużycia rzadko jest dramatem. Ale ten sam kanał Modbus bywa zapisywalny, a wtedy mówimy już o zmianie pracy instalacji, nie o podglądzie.

   Zamknięte: obie pozycje wyłączone w ustawieniach. Rozstrzyga ta lista, a nie próba połączenia z licznikiem — powód jest wyżej, nad listą.

4. Chmura producenta — czy Twoje dane tam wychodzą. W ustawieniach sterownika znajdź sekcję portalu producenta — u Victrona to VRM — i zobacz, czy włączona jest wysyłka danych, a razem z nią tunel dwukierunkowy.

   Włączona: tak jest u nas. Sam w sobie nie jest to błąd. To wygoda, za którą płacisz tym, że pełna historia instalacji leży poza Twoim budynkiem.

   Wyłączona: dane zostają u Ciebie — i wtedy pada pytanie, gdzie masz historię. Lokalnie prawie jej nie ma: MPPT trzyma dwie doby, a archiwum falownika zna wyłącznie produkcję AC.

   Tak czy inaczej ma to być Twoja decyzja, a nie ustawienie, którego nikt nigdy nie ruszał.

5. Kto jeszcze jest w tej sieci. Otwórz w routerze listę podłączonych urządzeń i spróbuj nazwać każde po kolei.

   Wynik dobry: nazywasz każdą pozycję z listy i wiesz, po co tam jest.

   Wynik zły: zostaje choć jedno urządzenie, którego nie umiesz nazwać — a usługi z punktów wyżej wpuszczają je bez pytania. Nazwa podpowiedziana przez router też bywa myląca: dla naszego falownika baza producentów podpowiada „Fronius Schweissmaschinen”, czyli spawarki.

   To pytanie przesądza o wadze czterech poprzednich. Jeżeli automatyka budynku siedzi w tej samej sieci co goście, telewizor i kamery kupione z drugiej ręki, „dostęp tylko lokalny” znaczy coś zupełnie innego, niż się wydaje.

Jeśli wszystkie pięć odpowiedzi brzmi „tak, otwarte” — jesteś w tym samym miejscu, co instalacja opisana w tym artykule. W następnym rozdziale jest, co z tym zrobić. Przy każdej pozycji piszemy też, co realnie zamyka, a czego nie.

Co z tym zrobić — od darmowego do kosztownego

Kolejność poniżej to kolejność kosztu, a nie ważności. Przy każdej pozycji piszemy trzy rzeczy: co ona naprawdę zamyka, czego nie zamyka i po czym poznasz, że zadziałała.

Pozorne zabezpieczenie jest gorsze od jawnie otwartego dostępu

Otwarty port widać w każdym zestawieniu i wraca w każdym kolejnym przeglądzie. Hasło założone na jedne drzwi, kiedy obok stoją trzy otwarte, daje spokój — i na tym spokoju temat się kończy. Nikt tu już nie wróci, bo „przecież jest hasło”. Dlatego każdą pozycję z tej listy czytaj razem z jej drugą połową.

1. Hasło na Remote Console (koszt: zero)

   Zamyka: wejście z przeglądarki do pełnego panelu GX komuś, kto po prostu trafił do tej sieci. To najszersze pojedyncze drzwi: z konsoli widać wszystko, co ma pozycję w menu, i wszystko to da się przestawić.

   Nie zamyka: portu 502, portu 1883 ani edytora na 1881. Żadna z tych usług o hasło do konsoli nie pyta. To nie jest hasło do urządzenia, tylko hasło do jednych drzwi. Odczyt Modbusem działa po jego ustawieniu dokładnie tak samo jak wcześniej.

   Sprawdzenie jest jedno: z innego komputera w tej samej sieci otwórz w przeglądarce adres sterownika. Wyszło: przeglądarka pyta o hasło i bez niego nie pokazuje pulpitu. Nie wyszło: pulpit pojawia się od razu, tak jak przedtem.

2. Tryb secured zamiast no-auth tam, gdzie coś steruje (koszt: zero plus jeden restart)

   Ustawienie Settings/Services/NodeRed ma trzy stany: 0 = wyłączony, 1 = secured (wymaga hasła), 2 = no-auth. Sam Node-RED jest tylko w wersji systemu Large.

   Zamyka: anonimową zmianę przepływów, czyli anonimową zmianę sterowania ESS. Jeżeli w instalacji jest choć jeden flow, który cokolwiek zapisuje, ta pozycja jest obowiązkowa.

   Nie zamyka: Modbusa. Ktoś w tej sieci wciąż sięga po setpointy, nie pytany o nic. Zamykasz wygodniejszą drogę, nie jedyną.

   Pułapka, przez którą bywa to zabezpieczeniem wyłącznie na papierze: przełączenie tego ustawienia nie działa od razu — ani 1→2, ani 2→0→2. Potrzebny jest restart GX, a SSH bywa zamknięty, więc nie ma jak zrestartować samej usługi. Przestawiasz na secured, wychodzisz z panelu z poczuciem, że zrobione, a edytor nadal wpuszcza bez pytania. Sprawdzenie jest jedno: po restarcie otwórz https://<adres-cerbo>:1881/. Wyszło: edytor prosi o logowanie. Nie wyszło: otwiera się od razu, tak jak przedtem.

3. Świadoma decyzja o tunelu do chmury producenta (koszt: zero złotych, prawdziwa cena w funkcjach)

   Zamyka: wysyłkę danych instalacji do chmury producenta, a razem z nią kanał, który już z nazwy idzie w obie strony.

   Nie zamyka: niczego w sieci lokalnej — wszystkie pozycje z tabeli zostają na miejscu. Działa to też w drugą stronę: zapora blokująca ruch przychodzący tunelu nie dotyka, bo tunel wychodzi z instalacji na zewnątrz. Nie ma tu miejsca na „przecież mamy firewalla”.

   Czego ta decyzja naprawdę dotyczy: lokalnie historii prawie nie ma. MPPT trzyma dwie doby, a komplet — zużycie, bateria, sieć — jest dopiero w chmurze. Fronius ma własne archiwum 5-minutowe, ale wyłącznie produkcji AC. Jeśli wyłączysz tunel i nie zbierasz danych u siebie, za miesiąc nie odpowiesz na pytanie, co się działo. To wybór między suwerennością a historią.

   Sprawdzenie widać dopiero po czasie: miesiąc po decyzji zapytaj, co działo się w instalacji tydzień wcześniej. Wyszło: odpowiadasz z danych, które trzymasz u siebie. Nie wyszło: nie masz skąd — MPPT trzyma dwie doby, a archiwum falownika zna wyłącznie produkcję AC. Czego nie sprawdziliśmy: co widać w portalu producenta po wyłączeniu wysyłki. U nas tunel jest włączony i tego nie mierzyliśmy.

   W budynku klienta tę decyzję podejmuje właściciel, a nie firma, która instalację montuje. Zadaniem firmy jest tylko postawić to pytanie przed wdrożeniem, a nie po pierwszym pytaniu prawnika.

4. Wydzielona sieć dla automatyki (koszt: konfiguracja, czasem sprzęt, zawsze praca)

   Skoro te urządzenia z założenia nie pytają, kim jesteś, granicą musi być sieć. Wydziel osobną sieć wokół automatyki i przepuszczaj do niej wyłącznie ruch, który ma prawo tam wjechać.

   Zamyka: dostęp z ogólnej sieci budynku, z Wi-Fi dla gości, z laptopa, który złapał coś w załączniku. To jedyna pozycja na tej liście, która zamyka wszystkie usługi z tabeli naraz, bo działa piętro niżej niż każda z nich. Dlatego jest ważniejsza od dwóch pierwszych, mimo że droższa.

   Nie zamyka: dostępu komukolwiek, kto już jest w środku. Maszyna zbierająca dane staje się najcenniejszym urządzeniem w budynku, bo ma tam wstęp z definicji. Od tej pory jej zabezpieczenie jest zabezpieczeniem instalacji. Nie zamyka też tunelu do chmury ani dostępu fizycznego do urządzeń.

   Warunek wstępny: taki podział jest tyle wart, ile spis tego, co dzielisz. Bazy producentów rozpoznają sprzęt po pierwszych znakach adresu MAC. Dla tego falownika podpowiadają „Fronius Schweissmaschinen”, czyli spawarki. Producent się zgadza, ale w sieci stoi falownik — i rozstrzyga dopiero odpowiedź Solar API. Podział zrobiony z samej listy adresów MAC potrafi zostawić falownik po złej stronie granicy.

   Sprawdzenie jest jedno: powtórz pięć odczytów z rozdziału „Sprawdź u siebie”, ale z komputera stojącego w ogólnej sieci budynku. Wyszło: stamtąd nie odpowiada żadna z tych usług. Nie wyszło: odpowiada choć jedna — granicę wtedy narysowałeś, ale jej nie pilnujesz. Czego nie sprawdziliśmy: u siebie takiego podziału nie mamy, więc tej pary wyników nie widzieliśmy na własnym pomiarze.

5. Własne zbieranie danych, a osobno jedna droga zapisu (koszt: to już projekt, nie ustawienie)

   Co zamyka własne zbieranie danych: zależność od chmury producenta w pytaniu „co się działo”. To jedyny sposób, żeby wyłączyć tunel i nie stracić historii.

   Co zamyka jedna droga zapisu: pytanie „czy to my” po każdej zmianie w instalacji. Odpowiadasz na nie jednym zdaniem, zamiast dowodzić, że nic nie zapisałeś.

   Czego nie zamyka ani jedno, ani drugie: tego, że w sieci lokalnej te urządzenia nie pytają, kim jesteś. Tego nie zamyka nic poza granicą sieci. Jeżeli masz wybrać z tej listy jedną pozycję, wybierz poprzednią — jest tańsza i zamyka więcej.

   Sprawdzenie zbierania: zapytaj własnej bazy o dobę sprzed miesiąca. Wyszło: baza oddaje próbki z tej doby. Nie wyszło: szereg zaczyna się później, niż sięga pytanie.

   Sprawdzenie jednej drogi zapisu: poszukaj w kodzie monitoringu funkcji zapisu po Modbus. Wyszło: nie ma jej, więc nikt jej przez pomyłkę nie wywoła. Nie wyszło: jest, tylko dziś nikt jej nie woła.

Czego nie zmierzyliśmy

Ten rozdział jest w tej serii obowiązkowy. Bez niego poprzednie brzmiałyby pewniej, niż na to zasługują.

• Ile połączeń Modbus naraz przyjmuje EM24. Wiemy, że co najmniej dwa, bo tyle sami utrzymujemy. Ile dokładnie — nie sprawdzimy na żywej instalacji i uważamy, że nikt nie powinien.
• Czy zapis przez Modbus faktycznie przestawi instalację. Nie próbowaliśmy. Funkcje zapisu są dostępne bez hasła i sięgają setpointów sieci oraz przekaźników. Sprawdzenie „czy naprawdę” byłoby dokładnie tym, przed czym ostrzegamy.
• MQTT na porcie 8883 — czy pyta o hasło. Port jest dostępny i szyfrowany, ale szyfrowanie chroni drogę, a nie odpowiada na pytanie, kto pyta. Tego nie mierzyliśmy.
• MQTT na porcie 1883 — co da się przez niego zapisać. Wiemy, że wpuszcza anonimowo. Co dokładnie da się przez niego zrobić — nie sprawdzaliśmy.
• Numer seryjny licznika ani wersja firmware EM24. Nie znaleźliśmy ich w rejestrach i tak to zapisujemy, zamiast zgadywać. W praktyce znaczy to tyle: tego licznika nie spiszesz do inwentarza zdalnie, przez sieć — trzeba podejść i przepisać z tabliczki.
• Jak głęboko sięga archiwum Froniusa. Potwierdziliśmy do 01.09.2025; starszych danych nie sprawdzaliśmy.

I zastrzeżenie na koniec: to jest pomiar jednej instalacji. Twoja może mieć otwarte inne usługi. Tabela z pierwszego rozdziału jest metodą — listą pytań do własnej sieci — a nie opisem tego, co masz u siebie. Jeżeli zrobisz po tym artykule jedną rzecz, niech to będzie ta tabela wypełniona Twoimi własnymi odpowiedziami.