Hogyan készült.

Inverter

Fronius Primo 5.0-1, Datamanager 2.0 adatgyűjtővel

Modulok

16 panel két füzérben — délkeletre 10, délnyugatra 6

Névleges

5,12 kWp DC · 5 000 W AC · egyfázisú betáplálás

Üzembe

2019. július · HMKE-szerződéssel

A monitorozás évekig a gyártó felhőszolgáltatásán ment. Ott viszont az adat mögé nem lehet benézni, és nem lehet összevetni a mérőóra adatával — pedig, mint kiderült, pont az összevetés a lényeg.

1. Az inverter helyi archívuma

A Datamanager a lakás hálózatán kiszolgál egy JSON API-t. Ötperces bontásban adja a teljesítményt, a termelt energiát, az inverter hőmérsékletét, az AC feszültséget, és — ez a lényeg — füzérenként a DC áramot és feszültséget.

GET /solar_api/v1/GetArchiveData.cgi
    ?Scope=Device&DeviceClass=Inverter&DeviceId=1
    &StartDate=09.06.2024&EndDate=23.06.2024&Channel=…

Két buktató. A Scope=System hívás minden 15 napos tartományon Status.Code 255 hibával elszáll, míg a Scope=Device ugyanarra az adatra hibátlanul válaszol. A válaszban pedig az idősor kulcsai nem időbélyegek, hanem másodpercek a tartomány kezdetétől.

Eredmény: 129 964 ötperces rekord és 259 928 füzérmérés, 2024 júniusától. Ennél korábbra a készülék nem őriz adatot.

2. Az elosztói mérőadat

Az ügyfélportál egy SAP OData szolgáltatás mögött ül. A portál felületén a mérési csatornák listája elsőre üresnek látszik. Nem hiba: a csatornák kulcsa a (csatorna, időfelbontás, szakág) hármas, tehát amíg nincs kiválasztva időfelbontás, nincs mit felkínálni.

Erre a tulajdonos jött rá, nem az ügynök — az ügynök addigra már „portálhibát” állapított meg. Az API válasza utólag igazolta a tulajdonost.

Eredmény: 134 894 negyedóra, 2022 októberétől.

3. Régi e-mail mellékletek

Kiderült, hogy évekre visszamenőleg érkeztek xlsx-mellékletek ugyanezekkel az adatokkal: 198 696 mért érték. Ez első ránézésre redundáns másolatnak tűnt. Nem az volt.

A betöltött hálózati adat minden formai ellenőrzésen átment. Minden napra megvolt mind a 96 negyedóra, nem volt hiányzó sor, nem volt típushiba. Ettől függetlenül 2023 első felében 151 nap adata csupa nulla volt, és 2024 decemberében további 22 napé.

Az ok egyszerű, a következménye nem: a mérőoldal a „nincs adat” állapotot üres mezővel küldi, amiből a betöltő nullát csinál. A nulla pedig legitim érték — nem hiányzik, nem gyanús, nem dob hibát. Egy lakott házban viszont nincs olyan negyedóra, amelyben egyszerre nulla a vételezés és a betáplálás: 1410 napból 1357-en egyetlen ilyen negyedóra sincs.

Utólag ellenőrizve az elosztónál sincs meg ez az adat: a 2023 márciusi közvetlen lekérdezés 768 negyedórára 768 üres értéket adott vissza, míg a kontroll-hónap teljesen kitöltött volt. Az e-mailes archívum tehát nem másodpéldány, hanem az egyetlen fennmaradt forrás.

A mérőoldali táblában volt egy ts_utc nevű oszlop. Nem UTC-t tartalmazott, hanem helyi időt. A helyi idő oszlopa pedig ebből készült, még egyszer ráadva az eltolást — vagyis duplán csúszott.

A bizonyítás nem feltevésből ment, hanem mérésből. A napi görbe súlypontja a két forrás saját időbélyege szerint:

Nyáron két óra, télen egy. Ha egy elrontott konstans okozná, a kettő egyforma lenne. Így viszont csak egy dolog lehet: nyári időszámítás. A javítás ezért nem fix eltolás volt, hanem valódi időzóna-konverzió, a DST-átmenetek kezelésével — tavasszal 92 negyedóra, ősszel 100, és ősszel a helyi bélyeg kétértelmű, amit a fájlon belüli sorrend old fel.

A termelési görbe súlypontja egész évben 10,10 h maradt. Budapesten (k. h. 19,05°, napdél ~10:44 UTC) egy délkelet-túlsúlyos mezőnél pontosan ennyi — az inverter bélyege tehát valóban UTC volt. Egy forrás jó, a másik rossz: ezt csak úgy lehetett eldönteni, hogy volt mihez hasonlítani.

Akkumulátor nélkül minden megtermelt kilowattóra vagy itthon fogy el, vagy kimegy a hálózatra. Tehát termelés = önfogyasztás + betáplálás, kivétel nincs.

Az adatbázisban ez nem állt: a tárolt önfogyasztás és a betáplálás összege 18,6%-kal meghaladta a mért termelést. Körülbelül 1 900 kilowattórányi energia, ami nem létezett.

A kérdés az volt, melyik oldal a hibás — a mérés vagy a származtatás. Három próba döntötte el:

• a Fronius adatából a termelés kétféle úton számolva 10 452 és 10 434 kWh — 0,2%-on belül egyeznek;
• 361 érdemi termelésű napból egyetlen egyen sem haladta meg a napi betáplálás a napi termelést;
• a betáplálást a számla is igazolja, −2,7%-on belül.

A mérés tehát jó volt, a származtatás rossz — és az ok ugyanaz a csúszó óra: a negyedórás párosítás rossz időpontokat kötött össze. A javítás után:

Az utolsó sor nem érte el a célt — a cél ezrelék volt, az eredmény 5,3%. A maradék 92 kWh többlet az egész időszakra mérési zaj és a két óra apró eltérése. Ezt a lapot azért írjuk, hogy az ilyesmi is szerepeljen rajta, ne csak a sikeres sorok.

A dokumentáció 4,48 kWp-ot mondott, az adatbázis 5,12-t. A különbség 14%, ami minden fajlagos számot eltol. Papír helyett az inverter DC-mérése döntötte el.

Először a panelszám. Soros kapcsolásnál a feszültségek összeadódnak, tehát a füzér feszültsége elárulja, hány panel van benne:

Aztán a panel teljesítménye. A mért DC-csúcs elosztva a panelszámmal 295, illetve 313 W panelenként. Egy 280 W-os panel 313 W-ot adna — az +12% a névleges fölött, ilyen nincs. Egy 320 W-osnál ez 98%, ami hideg, tiszta napon normális.

Ráadásul felosztástól függetlenül is: a két füzér saját csúcsa önmagában 2 952 + 1 878 = 4 830 W, ami már több, mint 4 480. A rendszer 16 × 320 W = 5 120 Wp.

Mellékeredmény: 2019-es telepítésnél a szokásos évi ~0,5%-os öregedéssel ma ~307 W-os panelcsúcsot várnánk. A DNy füzér 313-at hozott — a panelek egészségesek.

Sokáig minden betöltés kézi volt. Ma két csatorna megy magától.

Inverter, ötpercenként

A szerver nem látja az invertert — az a lakás belső hálózatán van. Ezért a letöltő a helyszíni gépen fut: megkérdezi a szervertől, meddig van adata, letölti a hiányzó ablakot, és nyersen, gzippelve feltölti egy hitelesített végpontra. Az átfedés szándékos: a betöltés idempotens, tehát az ismétlés ingyen van, a hiány viszont nem.

Éjszaka az adatgyűjtő nem érhető el, mert az inverter DC oldaláról kap tápot. Ez nem hiba — a szkript ilyenkor csendben kilép.

Mérőóra, naponta

Az elosztó portálján beállított ütemezett export minden reggel küld egy xlsx-et, 7 napra visszamenőleg. A szerver óránként megnézi a postafiókot, kiszedi a mellékletet, elteszi nyersen, betölti — és csak sikeres betöltés után teszi olvasottá.

Minden beérkező nyers fájl megmarad, SHA-256 alapú azonosítással: ugyanaz a fájl kétszer nem dolgozódik fel, de a tény naplózva van. Amit egyszer megszereztünk, azt nem veszítjük el azért, mert a feldolgozója később hibásnak bizonyul.

A kedvezményes lakossági ár évi 2523 kWh-ra jár. Hogy pontosan hogyan, azt a számlák árulták el: naptári napokra arányosítva, augusztus 1-jei fordulóval, miközben az elszámolási időszak a mérő évfordulójához igazodik. A számla ezért kettévágja a saját időszakát, és mind a négy sávhatár kijön a képletből:

A másik felismerés a szaldózásé: a számlázott mennyiség a két mérőregiszter különbsége — és nemcsak az energiadíj, hanem a rendszerhasználati díjak is erre mennek. A szaldó az elszámolási évre nettóz, nem a keretév szerint; az augusztusi vágás csak a keret nagyságát adja. A betáplálás tehát visszaad a keretbe, és ettől lesz a kWh ára útfüggő — nem lehet egy szorzással számolni.

A modell próbája: ahol az adat teljes (a 2024/25-ös számla, nulla hiányos nap), a számított összeg 355 428 Ft a számla 356 224 Ft-jával szemben — −0,2%, a sávozással együtt. A következő évnél −5%, és az eltérés teljes egészében a 9 hiányos napra vezethető vissza.

Van egy nyilvános és egy privát nézet. A publikus egy befagyasztott bemutató, rögzített mintanappal; a privát az élő, ötperces adatot is mutatja, passkey-vel védve.

Az első változatban a rajzoló kód másolatban élt a két lapon. A következmény megjósolható: ami az egyikre bekerült, a másikra nem, és a privát oldal — pont az, amelyiket a tulajdonos naponta nézi — lett a szegényebb.

A mostani felépítésben egy viz.js tartja a diagramokat és egy panels.js a kész szakaszokat; mindkét lap ugyanezeket hívja, csak más tartóelemeket ad nekik. A paritás így szerkezetből következik, nem fegyelemből.

A publikus oldal egyetlen adatbázis-lekérdezést sem futtat: egy generáló folyamat statikus JSON-fájlokat ír, a lap azokat olvassa. Ami hiányos, az nem nullaként jelenik meg, hanem hiányként — a diagram inkább szakadjon meg, mint hogy hazudjon.

Egy apróság a végéről: a szerver serialize_precision beállítása miatt a JSON teljes bináris pontossággal írta a lebegőpontos számokat (6.860000000000000319…). Egy sor javítás után a napi adatfájl 380 kB-ról 152 kB-ra csökkent, változatlan számértékekkel.

• Az őszi óraátállítás négy negyedórája régebben elveszett egy kulcsütközés miatt. Évi négy negyedóra, az adatbázisból már nem hozható vissza.
• A P1 port. A mérőórának van egy felhasználói adatkimenete, ami 10 másodpercenként ad fázisonkénti feszültséget és áramot is. Ezzel a hálózati oldal ugyanolyan élő lenne, mint az inverteres — és látnánk, mikor tolja fel a betáplálás a hálózati feszültséget.
• A 2018–2024-es számlák még nincsenek betöltve, tehát a költségmodell két évre van igazolva, nem hétre.
• A meddő energia gyűlik, de még nem kezdünk vele semmit.

A betöltőket, az adatbázis-sémát, az összesítőket, a felületet és ezt a lapot AI-ügynökök írták. A hibákat is ők találták meg — de nem elsőre, és nem maguktól.

• A 151 néma nap átment a formai ellenőrzésen. Csak egy független forrás mutatta meg.
• A csúszó óra egy évig bent volt, mert a napi összegeket nem rontotta el.
• A portál „hibáját” az ügynök állapította meg — tévesen. A tulajdonosnak volt igaza.
• Az egyik ügynök megtagadta a betöltést, amikor az adat nem stimmelt az elvárttal. Ez mentette meg az évek óta tárolt adatot.

Ami emberi döntés maradt: a hálózati megfelelőséget érintő beállítások, a plombához tartozó minden lépés, és minden olyan változtatás, ami a fiókban vagy a szerződésben tartós nyomot hagy. Az inverteren az ügynökök kizárólag olvastak.