Fronius Solar API i archiwum 5-minutowe: jakie dane daje Symo

Solar API: otwarte, bez hasła, tylko do odczytu

Wpisujesz adres w przeglądarce i falownik oddaje wszystko, co wie o sobie w tej sekundzie: P_PV = 3416 W, 9,1 kWh od północy, 20,3 MWh od uruchomienia. Bez loginu, bez hasła, bez konta w chmurze producenta. Ten artykuł mówi, które adresy naprawdę coś zwracają i dlaczego część pól jest pusta. Pokazuje też, gdzie ten falownik trzyma historię głębszą niż jakikolwiek monitoring, który postawisz dziś. Wszystkie liczby pochodzą z jednej instalacji: Fronius Symo 3.7-3-S z kartą Fronius Datamanager, pracujący jako źródło PV po stronie AC w układzie ESS.

Za Solar API odpowiada karta komunikacyjna, a nie sam inwerter. Odpowiada tekstem w formacie JSON, nikogo nie pyta o hasło i działa wyłącznie do odczytu — nie ma tam niczego, czym zmienisz ustawienie falownika. Początek adresu, wspólny dla wszystkich wywołań, dostajesz w odpowiedzi na pierwsze z nich. Nie musisz go zgadywać.

Nazwij to poprawnie. Otwarte Solar API nie jest „dziurą” ani zaniedbaniem instalatora. To domyślne zachowanie karty i decyzja producenta: dane produkcji w sieci lokalnej są jawne. W domu albo na instalacji pokazowej to jest akceptowalne ryzyko. U klienta to samo zdanie brzmi inaczej. Tam właściciel sieci musi rozstrzygnąć, kto ma do niej wstęp i gdzie te dane wolno wypuszczać. To nie jest temat „zapomnieli ustawić hasła”.

Trzy rzeczy, które zaskakują za pierwszym razem

Nocą API milczy. Falownik śpi i nie odpowiada. To nie jest błąd — po prostu nie ma tam kogo zapytać. Monitoring musi to odróżnić: ma oznaczyć dane jako stare, a nie rysować ostatnią znaną moc tak, jakby była aktualna. Nocny wykres ze stałą mocą nie pokazuje produkcji, tylko zamrożony odczyt.

Nazwa własna falownika przychodzi zakodowana — tak, jak w HTML-u zapisuje się znaki specjalne. Jeśli wstawisz ją na ekran bez odkodowania, w tabeli urządzeń zobaczysz krzaki zamiast nazwy. Wygląda to na problem z czcionką, a jest zwykłym pominięciem przy czytaniu odpowiedzi.

P_PV to nie to samo, co moc AC. Pierwsza liczba opisuje produkcję po stronie paneli, druga moc oddaną po stronie AC; różnią się o straty przemiany. Obie są poprawne i obie bywają potrzebne, ale wybierz jedną jako „moc falownika” w swoim monitoringu i trzymaj się jej. Inaczej dwa wykresy tej samej instalacji nigdy się nie zgodzą. Będziesz wtedy szukał usterki tam, gdzie jest tylko różnica w tym, co się liczy.

To samo urządzenie widziane dwa razy

W tej instalacji falownik widać podwójnie. Raz przez sterownik systemu ESS (Venus OS v3.79 na Cerbo GX, gdzie Symo figuruje jako pvinverter), a raz bezpośrednio, przez własne Solar API. To wygodne: dwa niezależne źródła tej samej wielkości mogą się nawzajem kontrolować. To także pułapka księgowa — nie sumuj tych dwóch odczytów. Sterownik pokazuje sumę całego systemu, falownik pokazuje siebie. Dodane do siebie dają produkcję, której nigdy nie było.

Tryb produce-only: puste pola, które wyglądają na Twój błąd

Ta instalacja pracuje w trybie produce-only: po stronie Froniusa nie ma ani Smart Metera, ani baterii. Skutek widać w odpowiedzi natychmiast. Pola P_Grid, P_Load i P_Akku mają wartość null, czyli „puste” — nie ma tam żadnej liczby, nawet zera. Tak samo puste są procenty autonomii i autokonsumpcji. Same nazwy pól w odpowiedzi są, tylko nikt ich nie wypełnił.

To najczęstszy powód, dla którego pierwszy dzień pracy z tym API kończy się szukaniem błędu we własnym programie. Budujesz monitoring na P_Load, bo dokumentacja to pole pokazuje. Dostajesz pustkę i zaczynasz sprawdzać program, sieć i uprawnienia. Tymczasem odpowiedź jest poprawna: falownik nie ma czym zmierzyć ani sieci, ani domu. Licznik na przyłączu i bateria są tu podpięte pod inny sterownik. To on, a nie Fronius, wie cokolwiek o zużyciu.

Zero to nie brak

Nie podstawiaj zer pod puste pola. „Sieć 0 W” to konkretna i całkiem możliwa informacja: akurat nic nie płynie. Wpisane w miejsce braku pomiaru, takie zero przestaje się różnić od zera prawdziwego i nikt później nie odgadnie, które było które. Program ma pola puste pomijać, a ekran ma chować wiersz, którego nie ma czym wypełnić. Puste miejsce jest uczciwe, wyzerowany wykres nie.

Sprawdzaj najpierw pole Mode, zanim cokolwiek zbudujesz. To jedno pole mówi, czy reszta odpowiedzi ma prawo być wypełniona. Na instalacji ze Smart Meterem i magazynem po stronie Froniusa ten sam adres zwróci komplet. Pola zapalą się wtedy same, bez żadnej zmiany w programie — o ile wcześniej nie „naprawiłeś” go zerami.

Druga konsekwencja pracy bez licznika jest mniej oczywista. Dane trójfazowe dają napięcia i prądy osobno dla każdej fazy, ale nie dają mocy czynnej na fazę — tej bez licznika nie ma skąd wziąć. Napięcie razy prąd aż się prosi, żeby policzyć tę moc samemu. Tylko że z takiego mnożenia wychodzi moc pozorna w VA, a nie moc czynna w W. Możesz ją pokazywać, ale podpisz ją jako szacunek. Inaczej za pół roku porównasz tę liczbę z odczytem licznika i uznasz, że jedno z urządzeń kłamie.

Archiwum w samym falowniku, czyli rok historii przed pierwszym czujnikiem

Nasz własny system zbiera pomiary tej instalacji od 30.08.2026 22:07 — sześć pełnych dób w chwili pisania. Falownik w tym samym momencie miał własną historię potwierdzoną wstecz do 01.09.2025, z próbką co 5 minut. Trzyma ją u siebie, oddaje przez to samo otwarte API i nie potrzebuje do tego chmury.

O historię pytasz tak:

GET /solar_api/v1/GetArchiveData.cgi
      ?Scope=System
      &StartDate=RRRR-MM-DD
      &EndDate=RRRR-MM-DD
      &Channel=EnergyReal_WAC_Sum_Produced
      &SeriesType=Detail

• SeriesType=Detail — próbka co 5 minut, czyli 288 na dobę.
• SeriesType=DailySum — sumy dzienne, gdy interesuje Cię tylko przebieg miesięcy.
• Channel=EnergyReal_WAC_Sum_Produced — energia rzeczywista wyprodukowana po stronie AC. To jedyna wielkość, którą ta instalacja ma czym wypełnić. Dlaczego — mówi rozdział czego w tym archiwum nie ma.
• Zasięg potwierdzony wstecz do 01.09.2025. Starszych dat nie sprawdzaliśmy — i tak to zapisujemy, zamiast twierdzić, że ich nie ma.

Po czym poznasz, że odczyt się udał: pełna doba przynosi 288 próbek, a każda z nich jest podpisana liczbą sekund od StartDate. Pusta lista przy braku błędu to osobny przypadek — mówi o nim rozdział o pułapce 16 dni.

To zmienia układ sił przy nowym kliencie. Na pytanie „jak ta instalacja pracowała w zeszłym roku” standardowa odpowiedź brzmi: „nie wiem, zaczynamy mierzyć dziś, wróćmy do tematu za rok”. Tutaj już pierwszego dnia masz roczną historię produkcji, próbka co 5 minut — jeszcze zanim postawisz jakikolwiek czujnik. Wystarczy to, żeby policzyć rozkład dnia, znaleźć doby wyraźnie odstające i porównać miesiące między sobą. Nie musisz prosić o dostęp do konta w portalu producenta ani czekać na eksport od instalatora — wystarczy dojść do urządzenia w sieci lokalnej i mieć zgodę właściciela.

Potwierdzone pomiarem. Cały sierpień 2026 pobraliśmy z tego archiwum: 588,7 kWh, średnio 19,0 kWh na dobę. Przez niemal cały ten miesiąc nasz monitoring nie miał ani jednej próbki — zaczął zbierać dopiero wieczorem 30.08. Liczby z sierpnia istnieją wyłącznie dlatego, że falownik zapisał je sam u siebie.

Pułapka: pytanie o cały miesiąc wraca puste, ale bez błędu

Falownik odda historię najwyżej za 16 dni naraz. Poproś o dłuższy okres — choćby o cały miesiąc — a odpowiedź i tak przyjdzie. I to taka, która ze wszystkich stron wygląda na udaną: żadnego błędu, żadnego ostrzeżenia, odpowiedź zbudowana dokładnie tak, jak się jej spodziewasz. Dopiero w jej środku, w nagłówku o nazwie Head, siedzi Status.Code=255 i komunikat Query interval is restricted to 16 days. To znaczy: pytasz o zbyt długi okres, nie dostaniesz danych. Miejsce na dane w tej odpowiedzi jest puste.

To najgroźniejsza rzecz, jaka może Cię tu spotkać, bo w niczym nie przypomina błędu. Kto patrzy tylko na to, czy odpowiedź przyszła, idzie dalej bez mrugnięcia okiem. Brak danych bierze wtedy za fakt o instalacji: ten falownik nie ma historii sprzed miesiąca. Taki wniosek trafia do notatki, notatka do oferty, a rok historii dalej spokojnie leży w urządzeniu, nikt go nie zauważył. Kilka minut wcześniej to samo API pokazało bieżącą moc, więc nikomu nie przychodzi do głowy, że wina jest po stronie źle zadanego pytania.

1. Czytaj nagłówek Head w środku odpowiedzi. Nie tylko to, czy odpowiedź przyszła. To, że przyszła, znaczy tyle, że urządzenie odebrało pytanie. Czy je wykonało — mówi dopiero kod w środku. Sprawdź, jaki kod przychodzi przy zapytaniu, o którym wiesz, że się udało, i porównuj z nim. U nas odmowa z powodu zbyt długiego okresu to 255.
2. Dziel zakres na kawałki nie dłuższe niż 16 dni. Miesiąc to dwa zapytania, na przykład 2026-08-01 … 2026-08-16 i 2026-08-17 … 2026-08-31. Dziel z zapasem. Nie sprawdzaliśmy, czy do tych 16 dni wlicza się dzień z EndDate, a test „czy 16 znaczy 16” kosztuje więcej niż jeden dzień marginesu.
3. Policz próbki i porównaj z tym, ilu się spodziewasz. Przy SeriesType=Detail pełna doba to 288 próbek. Pobieranie ma meldować, ile próbek pobrało, a nie że „poszło”. Zero pobranych próbek przy zerze błędów to nie sukces, tylko cisza — i pozna ją tylko ten, kto liczy.
4. Zapisuj osobno „brak danych” i „odmowa, bo okres za długi”. To dwa różne zdania: pierwsze mówi o instalacji, drugie o Twoim zapytaniu. Jeśli w zapisie zdarzeń wyglądają tak samo, za miesiąc nie odtworzysz, które było które.
5. Kawałki sklejaj po dacie i godzinie, nie po kolejności. Najpierw przelicz podpisy próbek na konkretny czas (patrz następny rozdział), a dopiero potem łącz. Gdy pobierasz kilka kawałków naraz, nic nie gwarantuje, że wrócą w tej kolejności, w której o nie poprosiłeś.

Po czym poznasz, że tym razem wyszło: w nagłówku Head stoi ten sam kod co przy zapytaniu, o którym wiesz, że się udało. Każda pełna doba przynosi wtedy 288 próbek. Cały sierpień 2026 złożyliśmy właśnie tak, z dwóch kawałków — wyszło 588,7 kWh.

Brak błędu to nie jest wynik pomiaru. Ta sama zasada wraca w tej serii przy każdym urządzeniu: „nic nie krzyknęło” znaczy tylko tyle, że nic nie krzyknęło. Stan trzeba przeczytać wprost — z kodu w treści odpowiedzi, z licznika próbek, z licznika energii. Systemy, które o tym zapominają, nie psują się głośno; one po cichu przestają mieć rację.

Czas w archiwum jest liczony od dnia, o który zapytałeś

Druga rzecz, na której łatwo się przewrócić przy tym archiwum. Każda próbka jest podpisana liczbą, ale ta liczba nie jest ani godziną, ani datą. To liczba sekund liczona od StartDate, czyli od dnia, który podałeś w zapytaniu jako początek zakresu. Przy próbce co 5 minut kolejne podpisy rosną co 300, bo tyle sekund ma pięć minut. Żeby dostać prawdziwą godzinę, musisz te sekundy dodać do podanego dnia.

Pomyłka w tym miejscu niczego nie wywala. Ona przesuwa cały wykres. Weźmiesz te liczby za czas liczony tak, jak liczą go komputery, czyli od 1970 roku — dostaniesz dane z początku lat siedemdziesiątych. Weźmiesz je za numer kolejnej próbki — dostaniesz całą dobę ściśniętą do kilku minut. Najgorszy jest jednak wariant trzeci: przeliczysz je dobrze, ale dodasz do złego dnia. Wykres wygląda wtedy zupełnie sensownie, tylko produkcja wypada nie o tej porze, co powinna. Wnioski o „porannym szczycie” biorą się wtedy z arytmetyki, a nie ze słońca.

Jak to złapać bez żadnego drugiego źródła: produkcja PV ma zero w nocy i jeden szczyt w środku dnia. Tę kontrolę masz zawsze i za darmo. Jeśli po przeliczeniu szczyt siedzi w środku nocy albo doba zaczyna się od produkcji, to nie falownik jest zepsuty — to przeliczenie jest złe. Sprawdź przy okazji, czy pierwsza i ostatnia próbka wypadają tam, gdzie powinny przy zadanym zakresie.

I jeszcze jedno: nie zakładaj, że próbek zawsze jest 288. Policz je. To najtańszy sposób, żeby sprawdzić, czy doba jest kompletna. A jeśli nie jest, lepiej dowiedzieć się od razu — niepełna doba wchodzi do średniej tak samo jak pełna i po cichu ją zaniża.

Czego w tym archiwum nie ma: wszystkiego poza produkcją

Archiwum falownika zna wyłącznie produkcję AC. Nie ma w nim zużycia domu, nie ma stanu baterii, nie ma poboru ani oddania do sieci. Powód jest prosty i wart zapamiętania, bo dotyczy każdej takiej instalacji. Falownik zapisuje to, co potrafi zmierzyć, a bez Smart Metera po swojej stronie nie mierzy niczego poza sobą.

W tej instalacji reszta obrazu leży po stronie drugiego producenta. Magazyn i sterowanie to system ESS na Cerbo GX z Venus OS v3.79. Należą do niego: inwerter/ładowarka MultiPlus w układzie trójfazowym i bateria Pylontech 222 Ah z trzech modułów US3000C. Do tego ładowarka solarna MPPT BlueSolar po stronie DC oraz licznik sieci Carlo Gavazzi EM24 na przyłączu. Baterię zmierzyliśmy: 10,1 kWh do pełna i 8,6 kWh do progu 15%. Falownik Fronius jest tu jednym z pięciu urządzeń — i jedynym, które trzyma własną, głęboką historię.

Historia po drugiej stronie jest płytka. W samym sterowniku ESS praktycznie jej nie ma: ładowarka MPPT trzyma dane z dwóch dób. Komplet — zużycie, bateria, sieć — jest dopiero w chmurze producenta. Jeśli więc budujesz obraz instalacji z samych urządzeń w sieci lokalnej, dostajesz roczną historię produkcji i dwie doby całej reszty. To nie jest wada projektu. To fakt, który musisz znać, zanim obiecasz komuś analizę zeszłego lata.

Praktyczny wniosek jest taki: falownik odpowiada na pytanie „ile wyprodukowałem”, a nie na pytanie „ile z tego zostało u mnie”. To drugie pytanie wymaga co najmniej dwóch źródeł, a rozstrzyga je licznik na przyłączu. W tej instalacji czytamy go trzecią, niezależną drogą — wprost, a nie przez sterownik. Właśnie po to, żeby mieć czym sprawdzić dwa pozostałe odczyty.

Liczby: miesiąc z falownika i tydzień z naszego monitoringu

Poniżej dwa spojrzenia na tę samą instalację. Pierwsze pochodzi z archiwum falownika i obejmuje cały sierpień 2026. Drugie z naszego monitoringu i obejmuje sześć pełnych dób, 30.08.2026 22:07 – 05.09.2026 23:41, przy próbce co 2 minuty. Różnią się nie tylko długością, ale i tym, co w ogóle potrafią pokazać.

Sierpień z archiwum: 588,7 kWh i rozpiętość, której nie widać w aplikacji

Miesiąc dał 588,7 kWh, średnio 19,0 kWh na dobę. Ale średnia jest tu najmniej ciekawą liczbą. Najlepsza doba to 25,5 kWh, najsłabsza 5,9 kWh — ponad czterokrotna różnica w obrębie jednego miesiąca, w środku sezonu. Tego nie zobaczysz w kafelku „ile dziś”, bo kafelek pokazuje jeden dzień, a nie to, jak bardzo doby różnią się między sobą.

Sześć dób z monitoringu: produkcja to tylko jedna z czterech liczb

Nasz własny system ma krótszą historię, ale pokazuje więcej naraz: obok produkcji zna zużycie domu, pobór z sieci i oddanie do sieci. Dopiero te cztery liczby razem układają się w bilans.

W tym oknie były też dwie przerwy w zbieraniu danych, łącznie 0,7 godziny, najdłuższa 28 minut 02.09 o 19:28. Zapisujemy je, bo brakująca próbka wpływa na sumę doby. A sama suma wygląda identycznie niezależnie od tego, czy przerwa była, czy nie.

Liczniki od początku pracy: gdzie poszła ta energia

Przy tych trzech liczbach brakuje daty odczytu i nie umiemy jej odtworzyć. Nie zapisaliśmy, kiedy zdjęliśmy te stany liczników — a dla licznika narastającego moment odczytu jest połową treści liczby. Piszemy to wprost, zamiast dopisywać datę z pamięci. Jedyny datowany odczyt tych samych dwóch liczników na przyłączu podajemy w artykule o EM24: 01.09.2026 stało na nich 7022,6 kWh pobrane i 5185,5 kWh oddane. To jest inny odczyt niż wiersze w tabeli wyżej, a nie ich data.

Z tego zestawienia wynika jedna rzecz warta zapamiętania: do sieci trafiła około jedna czwarta wszystkiego, co ta instalacja wyprodukowała od uruchomienia. Trzy czwarte zostało zużyte na miejscu — albo od razu, albo po drodze przez magazyn. Druga rzecz: z sieci pobrano więcej, niż do niej oddano. Samo w sobie nie jest to ani dobre, ani złe. Mówi tylko tyle, że instalacja nie jest samowystarczalna w skali roku i nigdy nie miała być.

Granica tego porównania. To są dwa różne liczniki: produkcja pochodzi z falownika, oddanie i pobór z licznika na przyłączu. Nie sprawdziliśmy, czy oba zaczęły liczyć w tym samym momencie — a bez tego „około 25%” jest rzędem wielkości, nie wynikiem pomiaru. Świadomie nie przeliczamy też tych kilowatogodzin na złotówki. Stawki, którymi liczymy w tej serii, są założeniem z konfiguracji i dotyczą sześciodobowego okna, a nie kilku lat pracy instalacji.

Ciekawostka: według bazy producentów to spawarka

Przy spisywaniu urządzeń w sieci ten falownik potrafi zmylić. Każde urządzenie ma adres MAC, a jego początek wskazuje producenta. Publiczna baza podpowiada dla tego początku nazwę Fronius Schweissmaschinen, czyli dosłownie: spawarki. To nie jest błąd bazy. To ten sam producent, tylko inna linia produktów, wpisana do rejestru dawno temu.

Skutek jest praktyczny. Jeśli spis urządzeń powstaje z samych adresów MAC, na liście sprzętu w budynku pojawi się spawarka, której tam nie ma. Ktoś to potem przepisze do raportu, ktoś inny zapyta, po co w serwerowni spawarka. Nazwa z tej bazy mówi o producencie i nic nie mówi o tym, do czego urządzenie służy — a w spisie chodzi właśnie o to drugie.

Co rozstrzyga: odpowiedź spod adresu /solar_api/. Jeśli urządzenie oddaje dane produkcji, jest falownikiem PV i temat jest zamknięty. Do tej metody są dwa zastrzeżenia. Po pierwsze, pytaj w dzień: nocą falownik śpi i milczy, więc brak odpowiedzi jeszcze niczego nie dowodzi. Po drugie, narzędzie skanujące sieć po SNMP nie nazwie tego urządzenia w ogóle — karta Datamanager tego protokołu nie obsługuje, więc cisza na SNMP też nie jest wynikiem.

Zasada ogólna, którą z tego wyjmij: rozpoznanie po adresie MAC jest wskazówką, nie rozstrzygnięciem. Rozstrzyga to, co urządzenie odpowie, gdy się je zapyta w jego własnym języku.

Jedno urządzenie nie opowie całej historii

Podsumujmy. Z samego falownika Fronius Symo z Datamanagerem masz trzy rzeczy. Pierwsza: stan bieżący, oddawany przez otwarte i czytelne API, bez żadnego hasła. Druga: roczna historia produkcji AC z próbką co 5 minut, trzymana w samym urządzeniu. Trzecia: dwie pułapki, o których trzeba wiedzieć, bo obie wyglądają jak poprawna odpowiedź, a nie jak błąd.

Czego nie masz: zużycia, baterii i sieci. Te wielkości mieszkają w innych urządzeniach tej samej instalacji. Każde otwiera się inaczej, każde ma inną głębokość historii i własne pułapki. Bilans doby — ile wyprodukowałem, ile zjadłem, ile kupiłem, ile oddałem — nie powstaje z jednego źródła. Powstaje ze złożenia kilku, z których każde mówi prawdę o swoim kawałku i milczy o reszcie.

Dlatego ta seria nie jest zbiorem instrukcji do pojedynczych urządzeń. Jest opisem tego, co widać dopiero wtedy, gdy się je zestawi: licznik na przyłączu czytany wprost, sterownik magazynu, regulacja salda i pomiar, który rozstrzyga spory między nimi. Falownik jest w tym układzie najbardziej otwartym i najbardziej pamiętliwym uczestnikiem — i dobrym miejscem, żeby zacząć.

Zasada, którą trzymamy przy każdym z tych urządzeń: nasz monitoring tylko czyta, nigdy nie zapisuje. Solar API tego falownika i tak nie pozwala na nic innego. W pozostałych źródłach tej instalacji zapis bywa możliwy. Tam też z niego nie korzystamy — poza jedną ścieżką, którą dopuściliśmy świadomie. Pomiar, który zmienia mierzony układ, przestaje być pomiarem.