Ugrás a fő tartalomra

A szovátai referenciarendszer

A ház, amiben mindent tesztelünk, amit árulunk. Évek óta fut, és amikor elromlik valami, megjavítjuk és leírjuk.

szenzor egyetlen napelemes integrációból
~230szenzor egyetlen napelemes integrációból
integrált gyártó egyetlen felületen
7+integrált gyártó egyetlen felületen
felhőhívás a klímavezérlésben
0felhőhívás a klímavezérlésben

A kiindulás

Egy hétköznapi szovátai ház, napelemes rendszerrel és akkumulátorral, két klímával, saját hálózattal, kamerákkal és egy tárolószerverrel. Semmi különleges — pontosan az a fajta háztartás, amire építünk.

A probléma ugyanilyen hétköznapi volt: mindennek megvolt a saját appja. Az inverter az egyikben, a klíma a másikban, a kamerák a harmadikban, a hálózat a negyedikben. Semmi nem tudott semmiről, tehát semmit nem lehetett a másik függvényében automatizálni.

A cél

Egyetlen felület mindenre, ami a házban fut. Előfizetés nélkül, szolgáltatófüggőség nélkül, kiküldött adat nélkül.

És egy kemény feltétel: minden integrációnak működnie kell internet nélkül. Ha egy eszközt csak a gyártó szerverén keresztül lehet vezérelni, vagy találunk hozzá helyi utat, vagy kicseréljük a moduljában.

Az architektúra

A Home Assistant virtuális gépként fut a ház Proxmox hostján. Mellette, külön konténerekben, a hálózati szolgáltatások. A szétválasztás nem kacérkodás: egy Home Assistant-frissítés nem hagyhatja controller nélkül a hálózatot, egy Proxmox-pillanatkép pedig percek alatt visszavon egy rosszul sikerült frissítést.

A napelemes inverter Modbuson, közvetlenül olvasható. Innen jön nagyjából 230 entitás: pillanatnyi termelés szálanként, az akkumulátor töltöttsége, külön az import és az export, EMS-mód, hőmérsékletek. Egyetlen eszköz, mégis az egész ház leggazdagabb adatforrása — és minden energetikai automatizmus alapja.

A klímák a helyi hálózaton, a saját portjukon vezéreltek, a gyártó szervere nélkül. A gyári fiókot egyszer használjuk, hogy kinyerjük az eszközkulcsot; utána a külvilággal való kapcsolat már nem kell.

A hálózati controller jelenlét-forrásként kapcsolódik be: a hálózat ismert eszközei megmondják a rendszernek, ki van otthon, anélkül hogy követő alkalmazás kellene a telefonra.

Egy valódi hibakeresés: a klíma, amelyik címeket osztogatott

Egy ponton a ház eszközei rossz hálózati címeket kezdtek kapni. Nem mind, nem mindig, és nem ugyanúgy — az a fajta hiba, amit könnyű „a hálózatra” fogni, és évekig megmagyarázatlan marad.

A forrás az egyik klíma gyári Wi-Fi-moduljának bizonyult. Saját DHCP-szervert futtatott, és a routeren beállított tartományon kívülről osztogatott címeket, két órás érvényességgel.

Ami nehezen foghatóvá teszi a hibát: a modul meghamisította a szerverazonosítót, a router címét írva bele. A hálózati controller védelme, aminek pontosan ezt kellene blokkolnia, ez alapján az azonosító alapján dönt — tehát legitim szervert látott. Bekapcsolva hagytuk, mert egy nem hamisító szerver ellen véd, itt viszont nem volt mit tennie.

A mérés a hostról küldött DHCP-lekérdezéssel történt, véletlenszerűen generált hardvercímmel. Két ajánlat a válaszban azt jelenti, hogy a forrás még él; egyetlen, a routertől, azt, hogy megoldódott. A véletlen hardvercím számít: az eszköz alapértelmezett értékével a mérés hamis negatívot adhat. Magát a forrást a hálózati interfészen figyelt DHCP-forgalom azonosítja.

A gyári reset nem oldott meg semmit — és ezt mértük, nem feltételeztük. Teljes reset és újraregisztrálás után a szerver ugyanúgy futott; csak a belső tartományszámláló mozdult el, tehát más címeket osztott, azonos érvényességgel és azonos hamisított azonosítóval.

Mindkét klíma firmware-e azonos verziójú volt, mégis csak az egyik viselkedett így. A hardvercímek gyártói előtagjai eltértek, ami eltérő hardverrevíziót jelez. A beltéri egységnek nincs hálózati interfésze, tehát a szerver csak magában a Wi-Fi-modulban futhatott.

A megoldás két részből áll. Rövid távon a fontos eszközök fix címet kaptak: egy fix címes eszköz soha nem kérdez DHCP-t, tehát a hamisítás nem éri el. Hosszú távon a gyári modult nyílt, ESPHome-alapú, felhő nélküli darab váltja — ami ugyanazzal az alkatrésszel megoldja a hálózati problémát és a gyártói fiókfüggőséget is.

Amit nem csináltunk: nem tiltottuk le az eszközt a hálózati controllerben. A tiltás a hozzáférési ponton érvényesült volna, és elvágta volna a helyi vezérlés portját is — a klíma „elérhetetlen” lett volna a rendszerben, minden magyarázó hibaüzenet nélkül. A tünet eltűnt volna, és a helyére egy nehezebben diagnosztizálható került volna.

Az eredmény

Egyetlen dashboard a napelemre, a klímára, a hálózatra és a kamerákra. Egymásra épülő automatizmusok: az akkumulátor a többletből töltődik, a bojler akkor indul, amikor nagy a termelés, a klíma pedig nem hűt üres szobákat.

És — ami a legfontosabb abból, amit árulunk — mindez kihúzott internetkábellel is működik. A távoli elérés és az értesítések vesznek el; a többi megy tovább.

Tanulságok

A gyári modul a legrosszabb alkatrész egy jó eszközben. A klímák hibátlanul működnek; a probléma a bennük lévő tíz eurós Wi-Fi-kártya volt. Azóta minden eszköznél először azt nézzük meg, mit csinál a hálózati modul, nem azt, mit ígér az adatlap.

Mérj, ne feltételezz. A gyári resetnek „meg kellett volna” oldania. Nem oldotta meg, és ezt csak az utána következő mérés mutatta ki. A feltételezés heteket vitt volna el.

A fix cím védelmi eszköz, nem csak rendrakás. Egy eszköz, amelyik soha nem kérdez, nem is kaphat rossz választ.

És amiért mindezt leírjuk: ha egy rendszer nincs dokumentálva, a tavalyi hibát jövőre újra nulláról kell kideríteni. Itt ez nem történik meg, mert minden le van írva — ezért kapod meg te is a dokumentációt átadáskor.