Legutóbb odáig jutottam, hogy elmeséltem hogyan jutottam arra a következtetésre, hogy a Home Assistant lesz ami a ház 2 körös fűtési rendszerét okosan fogja majd vezérelni. Az építőkockákat felsorolva megemlítettem azt is, hogy maga a thermostat komponens lesz a lényeg, de ez még nem elég okos / kényelmes önmagában.

Az elmúlt egy évben sok minden történt ezzel az ötlettel. Ez az eddigi legolvasottabb bejegyzésem - na jó, 70 egyedi látogatótól nem fordul meg a világ, de kis pénz kis foci - szóval ideje papírra vetnem eddigi tapasztalataimat...

Korábban már esett szó a 433 MHz-en kommunikáló eszközökről és az MQTT-ről is. Lássuk hogy találkozik ez a kettő.

Rapsberry Pi megoldás

Kezdjük kicsit távolabbról: a pilight-ot már korábbi bejegyzésben említettem, itt is ez lesz a megoldás egyik alapköve. Ugyanis a pilight-ot alkotó nagyszerű kollégák sok sok munkát elvégeztek már, amit nem kell újra megcsinálni. Ha sima Arduino alapokon gondolkodunk, akkor közvetlenül nem lehet az egész jelfeldolgozó programkódot átültetni ide, mert azért az Arduino (pl Uno) nagyon sok korlátot jelent. (Hogy csak a legalapvetőbbet említsem: 2kB RAM.) Én is ezért választottam azt a megoldást az Arduino programomban, hogy a kódból a nekem feltétlen szükséges részleteket emeltem át, így a libem belefért egy UNO-ba bőven.

Előző bejegyzésemben meséltem arról, hogy a MiLight nevű izzók hogy is működnek. Szóba került a rádiós kommunikáció, illetve a Wifi-re kapcsolódó MiLight eszköz is. Ahol abbahagytam viszont a saját Wifi-s eszköz volt, lássuk hát mi is ez...

Otthonokosítás témában előkelő helyen szokott szerepelni a fények/világítás okos használata. Erre ad egyfajta megoldást a MiLight nevű termékcsalád.

Az előző bejegyzésben röviden leírtam hogyan lehet információt begyűjteni a Home Assistant rendszerében. Ha nem bináris az infó, akkor bizony a beérkező adatok - leginkább a mérés pontossága/pontatlansága miatt - gyakran ugrálnak az utolsó számjegyet nézve.

Ez az emberi szemnek kicsit zavaró, de ennél nagyobb gondot is tud okozni: a fenti képen egy hőmérő adatai szerepelnek, ahol zöldre van "satírozva" a grafikon, ott bizony beindult a fűtés, méghozzá a lefelé mutató tüskék miatt. (A fűtéssel kapcsolatos problémák kiküszöbölésére a szűrőkön kívül van más módszer is, erről majd később.) Ennek a problémának a kiküszöbölésére találták ki a szűrőket a HA-ban.

A Home Assistant-ról  már esett szó. Most leírom hogyan lehet szenzorokat felvenni benne. (Természetesen a configuration.yaml fájlban kell ezeket konfigurálni.) Jellemezően MQTT-n keresztül szokott érkezni az infó, ezeknek a feldolgozására kellenek a szenzorok. Több fajtája szenzor is van:

Az okosotthonosításról már sokan sokat írtak, valószínűleg ez a blog sem fogja megváltani a világot, de ez nem is célom. Nekem kezdetben sok 433 MHz-es konnektoraljzatom volt (sőt még van is), gondoltam ezek lesznek majd az okosítás alapkövei. Ám annak a technológiának vannak előnyei és hátrányai is:
- pro: egyszerű, könnyen elérhető alkatrészek ezek, kézbe fogható távirányítója azonnal intézkedik, mégsem merül rohamtempóban a benne lévő elem.
- con: nincs egységes protokoll, minden gyártó kitalálja a saját üzenetformátumát, 1-1 márkának limitált hogy hány készüléket lehet vele irányítani (3-4-8-24 per távirányító) és ami a legfőbb probléma: nem lehet tudni, hogy elérhető-e az aljzat, sőt arról sem tudunk semmit, hogy a kért művelet végbement-e. (Nyilván ha látja az ember hogy világos/sötét/hangzavar/csönd/hideg/meleg lett, az visszajelzés, de ez központilag nem derül ki sehogy.) Ennek a rendszernek a jellemzője, hogy az egyes eszközök vagy csak adni, vagy csak venni tudnak jeleket, így visszajelzésről álmodni sem lehet.

Wifi - ESP8266

Ennek a technológiának jó alternatívája a Sonoff névre hallgató termékcsalád. (Linket direkt nem rakok, akit érdekel majd rákeres.) Ez tulajdonképpen egy nyílt forrású HW, amivel reléket lehet kapcsolgatni, rajtuk keresztül pedig "akármit". Van ebből is konnektoraljzat kivitelű, de akad fixen beépíthető is, 1-2-4 kört is lehet velük kapcsolgatni, sőt olyan is van, ami tud 433 MHz jeleket is figyelni.

Nekem egy nagy problémám van a rendszerrel: ami SW-t adnak hozzá. Ha a saját programját használja az ember, akkor minden utasítás először kirohan a netre, egy ázsiai szerverre. Ez nekem no-go! Szerencsére erre van több megoldás is, mivel a HW jól ismert alkotóelemekből épül fel: ESP8266-os csip van bennük (többnyire) és már sokan hekkelték meg. Egész pontosan ez annyit jelent, hogy a rajta futó programot le lehet cserélni nyílt forrásúra. Én ebből kettőt próbáltam ki, az ESPEasy és a Sonoff-Tasmota nevűket. A második nekem szimpatikusabb volt, így azt használom inkább.

Van olyan Sonoff eszköz, amit szétszedés nélkül lehet újraprogramozni Tasmota SW-re, de amit nem, azt is viszonylag kevés forrasztással lehet átnevelni. Ha meg már egyszer felment az eszközre a custom firmware, utána nem kell tovább mókolni pákával.

Ha az ember Wemos D1 mini eszközt rendel a kínai barátaitól, nos arra is felmegy gond nélkül a SW, sőt számtalan érzékelőt/relét/akármit is rá lehet kötni. Vezérlése pedig MQTT-n keresztül könnyedén és megbízhatóan megy. Home assistant-tal sem gond összehangolni a cumót. Fogok még erről írni...

Egy okosotthon projektnek az alapja, hogy a különböző részegységek egymással tudjanak kommunikálni valahogy. Erre több platform is az MQTT nevű protokollt használja, amit röviden bemutatni próbálok most.

Busz - már itt is

Ha valakinek van némi jártassága Java-ban, netán találkozott már JMS-sel, annak ez szinte primitívnek fog tűnni. Sima publish/subscribe elven működő üzenetküldő szolgáltatással van dolgunk.

Az MQTT-t - a wikipedia szerint - 1999-ben kezdték fejleszteni olyan céllal, hogy beágyazott rendszerek tudjanak egymással infót cserélni. Message Queuing Telemetry Transport, azaz telemetrikus adatokat lehet üzengetni - legalábbis a tervezők eredeti szándéka szerint, de szerencsére nem csak versenyautókban fellépő g-erők közlekedhetnek ezen a buszon.

A rendszernek van egy központi egysége, amit brókernek hívnak. Ő tulajdonképpen csak biztosít egy végtelen hosszú papírlapot, ahova bárki bármit felírhat - kis túlzással. Hozzá csatlakoznak a kliensek, akik vagy üzennek, vagy üzeneteket várnak, vagy mindkettőt egyszerre. Minden üzenet egy bizonyos topic-ra érkezik (lefordítva elég furán hangzik hogy "téma") de ezeket nem kell előre, központilag előkészíteni. Ennek megvan az előnye és a hátránya is: könnyű új publisher-t csatlakoztatni, ugyanakkor nem egyszerű megtalálni egy új topikot, mivel ezeknek nem lehet központilag lekérdezni a listáját. Ha elírsz valamit, akkor lehet keresgélni sokáig...

Hogy áttérjek a lényegre: konkrét implementációnak én a mosquitto nevűt találtam. Legtöbb helyen ezt ajánlják a Home Assistant-hoz, ráadásul még nyílt forrású is. Telepíteni elég egyszerű:

sudo apt install mosquitto -y

Nem sok mindent kell rajta állítgatni, esetleg jelszóval, hitelesítéssel lehet játszadozni, ennyi. Nekem külön RasPi-n fut, de nyilván elfér a HA mellett is. Úgy szokott működni minden erre csatlakozó eszköz, hogy a különböző infókat különböző topikokba rakják fel, illetve ha vár valamire egy kliens, akkor feliratkozik bizonyos topikokra, majd amint azokon üzenet érkezik, akkor teszi amit kell.

Példa

1. sor: egy "sonoff_d1" nevű eszköz kirak egy státusz üzenetet. Akit érdekel, az feliratkozik a "tele/sonoff_d1/STATE" nevű topikra és feldolgozza az üzenetet. Jelen esetben az üzenet egy JSON kód, de nincs semmi előírás, bármi lehet itt. Túl nagy adatot nem érdemes küldeni, általában 1000 karakterben szokták maximálni az üzi hosszát, de sok beágyazott rendszernek már ez is túl hosszú (egy Arduino-nak 2 kB a teljes RAM kapacitása, ami mind nem is érhető el menet közben)
2. sor: egy "hass" nevű eszköz (ami jelen esetben a HA központi egysége) küldött egy üzenetet a "stat/sonoff_d1/POWER2" nevű topikra. Amint látható is, itt nem JSON az üzenet, hanem csak "OFF". A konkrét példa azt mutatja, ahogy a központ kikapcsol egy relét.
3. sor: "sonoff_d1" visszajelez a "stat/sonoff_d1/RESULT" topikon, hogy sikerült a művelet, JSON-ul szólva "{"POWER2":"OFF"}" - kikapcsolta a kettes relét.

A példa bemutatja, hogy hogy is kommunikálhatnak ezen keresztül a rendszerek. Minden eszköz "belekiált" valamit az éterbe, más eszközök meg hallgatózhatnak ilyen kiáltásokra. Kérdés-válasz jellegű kommunikációhoz 2 topik kell, státusz jellegű üzeneteket viszont bármikor lehet közreadni. A topikok akkor jönnek létre, amikor valaki üzen rájuk, vagy valaki elkezd hallgatni egyre.

Parancssor

A mosquitto-val jön pár parancssori alkalmazás is:

• mosquitto_pub: publish, azaz ezzel lehet publikálni üzit. Ha lokális a mosquitto szerver, akkor csak -t topic -m message paraméterek kellenek és már el is küldtük a "topic"-ra a "message" üzenetet.
• mosquitto_sub: subscribe, vagyis ezzel lehet feliratkozni topikra. Lokálisan ő csak egy topik nevét várja -t után

Retain

Amikor küldünk egy üzenetet, akkor meg lehet adni, hogy az "postán maradó" legyen-e: ha igent mondunk, akkor ez az üzenet ottmarad a topikon, amíg nem jön újabb. Ez azért érdekes, mert ha valaki azután iratkozik fel miután az üzi már megérkezett a topikra, akkor ez a paraméter dönti el, hogy a friss feliratkozó megkapja-e az üzinket, vagy csak a következőt. (Ja igen, azt nem mondtam még, hogy a korábbi üziket nem lehet hivatalos módszerrel elérni, csak mindig a legfrissebbet.)

Will

Ami nekem érdekes volt, hogy megoldható az is, hogy tudni lehessen, egy kliens csatlakozva van-e. Ezt úgy lehet elérni, hogy amikor kliensként csatlakozunk, akkor pár paraméterrel lehet olyat mondani, hogy mennyi legyen a timeout és ha ennyi időn belül nem küldünk semmit a szerver felé, akkor melyik topic-ra milyen üzenet kerüljön ki magától. Python-ul ez a következőképp hangzik:

import paho.mqtt.client as mqtt

MQTT_HOST = 'your_mqtt_server_address'

client = mqtt.Client()
client.will_set('myclient/status', 'offline', 0, True)
client.connect(MQTT_HOST, 1883, 60)
client.loop_start()
client.publish('myclient/status', 'online', 0, True)

#do what you want

client.loop_stop()
client.disconnect()

Itt 60 mp a timeout, és a myclient/status topikra offline üzenet megy ki (retian módban) ha ezen az időkorláton belül nem szólunk semmit. Nyilván a csatlakozás után rögtön szólunk is az említett topikra, hogy online lett a kliensünk. (Ha normál módon, disconnet() metódussal ér véget az együttműködés, akkor is kimegy az offline, amit beállítottunk.)

Lassan egy év telt el az utolsó bejegyzésem óta. Közben történtek dolgok, találkoztam sok érdekességgel, elkezdem hát papírra vetni az összegyűlt tapikat.

Ugye a termosztát projektemet, mint végső célt már korábban összefoglaltam. Ez nem változott igazából azóta sem, de rájöttem, hogy érdemesebb lenne kipróbált alkotóelemekből rakni össze egy ilyen dolgot. Viszont egy valamihez ragaszkodok: a nyílt forráskódhoz és az információ házon belül tartásához. Ennek két nyilvánvaló oka is van: a boltban kapható megoldások többnyire elég húzós áron futnak, illetve ami nem drága, ott meg az ember az adataival fizet. Nekem az nem tetszik, ha egy villany felkapcsolásához a kérésem egy kínai szerverig szaladjon...

Ma bemutatom az általam választott megoldás szoftveres oldalát - legalább is elkezdem.

Home Assistant

Mint a neve is sugallja, ez egy olyan platform, ami az otthon automatizálásban tud asszisztálni. Rengeteg mindennel tud kommunikálni, illetve inkább úgy mondanám, hogy sok mindennel lehet integrálni. Ami nekem mindenképp szimpi volt, hogy nyílt forrású és az én kezembe marad minden infó - legalábbis remélem. (Nyilván nem néztem át az összes forráskódot, de bízom az open source community-ben.)

A rendszer Python-ban íródott, pontosabban íródik a mai napig. A kommunikáció egy bizonyos MQTT nevű rendszerre épül. (Erről lesz külön poszt hamarosan, stay tuned!) Én kezdetben egy Raspberry Pi 3-ra telepítettem, mert az volt kéznél. Ugye fontos, hogy egy ilyen rendszernek folyamatosan üzemelnie kell, tehát nem árt ha olyan HW-en fut, ami nem zajos, nem fogyaszt sokat és nem éjjeliszekrény méretű. Számítási igénye nincs kifejezetten sok, de ahogy kezd komplexebb lenni a rendszer nyilván kér majd enni. Van a Home Assistant-nak (továbbiakban HA) olyan verziója is, amit az ember felmásol egy microSD kártyára, bedugja egy RasPi-ba és indulhat is a móka, de én nem ezt választottam. Inkább manuálisan telepítettem, mert az említett RasPi nálam más dolgokat is csinál, szeretem a saját kezemben tartani az irányítást.

Miután az ember felinstallálja a rendszert és elindul a 8123-as porton lesz a webes felület. Letisztult a dizájn, csak kezdetben nagyon üres - de mit is várjon az ember? mivel nagyon sok mindenre jó a cucc és sokrétűen konfigurálható, így alap dolgokkal indul. Első körben csinálni kell egy új júzert, semmi extra. Ami kicsit kevésbé volt egyértelmű - nekem - hogy hol is vannak a konfigurációs fájlok. Elmondom:

cd /home/homeassistant/.homeassistant

Itt kell kezdeni a configuration.yaml fájl reszelgetését. Nem titok, aki maga akarja csinálni egy kézműves otthonautomatizálást, az közeli barátságba fog kerülni ezzel és a többi yaml kiterjesztésű haverjával.