Jak AI obsługuje alarmy, uzyski i serwis instalacji fotowoltaicznych w SolarEdge, Fronius i Huawei FusionSolar?

Tak, AI można podłączyć do wszystkich trzech platform i dostać z nich spójny obraz setek instalacji naraz. SolarEdge, Fronius i Huawei FusionSolar mają REST API dostępne dla kont instalatora, więc zamiast logować się do trzech osobnych portali, firma serwisująca instalacje fotowoltaiczne może otrzymywać jeden raport rano: które instalacje wymagają reakcji, gdzie falownik przestał odpowiadać w nocy i jakie alarmy czekają na obsługę. To nie jest odległa wizja, to działa dzisiaj przy odpowiednim podłączeniu.

Trzy portale, trzy API: co musi mieć firma, żeby AI miało dostęp do danych

Każda platforma idzie trochę inną drogą technicznie, ale wszystkie trzy udostępniają dane przez REST API. Różnica jest w tym, jak się uwierzytelniasz i co konkretnie dostajesz.

SolarEdge Monitoring udostępnia REST API pod adresem monitoringapi.solaredge.com. Klucz API generujesz w ustawieniach konta instalatora: zakładka Admin, a w niej API Access. Jeden klucz obejmuje wszystkie instalacje przypisane do twojego konta. Najważniejsze endpointy to /sites/list (lista twoich instalacji z ich siteId, adresem i statusem połączenia), /site/{siteId}/alerts (aktywne alarmy z polami alertType, alertCode i datą wystąpienia) oraz /site/{siteId}/energy (uzyski za dowolny zakres dat, dobowo lub godzinowo). Do danych na poziomie pojedynczego optymalizatora potrzebna jest odpowiednia konfiguracja sprzętowa po stronie klienta.

Fronius daje dwa wejścia i ma to znaczenie praktyczne. Fronius Solar.web to portal chmurowy z API opartym na OAuth 2.0 i koncie instalatora. Jest też lokalny Fronius Solar API bezpośrednio na falowniku, dostępny przez adres IP urządzenia w sieci klienta, na porcie 80, jako REST, bez konta w chmurze. Lokalne endpointy to m.in. GetInverterRealtimeData (aktualna moc, napięcie, prąd), GetPowerFlowRealtimeData (przepływ energii w systemie) i GetErrorCodes (kody błędów falownika). W praktyce: zdalne monitorowanie całej floty robimy przez chmurę Solar.web, a lokalny interfejs przydaje się, gdy jesteśmy na miejscu u klienta albo gdy falownik nie łączy się z chmurą i chcemy sprawdzić stan przez laptopa podłączonego do sieci lokalnej.

Huawei FusionSolar udostępnia tzw. Northbound Interface, czyli API REST dla kont instalatora i właściciela. Jeden szczegół, który prawie zawsze wychodzi dopiero przy pierwszym podłączeniu: dostęp API trzeba ręcznie włączyć w ustawieniach konta w portalu, w sekcji API Management. Bez tego kroku żadne uwierzytelnienie nie zadziała, choćbyś miał poprawne dane. Po włączeniu API zwraca m.in. plant list (lista instalacji z plantCode i adresem), device list (urządzenia z devTypeId, esnCode czyli numerem seryjnym i devStatus), alarm list (pola alarmId, alarmName, alarmCause, devName) oraz dane historyczne produkcji i odczyty w czasie rzeczywistym. Starsze instalacje pracujące pod NetEco wymagają oddzielnego konta z własnym API, ale nowe obiekty wchodzą bezpośrednio przez FusionSolar.

Czego producenci nie udostępniają bez ograniczeń: bardzo wysokie częstotliwości odpytywania (rate limity SolarEdge to kilkadziesiąt zapytań na minutę), niektóre szczegółowe dane diagnostyczne wymagające wyższych licencji konta, a dostęp bez aktywnego konta instalatora daje dane tylko dla jednego obiektu jako właściciel.

Jakie dane wyciągamy i co z nich widać w praktyce

AI normalizuje dane z trzech różnych formatów do jednego widoku. Konkretnie co zbieramy i z jakich pól:

• Status instalacji: online, offline, alarm. SolarEdge podaje connectionStatus przy każdym siteId, Fronius StateCode z GetInverterRealtimeData, Huawei devStatus przy każdym urządzeniu.
• Alarmy z kodami i opisami: SolarEdge ma pola alertType i alertCode, Fronius zwraca ErrorCode, Huawei podaje alarmId razem z alarmName i alarmCause. AI tłumaczy kody na zdania po polsku i grupuje alarmy według priorytetu.
• Dzienne i miesięczne uzyski: w kWh, dostępne we wszystkich trzech API. AI porównuje z tym samym okresem rok wcześniej albo z szacowaną prognozą dla lokalizacji instalacji.
• Dane stringów: napięcie, prąd i moc per string. W SolarEdge przez endpoint /site/{siteId}/equipment/{serialNumber}/data, w Huawei przez telemetrię string-level dla falowników z taką telemetrią. To pozwala AI zobaczyć, czy problem dotyczy całej instalacji, czy jednego stringa.
• Daty uruchomienia i numery seryjne: commissionDate i serialNumber w SolarEdge, dane karty urządzenia w Fronius, esnCode i installedTime w Huawei. Z tych pól AI liczy terminy gwarancji.

Jak wygląda poranek w firmie z kilkuset instalacjami: zanim i po

Przed wdrożeniem AI typowy poranek w firmie serwisującej kilkaset instalacji wyglądał tak: jedna osoba loguje się do SolarEdge, przegląda zakładkę Alerts, ważniejsze przypadki zapisuje na kartce albo w Excelu. Potem to samo w Fronius Solar.web, potem w FusionSolar. Do dziesiątej ma ręczną listę, którą trzeba jeszcze posortować i ocenić. Przy dwustu instalacjach rozsianych po trzech platformach to nie jest szybka robota, a zdarzało się, że alarm z poprzedniego wieczoru czekał do południa, bo akurat nikt nie zajrzał we właściwą zakładkę.

Z AI wygląda to inaczej. O 7:30 ktoś z biura otwiera jedno okno i widzi zestawienie za ostatnie 24 godziny ze wszystkich trzech platform razem. Przykładowy wpis w raporcie: "Instalacja Kowalczyk, Rzeszów ul. Malinowa 8, Huawei FusionSolar. Falownik offline od 03:42. Ostatni alarm przed rozłączeniem: DC Overvoltage, alarmId 30234, urządzenie SUN2000-5KTL, numer seryjny SN-HW-XXXXXXX. Gwarancja urządzenia do 2027-09-01. Klient nie był informowany. Proponowane działanie: kontakt z klientem, weryfikacja napięcia DC w stringu."

Serwisant w kwadrans przegląda całe zestawienie i decyduje: kogo dzwonić zaraz, co czeka do popołudnia, co może poczekać do końca tygodnia. Resztę planowania trasy przejmuje AI.

Jak AI odpowiada klientowi, który pyta, czemu instalacja produkuje mniej

Klient dzwoni albo pisze maila: "Od tygodnia mam mniejszy uzysk, co się dzieje?" Bez dostępu do danych serwisant może tylko powiedzieć "sprawdzimy" i potem ręcznie szukać po portalu. Nie brzmi przekonująco ani dla klienta, ani dla serwisanta.

Z AI serwisant wpisuje adres albo imię klienta, a AI odpytuje API, porównuje bieżący tydzień z analogicznym tygodniem rok wcześniej i sprawdza, czy różnica jest równomierna (cały układ słabszy, może warunki pogodowe lub zabrudzenie) czy punktowa (jeden string, jeden falownik). Jeśli dane stringów z SolarEdge pokazują, że string 2 od ośmiu dni generuje wyraźnie mniej niż string 1 przy zbliżonym nasłonecznieniu, AI przygotowuje projekt odpowiedzi dla klienta: "String 2 od dnia X wykazuje obniżoną produkcję względem stringa 1. Może to wskazywać na zacienienie, zabrudzenie modułu lub usterkę. Zalecamy wizytę kontrolną."

Klient dostaje konkretną odpowiedź z datami i danymi, nie ogólnik. U jednego z klientów taka analiza stringów pokazała, że obniżona produkcja zaczęła się dokładnie w dniu, gdy sąsiad rozbudował ogrodzenie. Zdalnie, bez danych stringowych, byśmy tego nie zobaczyli.

Zgłoszenia serwisowe, trasa przeglądów i gwarancje: co AI robi samo

Gdy AI oznaczy instalację jako wymagającą wizyty, przygotowuje szkielet zgłoszenia serwisowego. Zbiera z portalu: numer seryjny z pola serialNumber lub esnCode, model urządzenia, datę uruchomienia, aktywne alarmy z kodami, historię alarmów z ostatnich 30 dni i dane kontaktowe klienta, jeśli są w systemie. Serwisant dostaje gotowy dokument do uzupełnienia o obserwacje z wizyty. Nie musi szukać numeru seryjnego w papierowym protokole odbioru z poprzedniego roku.

Trasa przeglądów to kolejna rzecz, która dawała dużo pracy ręcznej. Przy kilkudziesięciu wizytach w miesiącu AI grupuje instalacje wymagające obecności fizycznej według adresów z pól siteAddress w SolarEdge, plantAddress w FusionSolar i adresów klientów z kart w Solar.web. Proponuje kolejność wyjazdu, żeby serwisant nie jechał dwa razy w to samo miasto w tym samym tygodniu. Można to dalej integrować z aplikacją nawigacyjną albo arkuszem zleceń.

Gwarancje. Każdy falownik ma w portalu datę uruchomienia. AI co miesiąc wypisuje listę urządzeń, których standardowy okres gwarancji producenta kończy się w ciągu najbliższych sześciu miesięcy. Dzięki temu firma zdąży ze zgłoszeniem do producenta albo dystrybutora przed upływem terminu, zamiast odkryć to po fakcie i zostać z usterką bez pokrycia gwarancyjnego.

Od czego zaczyna firma, która chce to wdrożyć

Wdrożenie nie zaczyna się od wyboru platformy AI. Zaczyna się od sprawdzenia, co już masz i czego brakuje:

• Czy masz konto instalatora w każdym portalu, z którego korzystasz? Bez konta instalatora, a nie tylko konta właściciela jednej instalacji, API daje ograniczone dane lub nie daje żadnych dla całej floty.
• Czy w Huawei FusionSolar masz włączony Northbound Interface? Sprawdzamy to w pierwszej kolejności: Settings, API Management. To częsty bloker przy pierwszym podłączeniu.
• Które dane zbierasz dziś ręcznie najczęściej: alarmy poranne, uzyski miesięczne, statusy przed kontaktem z klientem? To punkt startowy integracji.
• Czy masz pełną listę instalacji ze wszystkich platform w jednym miejscu? Jeśli nie, AI zbuduje ją z API jako pierwszy krok.

Dobrze zacząć od pilota na kilkudziesięciu instalacjach, po kilka z każdej platformy, żeby sprawdzić, czy dane spływają poprawnie i czy raport poranny zawiera to, czego faktycznie potrzebuje biuro. Dopiero potem rozwijać na całą flotę. Przy kilkuset instalacjach warto od razu zadbać o lokalny cache danych: zbierać historię uzysków do własnej bazy, żeby AI nie odpytywało API przy każdym pytaniu i nie natrafiało na rate limity producenta w środku roboczego dnia.

Jeśli chcesz sprawdzić, jak to zadziała przy twoim miksie platform i twoim modelu serwisowania, zapraszamy na bezpłatny audyt. W ciągu jednej rozmowy ustalimy, do jakich API masz już dostęp i co można uruchomić bez dużego przygotowania. Możesz też zajrzeć na realne wdrożenia, żeby zobaczyć, jak to wygląda w firmach, które już to robią.