Hello!
Tóth Attila vagyok, a Szélessáv Alapítványtól. Ez itt a szelessavmuhely.hu oldalon megosztott, okosotthon alapú, energiahatékonyságot támogató szoftverrendszerünk eredettörténete.
Hosszú lesz. Valószínűleg sokan nem fogják végigolvasni. De nekem fontos, mert ebben a történetben nemcsak egy szoftver születése van benne, hanem több évnyi tanulás, kísérletezés, zsákutca, családi ház, fűtés, rezsi, háború, napelem, hőszivattyú, kazán, router, nyílt forráskód, és az a nagyon egyszerű emberi vágy, hogy ha már lehet valamit jobban, takarékosabban és függetlenebbül csinálni, akkor próbáljuk meg.
A projekt megvalósításában többen is segítettek. Voltak, akik szakmai munkával, voltak, akik teszteléssel, voltak, akik tanáccsal, ötlettel, vitával, vagy egyszerűen csak azzal, hogy jelezték: „ez nálam is probléma, meg tudnád oldani?” Ezért a történetben sokszor többes számban beszélek. Nem azért, mert mögötte egy nagy cég vagy fejlesztőcsapat állt volna, hanem mert a fontos döntések, felismerések és tapasztalatok sokszor közösen alakultak.
A történet valahol az orosz–ukrán háború kitörése környékén kezdődött. Vagy talán már jóval korábban, csak akkor vált belőle elhatározás.
Régóta érlelődött bennem, hogy a többgenerációs családi házunk energiaellátásán változtatni kell. El kellene hagyni a fosszilis energia használatát, vagy legalábbis erősen csökkenteni kellene. A ház fűtése addig gázkazánra épült. Működött, kiszolgált, bizonyított. Gazdasági szempontból sokáig nem is volt igazán sürgető a váltás, mert a rezsivédett gázár csapdájában én is ugyanúgy benne voltam, mint nagyon sokan mások: amíg olcsóbbnak látszik a régi rendszer, addig nehéz racionálisan megindokolni egy drága beruházást.
De a háborúval valami megváltozott.
Nemcsak a számok változtak meg, hanem a szemlélet is. Az energia egyszerre nem pusztán rezsikérdés lett, hanem kiszolgáltatottság, erkölcsi kérdés és jövőkép. Ekkor született meg bennem végleg az elhatározás: váltani kell. Ha gazdaságilag nem is térül meg azonnal, akkor is el kell indulni a fosszilis energia csökkentése felé.
Az anyagi lehetőségeim és az elektromos kapacitás korlátai miatt első lépésben csak egy kisebb, 10 kW teljesítményű hőszivattyú beszerzése jöhetett szóba. Ez nem volt akkora, hogy a ház teljes hőigényét minden körülmény között önállóan kiszolgálja.
A meglévő rendszer egy 24 kW-os kondenzációs kombi gázkazán volt, amely már több éve bizonyította, hogy bármilyen hidegben képes kifűteni a házat. Így adta magát a gondolat: a hőszivattyú legyen az elsődleges hőforrás, de ha szükséges, maradjon ott tartaléknak a gázkazán.
Papíron ez egyszerűnek hangzik. A valóságban viszont nagyon hamar kiderült, hogy az ilyen kettős hőforrású rendszerekre nem nagyon találtam kész, jól használható megoldást.
Amit találtam, az többnyire váltó üzemről szólt: vagy az egyik rendszer működik, vagy a másik. Nekem viszont ennél rugalmasabb megoldás kellett. Olyan rendszer, amellyel ki tudom próbálni a különböző üzemmódokat: mikor menjen csak a hőszivattyú, mikor a gázkazán, mikor menjenek együtt, mikor váltson egyik a másikra, és mindezt milyen paraméterek alapján tegye.
Ekkor fogalmazódott meg az első valódi fejlesztési feladat: készíteni kell egy szoftvert, amellyel a lehetséges variációkat üzemben lehet kipróbálni, és később automatizálni.
A nulláról saját okosotthon rendszert írni értelmetlennek tűnt. Már léteztek rendszerek, amelyek kezelték az eszközöket, szenzorokat, kapcsolókat, grafikonokat, eseményeket. Nekem nem ezt az alapot kellett újra feltalálnom, hanem erre kellett ráépítenem azt a speciális logikát, amely a kettős hőforrás vezérléséhez kellett.
A zárt, gyári dobozos rendszereket gyorsan elvetettük. Nem azért, mert ne lennének jók bizonyos célokra, hanem mert a mi igényünk pont az volt, amit ezek a rendszerek általában nem szeretnek: mély testreszabás, saját logika, nyílt működés, helyi vezérlés, függetlenség.
A végén két nyílt forráskódú rendszer maradt versenyben: a Home Assistant és a Domoticz.
A Home Assistant mellett szólt az elterjedtsége, a hatalmas eszköztámogatás, a dinamikus fejlesztés és a látványos, modern felület. A Domoticz ezzel szemben jóval puritánabb volt. Szűkebb támogatás, kevésbé látványos felület, néha kifejezetten csúnya megjelenés. Viszont volt egy óriási előnye: töredék hardverigény mellett is stabilan működött.
Végül a Domoticz mellett döntöttünk.
A legfontosabb érv a stabilitás volt. Ha egy Domoticz-alapú rendszer elkészül, akkor az akár évekig képes különösebb gondozás nélkül működni. Nincs heti-havi kényszerfrissítés, nincs állandó újratanulás, nincs az az érzés, hogy a rendszer saját maga is egy folyamatosan változó, karbantartandó célpont.
A Home Assistant ezzel szemben sokkal inkább egy élő, gyorsan fejlődő világ benyomását keltette. Ez lehet előny is, de nálunk kockázat volt. Egy fűtésvezérlésnél nem az a cél, hogy mindig a legújabb legyen, hanem hogy ha egyszer jól működik, akkor holnap, jövő héten és jövő télen is ugyanúgy működjön.
Kicsit olyan ez, mint a Windows és a Linux világa. A Windows szép, kényelmes, elterjedt, sok mindent kiszolgál, de cserébe állandóan frissül, változik, időnként újra kell tanulni. A Linux puritánabb, de ha jól beállítottad, akkor képes csendben, hosszú ideig megbízhatóan tenni a dolgát.
Nekünk ez kellett: egy rendszer, amit nyugodtan magára lehet hagyni.
A másik nagy döntési szempont a felhőfüggés elkerülése volt.
A Home Assistant nagyon sok eszközt támogat, köztük olyanokat is, amelyek gyártói felhőszolgáltatásokon keresztül érhetők el. Ez elsőre kényelmes, de a mi szemléletünk szerint egy fűtési, hűtési vagy épületüzemeltetési rendszer esetében megengedhetetlen kockázat.
Az ukrán konfliktus és az azt kísérő gazdasági események nagyon erősen megmutatták, mennyire kiszolgáltatottak vagyunk külső szolgáltatásoknak, embargóknak, politikai döntéseknek, ellátási láncoknak. Egyáltalán nem elképzelhetetlen, hogy egy gyártó, egy ország vagy egy szolgáltató valamilyen okból egyszer csak nem biztosítja tovább azt a felhőt, amelyen keresztül az otthonunk működik.
És akkor mi marad? Egy halom életképtelen vas.
Sok esetben még azt is nehéz kideríteni, hogy egy-egy okoseszköz felhőszolgáltatását valójában ki biztosítja. Kinek a szerverére megy az adat? Milyen joghatóság alatt működik? Mi történik, ha adatvédelmi vagy biztonsági probléma merül fel? Kihez lehet fordulni?
Számomra elfogadhatatlan biztonsági kockázatot jelent, hogy ismeretlen szerverekre kerülhetnek olyan adatok, amelyek az otthoni hálózatomhoz, eszközeimhez vagy szokásaimhoz kapcsolódnak. Különösen úgy, hogy a legtöbb otthoni telepítésben nincs külön szeparált hálózat az okoseszközöknek. Az átlagos szolgáltatói routerek erre többnyire nem is igazán alkalmasak.
Ezért lett alapelv: a rendszer lehetőleg helyben működjön, felhő nélkül, saját hálózaton belül.
Egy konkrét funkció végleg eldöntötte a kérdést: a jelenlétérzékelés.
Sok okosotthon funkcióhoz nagyon fontos tudni, hogy van-e otthon valaki. Ezt lehetne helyiségenként szenzorokkal figyelni, de ez drága, bonyolult, és nem is mindig megbízható. A mozgásérzékelő például nem látja, ha valaki nyugodtan ül és tévét néz. A fejlettebb, emberi jelenlétet érzékelő szenzorok drágák, tápellátást igényelnek, és minden helyiségbe telepíteni kellene őket.
Ehhez képest ott van valami, ami szinte mindig nálunk van: a mobiltelefon.
Ma már egy okosotthon telepítését fontolgató háztartásban szinte biztosan minden önálló családtagnak van okostelefonja. Ezek a telefonok általában csatlakoznak az otthoni wifi hálózathoz, és még inaktív állapotban is időnként életjelet adnak.
Ha tehát figyeljük, hogy a telefonok jelen vannak-e a wifi hálózaton, viszonylag olcsón és megbízhatóan következtethetünk arra, hogy van-e otthon valaki.
Ehhez viszont jól konfigurálható router kellett. Az OpenWrt ideális választásnak bizonyult. És itt jött vissza a Domoticz előnye: egy OpenWrt routeren vagy hasonló erőforrás-korlátos környezetben a Domoticz reálisan futtatható, míg a Home Assistant több gigabájtos memóriaigénye ezt a megoldást kizárta.
Így alakult ki az első nagy technológiai alapelv:
OpenWrt + Domoticz + helyi vezérlés + felhőmentes működés.
Miután eldőlt, hogy Domoticz lesz az alap, első lépésként készítettünk hozzá egy saját, a mi brandünkhöz illeszkedő CSS dizájnt.
Ennek prózai oka volt: az eredeti felület nem volt szép.
Ez persze önmagában nem lett volna baj. Egy fűtésvezérlésnél a szépség másodlagos. De ha egy rendszert másoknak is meg szeretnénk mutatni, ha azt szeretnénk, hogy ne csak mi értsük, hanem más is el tudja képzelni a saját otthonában, akkor a megjelenés igenis számít.
A Domoticz alapból inkább egy technikai vezérlőpult, mint felhasználóbarát otthoni rendszer. Nekünk viszont az volt a célunk, hogy a rendszer mögött álló bonyolultság ellenére a használata érthető és vállalható legyen.
A Domoticz önmagában alapvetően szenzorok és eszközök állapotának jelzésére, illetve vezérlésére alkalmas. A gyakorlatban azonban az eszközök használatba vétele nem mindig egy kattintás. Előkészítés, próbálkozás, kompatibilitás, kommunikációs útvonalak, firmware-ek, protokollok: ezek mind hamar előkerültek.
Hosszas kísérletezés után arra jutottunk, hogy a legmegbízhatóbb és legkezelhetőbb szisztéma a wifi kapcsolaton keresztüli MQTT kommunikáció, lehetőleg Tasmota firmware-t használó eszközökkel.
A wifi mellett több érv szólt. Kipróbált, elterjedt, jól kontrollálható vezeték nélküli kommunikációs forma. Hátránya, hogy energiaigényes, ezért elemes eszközökhöz kevésbé alkalmas. Viszont ahol van vezetékes tápellátás, ott nagyon jól használható.
A Zigbee és más okosotthon-protokollok elemes eszközöknél sokszor praktikusabbak, de a mi környezetünkben ezekkel vegyes tapasztalataink voltak. A Domoticz-Zigbee plugin használható, de erősebb hardvert igényel, gyengébb routereken nehézkesen vagy egyáltalán nem fut stabilan. Extroot, külső tároló, logolás, tárhelyfogyás, újrapárosítások, rejtélyes kapcsolatvesztések: ezek mind olyan problémák, amelyek egy fűtésvezérlés alapjainál már túl nagy kockázatot jelentenek.
A Zigbee jó és sokszor szükséges, például ablaknyitás-érzékelőknél vagy elemes hőmérőknél, de nálunk alapelv lett, hogy a rendszer kritikus működése lehetőleg ne csak ilyen eszközökön múljon.
A Tasmota ezzel szemben nyílt forráskódú, stabil, MQTT-képes firmware, amely sok eszközön futtatható. Ha egyszer jól beállítjuk, életszerű tapasztalatok szerint hosszú éveken át megbízhatóan működik.
A Tasmota-kompatibilis eszközök keresésében nagy segítség a Blakadder-féle adatbázis. A firmware-csere azonban sokszor nem kezdőknek való feladat: szétszerelés, forrasztás, soros kapcsolat, hibalehetőség, garanciavesztés. Szerencsére vannak gyártók, például az Athom, akik gyárilag Tasmotával árulnak eszközöket. Ezekkel rengeteg küzdelem megspórolható.
A fűtésvezérlés alapja a hőmérséklet. Ha nincs megbízható hőmérsékleti adat, nincs megbízható vezérlés sem.
Az első próbálkozások RF hőmérőkkel indultak. Ezek jellemzően házi időjárásállomásokhoz adott, elemes 433 MHz-es szenzorok. Egy megfelelő USB-vevővel és OpenWrt modulokkal a jelük fogható volt. Működött is, de gyorsan kiderült, hogy elemes szenzorokra nem szabad kritikus épületgépészeti funkciót alapozni.
Egy lemerült elem miatt leállhat a fűtésvezérlés, és a hétköznapi felhasználó érthető pánikhelyzetben nem feltétlenül azt fogja elsőként keresni, hogy vajon melyik hőmérőben merült le az elem.
A stabilabb megoldást végül a Wemos D1 mini és a DS18B20 hőmérő szenzor jelentette. Tasmotával, MQTT-n keresztül megbízhatóan szolgáltatta a hőmérsékleti adatokat.
Csakhogy egy D1 mini önmagában nem szép látvány. Egy kis nyáklap, rajta néhány alkatrész, mellette egy zsinóron lógó szenzor. Sérülékeny, poroláskor útban van, és nem olyan, amit szívesen kitesz az ember egy lakótérbe.
Kellett hozzá egy ház.
Így jött a 3D nyomtatás.
Addig leginkább csak hallottam róla, de úgy voltam vele: ha már kell, tanuljuk meg. Vettem egy alap 3D nyomtatót, és nekiálltam dobozt tervezni. Fontos volt, hogy a hőmérő szenzor kellően távol legyen a melegedő elektronikától, hogy az ne torzítsa a mérést.
Végül sikerült. Az oldalon megosztottam a készítés lépéseit és a 3D mintát is, hogy aki szeretne, készíthessen magának hasonlót.
Ezzel eljutottunk oda, hogy volt már stabil belső és külső hőmérsékletmérésünk, az adatok bekerültek a Domoticz rendszerbe, tárolódtak, grafikonon megjelentek, és végre lehetett valódi vezérlési logikát építeni rájuk.
A legegyszerűbb fűtési logika nagyon régi: ha hidegebb van, mint szeretnénk, kapcsoljon be a fűtés; ha elérte a célhőmérsékletet, kapcsoljon ki.
Ezt többféleképpen is meg lehet valósítani. A Domoticzban ott van például a Blockly felület, ahol húzd-és-dobd módszerrel lehet logikai szabályokat készíteni. Meglepően összetett dolgokra is alkalmas, ha az ember türelmes.
Lehet LUA vagy DzVents szkripteket írni, ami már programozói tudást igényel. És ott van a Domoticz plugin környezete is, ahol Python nyelven lehet bonyolultabb, keretrendszerbe illeszkedő logikát megvalósítani.
Mivel az alapcél nem egy egyszerű termosztát volt, hanem több hőforrás igény szerinti vezérlése, végül a plugin irányba indultam.
Ekkor jött az első fontos épületgépészeti kérdés: hogyan kommunikálok a hőforrásokkal?
A gázkazán egyszerű volt: egy száraz kontaktust fogad, mint egy hagyományos szobatermosztát. Ha zárjuk, fűt. Ha megszakítjuk, leáll.
A hőszivattyú elvileg ennél sokkal többre volt képes. Modbus kommunikáción keresztül utasításokat fogadhatott volna, és adatokat szolgáltathatott volna. Elsőre nagyon csábító volt, de hamar kiderült, hogy a megbízható dokumentáció beszerzése nehéz, sokszor lehetetlen. A Modbus ugyan szabványos protokoll, de a gyártói megvalósítások részletei nagyon eltérnek. Még azonos gyártón belül is változhatnak a parancsok és regiszterek.
Be kellett látni: nincs elég idő, pénz és erőforrás arra, hogy minden hőszivattyúhoz külön integrációt fejlesszünk és tartsunk karban.
Ezért maradtunk a legegyszerűbb, legáltalánosabb módszernél: a külső termosztát bemenet vezérlésénél.
Így született meg a virtuális termosztát gondolata. Nem a falon lévő hagyományos termosztát kapcsolja a rendszert, hanem egy szoftver, amely hőmérséklet, külső hőmérséklet, üzemmód, hőforrás-prioritás és később még sok más paraméter alapján dönt.
Az első alapelv egyszerű volt: elsősorban a hőszivattyú fűtsön. Nálam ezt különösen indokolta a szaldós napelemes rendszer. Ha van saját villamosenergia-termelés, akkor a hőszivattyú gazdaságilag és környezetileg is előnyös.
De a valóság itt is bonyolultabb volt.
Egyrészt a hőszivattyú nem volt elég nagy minden helyzetre. Másrészt a levegő-víz hőszivattyúk hatékonysága erősen függ a külső hőmérséklettől és az előremenő vízhőmérséklettől. A gyártók jellemzően +7 °C külső hőmérséklet és 35 °C előremenő mellett adják meg a szép COP értékeket. Ha kint hidegebb van, vagy magasabb előremenő kell, a hatékonyság jelentősen romolhat.
Ezért olyan vezérlés kellett, amely figyeli:
a belső hőmérsékletet,
a célhőmérsékletet,
a külső hőmérsékletet,
a hőforrások prioritását,
és azt is, hogy mekkora az eltérés a kívánt és a tényleges állapot között.
Nálam végül az lett az egyik fontos szabály, hogy ha a belső hőmérséklet legalább 0,5 °C-kal elmarad a kívánttól, akkor a gázkazán is bekapcsolhat a hőszivattyú mellé. Ez különösen az átmeneti időszakban bizonyult hasznosnak, amikor a külső hőmérséklet gyorsan változik, a padlófűtés viszont lassan reagál.
Az első téli szezon folyamatos javítgatással, kisebb-nagyobb logikai korrekciókkal telt. A végére létrejött egy működőképes virtuális termosztát, amely már képes volt kezelni a kettős hőforrást.
A padlófűtés kényelmes, de lusta.
Ez a lustaság régóta zavart. Tavasszal és ősszel különösen kellemetlen tud lenni: napközben gyorsan felmelegszik az idő, a ház is melegszik, a fűtés leáll. Este viszont a külső hőmérséklet hirtelen esik, a ház hűlni kezd, a fűtés bekapcsol, de a beton csak órák múlva adja le érezhetően a meleget.
Az eredmény: este fázunk, éjjel már jó, délelőtt pedig túlfűt a rendszer.
Korábban próbáltam felhős megoldást is, például Netatmót, amely azt ígérte, hogy az időjárás-előrejelzés és a ház tanult hőtehetetlensége alapján javítja ezt a problémát. Nálam nem vált be. Nem tudta érdemben kiküszöbölni a hőtehetetlenségből adódó kilengéseket.
Sokáig próbáltam az eltárolt hőmérsékleti adatokból, a kapcsolási állapotokból és a múltbeli viselkedésből valamilyen hőtehetetlenségi értéket számolni. Ez lett volna az elegáns megoldás. De túl sok volt a nem kontrollált tényező: szellőztetés, napsütés, több hőforrás, eltérő üzemmódok.
Végül egy egyszerűbb, de működőképesebb irány győzött.
A rendszer nem próbálja tökéletesen megtanulni a házat. Ehelyett előretekint. Megnézi, hogy a beállított időablakban – például három óra múlva – várhatóan melegebb vagy hidegebb lesz-e kint, és ennek alapján módosítja átmenetileg a célhőmérsékletet.
Ha például most 17 °C van kint, de három óra múlva 10 °C várható, akkor a rendszer tudja, hogy hamarosan nőni fog a hőigény. Ilyenkor még akkor is elkezdhet fűteni, ha a belső hőmérséklet pillanatnyilag elérte a célértéket. Reggel, amikor melegedés várható, ugyanez fordítva történik: előbb visszavesz, hogy ne fűtse túl a házat.
Ez nem tökéletes mesterséges intelligencia. Inkább egy józan, előretekintő szabályrendszer. De a gyakorlatban nagyon sokat javított a komforton. A korábbi 1–1,5 °C-os kilengések helyett nálunk jellemzően 0,5–0,7 °C körüli ingadozásra csökkent a belső hőmérséklet.
És itt kapott el igazán a gépszíj.
Nagyon büszke voltam arra, hogy sikerült kezelni a padlófűtés hőtehetetlenségi problémáját. Elkövettem azt a hibát – vagy inkább szerencsét –, hogy ezt többeknek elmeséltem.
Köztük olyanoknak is, akiknél ugyanez probléma volt.
A beszélgetésekből előbb érdeklődés lett, aztán konkrét kérés: „Csinálnál nekem is ilyet?”
Itt dőlt el a szoftver sorsa. Ez már nem csak az én magán játékszerem volt. Ha másnál is hasznos, akkor legyen közkincs.
Mivel az egész rendszer nyílt forráskódú alapokra épült, természetes volt, hogy az általam készített rész is nyílt és ingyenes legyen.
Innentől minden új fejlesztésnél arra törekedtem, hogy ne csak az én házamra legyen jó, hanem minél többféle valós rendszerhez igazítható legyen. A fűtési-hűtési rendszerek ugyanis majdnem olyan egyediek, mint a DNS: nincs két teljesen egyforma. Más a ház, más a kazán, más a hőszivattyú, más a hidraulika, mások a lakói szokások.
Ezért lett a rendszer első ránézésre talán bonyolult. Nem azért, mert szerettem volna túlbonyolítani, hanem mert a valóság is bonyolult.
A következő nagy lépés a használati melegvíz, vagyis a HMV készítés integrálása volt.
Ezt elvileg rá lehetne hagyni a hőforrások gyári vezérlésére. De akkor elveszítjük azt a kontrollt, ami miatt az egész rendszert elkezdtük építeni: mikor melyik hőforrás dolgozzon, milyen hőmérsékletre, milyen prioritással, milyen napszakban, milyen energiaforrás mellett.
Nálam eredetileg egy 300 literes tartály és egy 40 csöves napkollektoros rendszer szolgálta a melegvizet, gázkazánnal sorba kötve. Ez tíz évig jól működött. A napkollektor nyáron nagyon hatékony volt, de amikor a tartály elérte a 80 °C körüli hőmérsékletet, a többi napenergia már elveszett.
Amikor a napelemes rendszer fejlesztése került napirendre, végül arra jutottam, hogy a tető korlátozott felületét jobban használom ki napelemekkel. A napkollektor helyére napelem került, a HMV készítést pedig a hőszivattyúval kellett megoldani.
Ez újabb kísérletekhez vezetett: külső hőcserélő, nagyobb hőcserélő, belső spirál, zuhanykomfort, felfűtési idő, családi béke. A technikai megoldások között végül sokszor nem az elméletileg legszebb, hanem a hétköznapokban legélhetőbb döntés győz.
A HMV vezérlésben fontos gondolat lett, hogy ha van mozgástér az időzítésben, akkor a melegvizet lehetőleg akkor készítsük, amikor a hőszivattyú a legjobb hatásfokkal dolgozik: a nap legmelegebb időszakában.
Ezért készült olyan algoritmus, amelyben van egy minimum hőmérséklet, amelyet mindenképpen tartani kell, és egy magasabb, optimalizált célhőmérséklet, amelyet kedvezőbb időszakban érhet el a rendszer.
Később ehhez kapcsolódott a napelemes túltermelés figyelembevétele is: ha van elegendő többlettermelés, akkor akár magasabb hőmérsékletre is fel lehet fűteni a tartályt, ezzel helyben hasznosítva az energiát.
A HMV vezérlésnél hamar előjött a prioritás kérdése. Ha a hőszivattyú éppen 1–2 órán át melegvizet készít, akkor közben nem fűti a házat. Nálam ez azt eredményezhette, hogy a lakás hűlni kezdett, majd bekapcsolt a gázkazán is – éppen az, amit el akartam kerülni.
Ezért a rendszerben állítható lett a HMV prioritása:
kaphat abszolút elsőbbséget,
alárendelhető a fűtésnek,
vagy időszakosan váltogathat a két funkció között.
Később bekerült az elektromos fűtőpatron vezérlése is. Ez különösen akkor hasznos, ha a hőszivattyú hidegben már rossz hatásfokkal készítene magas hőmérsékletű melegvizet, vagy ha fertőtlenítési hőmérsékletet kell elérni.
A tartály fertőtlenítése külön funkció lett: beállítható, hogy a hét adott napján és adott órájában a rendszer magasabb hőmérsékletre fűtse a tartályt, ezzel csökkentve a ritkán használt rendszerekben előforduló baktériumkockázatot.
A fűtésben és HMV-ben is megjelent a takarékos és normál üzemmód.
Régi, jól ismert megoldás, hogy naptár alapján állítjuk a célhőmérsékleteket: hétköznap, hétvége, nappal, éjszaka. Ez sokszor működik, de a valós élet ritkán ilyen szabályos. Otthoni munkavégzés, váratlan távozás, hosszabb távollét, korábbi hazaérkezés – ezek mind felborítják a naptárt.
Ezért lett fontos a jelenlét alapú vezérlés.
Ha az utolsó figyelt mobiltelefon is eltűnik a wifi hálózatról, a rendszer takarékos üzemmódba kapcsolhat. Ha valaki visszatér, visszaáll normál üzemre.
Ez különösen radiátoros rendszereknél hatékony, mert azok gyorsan reagálnak. Ilyenkor teljesen életszerű, hogy távollétben alacsonyabb célhőmérsékletet tartunk, majd hazaérkezéskor rövid idő alatt visszafűtjük a helyiséget.
A jelenlétérzékeléshez OpenWrt oldalon külön megoldások készültek: wifi kapcsolódás figyelése, MAC cím alapú azonosítás, ping alapú érzékelés, sőt OpenWrt-s jeltovábbítók bevonása is, hogy nagyobb házakban ne csak a fő routerre csatlakozó eszközöket lássuk.
A zónavezérlés volt a következő nagy ugrás.
Egy ház soha nem egyformán melegszik. A déli, nagy üvegfelületű nappali napsütésben gyorsan felmelegszik, miközben az északi szobák hidegek maradhatnak. Ha a termosztát a nappaliban van, lekapcsolja a fűtést, és az északi helyiségek fáznak. Ha az északi oldalhoz igazítjuk a rendszert, napsütésben túlfűtjük a déli helyiségeket.
Erre való a zónavezérlés.
A gyakorlatban ez annyit jelent, hogy minden zóna saját virtuális termosztátlogikát kap. A rendszer zónánként figyeli a hőmérsékletet, célértéket, nyitásérzékelőt, szelepet, hűtési vagy fűtési igényt.
Először 6, majd később 12 zóna vezérlését valósítottam meg. A hat sok helyen kevésnek bizonyult.
Ezzel együtt bekerült a hűtés vezérlése, a pufferkezelés, a motoros keverőszelepek kezelése, a fűtési és hűtési előremenő hőmérsékletek szabályozása, valamint a harmatpont alapján történő felület-hűtési védelem is.
A rendszer ekkorra már nagyon sokat tudott. Cserébe nagyon bonyolult lett.
A felülethűtés egyik legnagyobb kockázata a párakicsapódás.
Egy hőszivattyú képes nagyon hideg vizet előállítani. Ha ez a hideg víz magas páratartalmú helyiségben, falban, mennyezetben vagy padlóban fut, akkor a csövek, felületek környezetében kicsapódhat a pára. Ez nemcsak műszaki probléma, hanem egészségügyi kockázat is lehet penészesedés miatt.
Ha olyan hőmérőket használunk, amelyek páratartalmat is mérnek, akkor kiszámítható az adott helyiség harmatpontja. A rendszer ennek alapján képes úgy szabályozni a keverőszelepet és az előremenő vízhőmérsékletet, hogy az mindig biztonságos távolságban maradjon a párakicsapódási határtól.
Így a felülethűtés hatásfoka maximalizálható, miközben csökkenthető a káros kondenzáció veszélye.
A hűtésnél és fűtésnél is fontos kérdés, hogy mi történjen, ha valaki nyitva hagyja az ablakot.
Nyáron különösen gyakori, hogy egy hűtött helyiség ablakát vagy ajtaját nyitva hagyják szellőztetés miatt, miközben a rendszer tovább hűtene. Ez pazarlás. Ezért bekerült a nyitásérzékelők kezelése.
Zónánként egy vagy több nyitásérzékelő állítható be. Ha bármelyik nyitott állapotot jelez, az adott zóna fűtési vagy hűtési igénye letiltható.
A gyakorlat itt is megtanított egy fontos leckére: ha egy Zigbee nyitásérzékelő nyitott állapotot jelent, majd utána nem küld újabb életjelet, akkor nem biztos, hogy tényleg nyitva maradt az ablak. Lehet, hogy csak az eszköz takarékoskodik vagy elvesztette a kapcsolatot.
Ezért a rendszerben időablakot kellett alkalmazni: ha túl régi az adat, a rendszer inkább zártnak tekinti az ablakot. Jobb néha feleslegesen fűteni vagy hűteni, mint teljesen leállítani egy zónát egy bizonytalan szenzor miatt.
A valós rendszerek újabb és újabb igényeket hoztak.
Megjelent a puffertartály kezelése. Ez különösen vegyes tüzelésű rendszereknél vagy hőszivattyús rendszereknél lehet fontos, ahol a puffer hőakkumulátorként működik.
Bekerültek az eszközönként állítható kapcsolási késleltetések is. Egy hőforrás leállításakor sokszor érdemes még pár percig keringtetni a vizet, vagy nyitva hagyni egy motoros szelepet, hogy a rendszer biztonságosan és hatékonyan álljon le.
Később megszületett a virtuális hidraulikus váltó funkció is. Ennek lényege, hogy ha már csak egyetlen zóna kér fűtést, és ez túl kicsi hőigényt jelentene a hőforrás stabil működéséhez, akkor a rendszer egy tartalék zónát is megnyithat. Ez nem tökéletes megoldás, mert némi túlfűtést okozhat, de sok esetben olcsóbb és egyszerűbb, mint a hidraulikai rendszer fizikai átalakítása.
A Domoticz plugin környezetének van egy fontos korlátja: csak korlátozott számú beviteli paramétermezőt biztosít. A kezdeti rendszerben ez még elég volt. Egy külső hőmérő, egy belső hőmérő, két hőforrás, egy keringtető, néhány alapparaméter.
A 12 zóna, a nyitásérzékelők, szelepek, keverőszelepek, HMV, puffer, patron, jelenlét és egyéb funkciók mellett azonban ez teljesen kezelhetetlenné vált.
Prefixeket kellett bevezetni. Egy paramétermezőben vesszővel elválasztott, betűjelekkel ellátott idx-ek sorakoztak. Gépi logikával értelmezhető volt, de emberi szemmel egyre kevésbé.
Ekkor nyilvánvalóvá vált: kell egy saját konfigurációs felület.
A Domoticz szerencsére támogat HTML template oldalakat, így elkezdtem egy egyedi kezelőfelületet készíteni. A cél az volt, hogy a rendszer logikája látható legyen, az eszközök húzd-és-dobd módszerrel rendelhetők legyenek a megfelelő blokkokhoz, és a grafikonokon keresztül a működés is visszakövethető legyen.
Ez hatalmas munka volt, de nélküle a rendszer a saját bonyolultsága miatt használhatatlanná vált volna.
Ahogy a rendszer terjedt a valós használatban, újabb igények jelentek meg.
Volt, aki nem akarta mobilról állítani a helyiség hőmérsékletét, hanem falikonzolt szeretett volna. Így bekerült néhány Zigbee alapú fali kezelő támogatása.
Aztán jöttek a távvezérelhető radiátorszelepek. Ezek nem egyszerű nyit-zár eszközök, hanem célhőmérséklet alapján dolgoznak. Ráadásul közvetlenül a radiátoron mérnek, ahol a hőmérséklet sokszor köszönőviszonyban sincs a helyiség közepén mérhető értékkel. Hosszas kísérletezés után sikerült használható logikát kialakítani hozzájuk.
Ez különösen távfűtéses vagy radiátoros rendszereknél nyitott új lehetőséget. Ott a hőforrás nem nálunk van, de a radiátorokon keresztül mégis lehet jelenlétalapú, zónás takarékosságot elérni.
Ezután jöttek a klímák.
A modern klímák nagy része gyártói felhőn keresztül vezérelhető, helyi hozzáférést viszont ritkán adnak. Ez nálunk továbbra sem volt elfogadható irány. Ezért egyszerűbb, de univerzálisabb megoldást választottunk: IR jeladóval emuláljuk a távirányítót.
Így szinte bármilyen klíma vezérelhető, feltéve, hogy az IR jeladó rálát a készülékre. Ehhez külön Domoticz plugin is készült.
A fűtés-hűtés mellett párhuzamosan más projektek is készültek. Ezek közül az egyik legfontosabb a redőnyvezérlés lett.
Elsőre egyszerűnek tűnik: ha meleg van, engedjük le; ha hideg van és süt a nap, húzzuk fel; ha sötét van, engedjük le. A valóságban azonban gyorsan kiderült, hogy ez is összetett kérdés.
Más a cél télen és nyáron. Más, ha otthon vagyunk, és más, ha nem. Más, ha bent hidegebb van a kívántnál, és más, ha már túl meleg van. Más, ha kint hidegebb van, mint bent, és más, ha melegebb. Más, ha kevés a fény, normál fény van vagy erős napsütés.
Végül egy 36 elemű mátrix lett a megoldás alapja.
Három fő belső hőmérsékleti állapot:
a minimum alatt,
a normál tartományban,
a maximum felett.
Ezeken belül két külső-belső viszony:
kint hidegebb van, mint bent,
kint melegebb van, mint bent.
Ezeken belül három fényállapot:
sötét vagy kevés fény,
normál fény,
erős napsütés.
És mindez jelenléttel vagy jelenlét nélkül.
Ha nincs otthon senki, az energiahatékonyság élvez elsőbbséget. Ha otthon vagyunk, akkor az emberi komfort is belép: kell a természetes fény, kell a szellőzés, nem élhetünk egy automatikusan sötétített dobozban csak azért, hogy megspóroljunk néhány wattot.
A redőnyvezérléshez is külön kezelőfelület készült, csúszkákkal, grafikonokkal, aktuális állapot kiemeléssel, hogy a rendszer finomhangolható legyen.
A másik fontos mellékprojekt az öntözésvezérlés.
Itt az alapgondolat egyszerű: ne csak időzítő alapján öntözzünk, hanem vegyük figyelembe a talajnedvességet és az időjárás-előrejelzést is.
Ha a következő 24 órában elegendő eső várható, akkor ne indítsuk el az öntözést akkor sem, ha a pillanatnyi talajnedvesség alapján indokoltnak tűnne. Ez talajnedvességmérővel és anélkül is használható, mert az előretekintés önmagában is értékes.
A cél itt is ugyanaz: kevesebb pazarlás, okosabb működés, helyi kontroll.
Amikor a rendszer már túlnőtt a saját házamon, nevet kellett adni neki.
A Szélessáv Alapítvány égisze alatt szerettem volna publikálni. Minden része ingyenes, nyílt forráskódú szoftver. Sokat gondolkodtam a néven, végül nem találtam jobbat, mint:
Szélessáv Okos Otthon rendszer.
A szelessavmuhely.hu domain már korábbról megvolt. Régen volt az alapítványnak egy Szélessáv Műhely nevű kezdeményezése, amelynek célja az volt, hogy a szélessáv terjedésében érdekelteket egyfajta műhelymunkára összehozza. Ez mára inkább emlék, de a név és a domain adott volt.
Így lett a Szélessáv Műhely az a hely, ahol ezt a rendszert elindítottuk.
Még nem tudom pontosan, hova tartunk. Egyelőre annyit tudok, hogy van egy komplex, nyílt forráskódú szoftverrendszer, amely segíthet energiát megtakarítani a háztartások mindennapi üzemeltetésében.
Nem akarom megváltani a világot.
De ha lehet, szeretnék egy kicsit jobbá tenni valamit abban, amihez értek.
Köszönöm mindenkinek, aki szakmai munkával, teszteléssel, tanáccsal, türelemmel vagy kritikával segítette ezt az utat. Velük együtt jutottunk el idáig, az 1.0 verzióig.
Folytatjuk…
