Már egy ideje játszogattam a gondolattal, hogy a korábbi otthoni okos eszközöket és az általuk használt alkalmazásokat, protokollokat stb. valahogy egységesíteni szeretném mert már kezdtem belekergülni, hogy olyan működik is meg nem is állapotban voltam. Philips Hue eszközeim már lassan 10 éve vannak, de ahogy egyrészt bővült a család, másrészről új lakásba is költöztünk, az eszközök száma tovább növekedett, valamint nyilván evés közben jön meg az étvágy: egyre kiváncsiabb lettem. Nem mellesleg, műszakilag is érdekel az ilyen jellegű „barkácsolás”, így hobbinak is jó (igaz, annak néha drága 😀 ).
Eszközök
Szóval, a gyors érthetőség kedvéért:
- van nekem három Philips Hue kapcsolóm. Ráadásul 3 különböző modell (pontosabban 2, de abból is 1. ill. 2. generáció),
- van két Philips Hue Play lámpám,
- van egy Philips Hue led szalagom,
- valamint van még 2 db Philips Hue színes E27-es égőm,
- 6 darab Xiaomi hőmérőm (+ páratartalom),
- IKEA TRÅDFRI fali (3 db) és mennyezeti lámpa,
- egy csak HomeKit kompatibilis Logitech Circle kamerám,
- egy Eufy kamerám,
továbbá múlt héten még beruháztam egy Shelly Plug S-be, mert ahogy mondtam: evés közben jön meg az étvágy. 🙂
A Philips-ekről nem akarok írni, as-is használom őket, ahogy lejöttek a futószalagról, ugyanez igaz a Shelly-re és az IKEA eszközökre.
A Xiaomi eszközök más téma. 🙂 Itt kezdődött a barkácsolás és indultam mélyebbre a nyúlüregben. A pontos modellszám: LYWSD03MMC. Azért esett erre a választásom, mivel Mastodonon is írták, ill. a neten utánaolvasva is megerősítést nyertem, hogy ezek az eszközök community firmware-rel Zigbee kommunikációs protokollra is rávehetőek amit egyébként a gyári vezérlővel nem tud. Szóval a hardver benne van, csak a gyári firmware nem tudja.
Szóval ezeket szépen átflash-eltem a community firmware-re és így azonnal át is mentek Zigbee-re. A Zigbee elég jó protokoll, mert elég keveset eszik, és arra hogy 3 számot áttoljon rajta időszakosan, pont elég (hőmérséklet, páratartalom és töltöttség). Plusz olyan opciók is elérhetővé váltak az egyedi firmware-rel, mint Bluetooth és kijelző kikapcsolás, amivel tovább lehet növelni az elem élettartamát. A másik remek tulajdonsága amit nagyon ügyesen ki is lehet (és szerintem kell is használni), hogy a Zigbee mesh topológia. Ez azt jelenti, hogy ha például A eszköz (device) túl messze van a vezérlőtől (coordinator), akkor egy köztes eszköz közbeiktatásával „megnyújtható” a hálózat és így A eszköz is eléri a vezérlőt B eszközön keresztül. Itt viszont fontos, hogy csak fix áramellátással rendelkező eszközök lehetnek jeltovábbítók – Zigbee terminológiában router (tipikusan lámpák, izzók). Lásd a csatolt képet:
Még két dolgot meg kell említenem, az egyik, hogy én korábban már vásároltam egy Raspberry Pi 4-es számítógépet, valamint a Zigbee kommunikációhoz vettem egy Sonoff USB adaptert, amit csak szimplán bedugtam a Raspberry-be.
Akad még egy Synology NAS is itthon, ennek majd csak a legvégén lesz jelentősége.
Az „agy”
Oké, az eszközök megvannak, valahogy rá kéne őket venni, hogy „ugyanoda” beszéljenek és az egész fölött legyen egy management és kontroll, legyen egy „üzleti logika”, historikus adattárolás a szenzor adatokra és a mért adatok megtekintésére egy vizualizációs réteg.
Management és kontroll
Az Open Source community-ban kvázi de facto megoldássá nőtte ki magát a Zigbee2MQTT (Z2M). Ez a koordinátor, amely tartja a kapcsolatot az eszközökkel (az USB adapteren keresztül), kezeli a frissítésüket (minden támogatott eszközhöz a gyári OTA frissítési csatornát használja ami szerintem nagy szó), valamint a Zigbee protokollon beeső üzeneteket kiforgatja MQTT protokollra.
Miért kell a Zigbee üzeneteket kiforgatni MQTT-re? Nos azért, mert a legtöbb eszköz nem beszéli natívan a Zigbee-t (szerverek, számítógépek, telefonok stb.), így kell egy protokoll váltás. Az MQTT a Message Queue Telemetry Transport rövididítése, amely gyakorlatilag egy über stabil, pontos informatikai postagalamb kimondottan az ilyen, IoT (Internet of Things) eszközökhöz. A dolog szépsége, hogy úgynevezett topic-okat lehet rajta/benne létrehozni, ahova az üzenet publikálók (Publishers) be tudják dobni a mondanivalójukat, és a feliratkozók (Subscribers) pedig olvasni az oda érkező üzeneteket. Így nem kell spagetti végpontos retteneteteket összedrótozni. Szóval mint egy fórum: mindenki belekiabálhat, és te meg csak azt olvasod el belőle, ami téged érdekel.
(Ha valakinek nagyon szájbarágós, akkor bocsi, probálom nem csak informatikusi fejjel írni.)
Szóval, az én MQTT szerverem Mosquitto-t használ és szintén az Raspberry Pi-n fut. Az alábbi képen egy pillanatnyi állapot az én itthoni MQTT forgalmamról.
Szóval ott tartok, hogy vannak eszközeim, amik mindenféle státuszt, parancsot, mért adatot továbbítanak Zigbee-n a koordinátor felé, ill. a koordinátor a kapott üzeneteket átlapátolja MQTT-re. Jöhet a szaftos rész, amely kétfelé oszlik:
- szenzor adatok mentése egy speciális, idősík alapú adatbázisba,
- további eszközök vezérlése különféle logika mentén.
„Üzleti logika”, historikus adattárolás
Adattárolás
A Xiaomi hőmérők, ill. a Shelly okos aljaztok telemetriai adatokat (hello MQ Telemetry T) továbbítanak. Nyilván egy hőmérőnél az értelmezhető adathalmaz a hőmérséklet, a páratartalom és mondjuk egy töltöttség adat, míg egy okos aljzatnál az elektromos hálózat feszültsége (Volt), a frekvenciája (Hz – Hertz), a rajta átfolyó teljesítmény (Watt). Hogy ezek az adatok visszanézhetőek legyenek tetszőleges mérési időintervallumon belül, szükség van ezek tárolására. Mivel ezek az eszközök „nem szabályozható” módon közölnek magukról adatokat, így nem behatárolható, hogy pl. minden 5. másodpercben leolvassuk őket, vagy akár küldjenek egy időbélyeget a mérés időpontjával, ezért célszerű egy olyan adattárolási megoldást választani, amely időérzékeny.
Itt jött nálam képbe az InfluxDB megoldás, amely pontosan ezt a célt hivatott szolgálni. Magas frekvenciával képes adatok fogadására és az időpontot képes akár nanomásodperces (1 másodperc az 1 000 000 000 nanomásodperc) pontossággal tárolni. Nyilván nekem ilyen granularitásra nem volt szükségem, de azért a másodperc felosztás nem rossz.
Csodával határos módon, az InfluxDB-m is a Raspberry-men fut. Lehetett volna Docker-ben is (mint ahogy a Mosquitto-t is vagy a később olvasható Node-RED-et is) futtatni, de lusta voltam főleg a hálózati réteggel szívni, meg különben is, ha van már egy „szerverem” akkor miért ne?
Az adatokat az én esetemben két megoldással töltöm (de ezen a jövőben változtatni fogok mert az egyik kiváltja a másikat, csak hát így alakult „történelmi” okok miatt 😀 ):
A Telegraf egy tipikusan nagy adatsűrűségű környezetbe tervezett adatbetöltő, amely számos bővítménnyel rendelkezik mind a bemenet, mind pedig a kimeneti oldalon. A Xiaomi szenzorok adatait jelenleg ez tölti, fogja és bemeneti oldalon rácsücsül a megfelelő MQTT csatornákra és az odaérkező adatokat betolja a kimeneti oldalon az Influx-ba.
A Shelly később érkezett, ott már a Node-RED-et használom, ami gyakorlatilag ezen a szinten ugyanazt csinálja, mint a Telegraf: fogja az MQTT csatornára beeső adatokat és kvázi minimál adat transzformáció után beír az InfluxDB-be (FYI: van InfluxDB plugin a Node-RED-hez).
Megvannak az adatok, egész jó pontossággal, áttérek az „üzleti logikára”.
„Üzleti logika”
Szuper! Gyűjtöm az adatokat, most már valamit csak kéne kezdeni azokkal az eszközökkel is, amikkel más eszközöket kívánok vezérelni. Hívjuk kapcsolóknak. 😀
A kapcsolók is a többi Zigbee eszközhöz hasonlóan minden rajtuk végzett tevékenységről egy eseményt küldenek adott paraméterekkel, például:
- megnyomtad az 1-es gombot,
- nyomva tartottad az 1-es gombot,
- nyomva tartottad az 1-es gombot 10 másodpercig,
- megtekerted a tekerentyűt,
- elengedted a 4-es gombot
stb. Ezekre az eseményekre – köszönhetően a Z2M és az MQTT átalakításnak, a Node-RED gyönyörűen fel tud ülni és egy amolyan üzenet áramlási logikával események sorozatát lehet felfűzni. A Node-RED ezt flow-nak hívja. Szóval, van bemenet meg kimenet és a kettő között bármi történhet az üzenettel (payload).
Ezt kihasználva, építettem egy viszonylag bonyolultnak tűnő flow-t (ami valójában nem az, csak sok elemből épül fel), ami a kapcsolók különböző eseményeire reagál és kimenetként vezérli a vezérelni való lámpát.
Az alábbi képen az eddig elkészült vezérlés látható, a kijelölés egy konkrét útvonalat valósít meg (adott kapcsoló által küldött üzenet hatására felkapcsolja a kiscsaj szobájában a lámpát):
A jövőben erre készülök áttérni a Telegraf-os megoldásról mert akkor attól is szabadulhatok és egy fokkal egyszerűbb lesz a komponens lista, a Node-RED-re így is úgy is szükségem van a vezérlés és a transzformációk miatt. A Node-RED jó cucc, bár kell egy pár óra olvasgatás, mire az ember agya elkezdi benne látni az értelmet. Ha van konkrét kérdés a flow kapcsán ami a képen van, akkor szívesen arról is írok egy ettől jelentősen rövidebb bejegyzést, a lényegre fókuszálva. 🙂
Vizualizációs réteg
Lassan a végéhez érek, cserkész becsszó! 🙂 Szóval a szenzorok által mért adatok tök jó, hogy bent vannak egy adatbázisban, de onnan azért macera csak úgy kiolvasni, meg hát, nem lehet belőle színes-szagos grafikonokat gyártani. Na pont erre találták ki a Grafana megoldást, amely gyakorlatilag szintén de facto megoldás lett, ha adatvizualizációról van szó.
És itt jön képbe a NAS. 😀 Mivel ez egy „hozzáadott” szolgáltatás a részemről ezért nem para, ha bármi történik vele, így végül a NAS-on kapott helyett egy csinos Docker konténerben. A bütykölt eddigi dashboard-om így néz ki:
Műszaki megoldás tekintetében minő véletlen, hogy direktbe tud InfluxDB-t olvasni, így gyakorlatilag pár perc alatt összedobható egy ilyen képernyő. (Persze miután az ember megtanulta az InfluxDB query nyelvezetét, mert egy hagyományos SQL-hez nagyjából pont nulla köze van. 😀 )
A ráadás
Eddig kevésszer írtam le az Apple nevét a bejegyzésben (emiatt szégyellem is magam), de mivel nálunk mindenki és minden is Apple, ezért nem tudtam kihagyni (és igazából nem is akartam) a képből a HomeKit integrációt. Itthon van nekem két Apple TV és egy HomePod mini eszközöm, így tehát a HomeKit bridge része megoldva. Viszont kellett valami ami „behazudja” ebbe a rendszerbe a többi Zigbee-s eszközt mint HomeKit képes eszköz. Így jött képbe a Homebridge megoldása, amely szintén a Raspberry-n fut. Viszont mivel az eszközök nem megszólíthatóak direktbe a Homebridge által Zigbee-n, ezért!! van hivatalos Zigbee2MQTT bővitmény ami pont ezt a hiányosságot hidalja át. És voilá! Az eszközök ott figyegnek HomeKit-en is, pedig a réteges megvalósítás (jah, mint a hagyma – Szamár) legalján ugyanúgy MQTT és Z2M kerül meghajtársra.
És telefonon:
Sokmindenről lehetne még írni, például a biztonság részéről, meg a többiről, de akkor sose lesz vége, így is velős, ugyanakkor érthető lett szerintem ez a bejegyzés. Hogy megérte-e? Vegyes. Hobbinak marha jó, meg az is marha jó amikor jól definiálható forgatókönyvekre reagál a rendszer (reggel, hazaértem, elmentem, filmet nézek, gyereknek random színnel fog világítani az alvós lámpa és ez örömet és izgalmat okoz, hogy ma milyen színű lesz), de persze ha megáll a rendszer, akkor maradnak a hagyományos fizikai kapcsolók. 🙂 Mert azért azokat nem iktattam ki. De szerintem nem is kell, ezt inkább on top of it élem meg és az tök jó. 🙂
Ha jönnek majd visszajelzések, hogy esetleg valamely részterületébe jobban beleásva írjak, akkor szívesen!
Maradok örök hobby home IoT barkácsolótok!
