Category Archives: homeaut

Ha nagy leszek, villanyász leszek?

Valamikor rég, talán még Mária Terézia idejében épületeket automatizáltam. Ez annyira ment, hogy majdnem munkát adott Ausztráliában – de az egy másik történet.
Most, hogy visszaköltöztünk Európába, nekiállok megint, ezúttal a fiaimmal, hármasban.

A dolog úgy indult, hogy a szerkezetkész házban, amit 20+ éve vásároltunk, 16 előre beépített szigetelt redőnytok volt készre szerelve és a villanyszerelőnk rákérdezett, hogy akarok-e motoros redőnyöket majd. Fogalmam nem volt, hogy kéne-e ez nekünk, ezért elsőre inkább nemet mondtam. Aztán persze egy évvel később már a saját bőrömön éreztem, hogy ez nem jó így és nekiálltam a tizenhat redőny automatizált villamosításának.

Az automatizálás mindenféle egzotikus hardverekkel kezdődött, majd találtam egy magyar gyártót is a feladathoz, azonban normális szoftver egyikhez sem volt, úgyhogy írtam egy sajátot, aztán még egyet, majd ern0 cimborámmal egy harmadikat. A második frontendjét szerettem a legjobban (annak ANSI C volt a háta és Macromedia Adobe Flash ActionScript az eleje), de igazán ern0 dataflow backend agymenése volt mind közül messze a legfrappánsabb. Ráadásul a dataflow komponens írás egy olyan addikció, amiről nehezen jön le az ember, ha egyszer belekezd. Ern0 agya nagyságrendekkel gyorsabb mint a beszédszintetizátora, de én ennek ellenére arra buzdítanálak, hogy ha érdekel a téma és kell még egy drog az életedbe, akkor nézd végig a témában ezt is meg ezt is meg ezt is 🙂

Szóval a nyúlüreg 2000 körül az X10 PowerLine protokollal indult, aztán jött minden, amit csak el lehet képzelni a témában. Az épületautomatizálás az esetek nagy százalékában protokollok egymáshoz illesztését jelenti. Van ugyan kivétel ahol nem kell gateway tuningolással vesződni, de arra meg kevés esetben elég a budget. Hogy mást ne mondjak, a gépészeti oldal még 2022-ben is kifejezetten szereti titkolni a saját buszos kommunikációját, miközben olyan, régóta létező nyílt szabványok segítenék az egységesítést, mint a Modbus, a BACnet vagy akár a KNX (és még lehetne sorolni bőven).
Szumma szummárum, anno sniffeltünk mi is mindenfélét, több-kevesebb sikerrel.

Amint berántott ez a homeaut világ, szembejött egy friss probléma: a villanyszerelők (és a riasztós szakemberek jó része is) retteg ettől a feladattól. Ráadásul kevés olyan mesterrel találkoztam, aki áttakinthető, dokumentált munkát adott csak ki a kezei közül. Ebből jött az, hogy én majd akkor szerzek egy villanyász papírt a 7/1991 számú kolbásztöltő üzemmérnökim mellé és villanyász is leszek. Onnantól majd eggyel kevesebb lesz a szűk keresztmetszet.

Nos, ez a 2000-es évek elején nem működött, ugyanis csak nappali tagozaton lehetett villanyszerelő képzést kapni. Anno beszéltem olyan hivatalnokkal, aki azzal zavart el, hogy “nem kellett volna agyoniskolázni” magam 😀

Szerencsére ez mára megváltozott, és már felnőttképzésben is lehetsz villanyász – Ákos fiamból is így lett villanyszerelő.
Ha te is beleugranál ebbe, akkor épp tudok adni a szóbeli vizsga tételeihez egy kupac kidolgozott doksit – pdf-ben és szerkeszthetően Markdown formátumban is ott van a zip file-ban. Enjoy!

HomeAssistant, Modbus, MQTT

Preface: száraz, technikai home automation post jön, magamnak és hasonló bűvös kockáknak.

A probléma

HomeAssistantban akartam egy PLC digitális kimeneteit szenzorokként látni. A PLC beszél Modbus TCP-t, HomeAssistantban meg ott a modbus támogatás gyárilag, így relatíve egyszerűnek tűnt a dolog.

Amint nekiálltam az első bináris modbus szenzor definíciójának elfogott a félsz, hogy mi van, ha a HomeAssistantnak nem lesz annyi esze, hogy az összes coil állapotát egy körben kérdezze le. Modbuson ugyanis egyetlen requesttel elkérheted az összes eszköz állapotát egy byte tömbben – ha jól emlékszem 10 msec alatt -, nálam pedig 96 coil lekérdezése a feladat, ezért nagyon nem mindegy, hogy 1*10 vagy 96*10 msec egy polling kör.

Így definiáltam két szenzort, majd meglestem mit csinál a modbus integráció és sajna igazam lett: a HomeAssistant egyesével polloz, így ez nekem nem járható út. Persze lehetne saját integrációt fejleszteni (nagy eséllyel ez lesz a vége), de egyelőre gyorsabbnak tűnt az, ha MQTT szenzorokra váltok. Ráadásul az MQTT szexi, minimál network forgalommal, szóval mindenképp szimpatikus.

HomeAssistant alatt régóta ott csücsül az MQTT integráció – egy Mosquitto brókert tudsz pár klikkel telepíteni és már megy is. Nálam ez már adott volt, mivel az adott configban monitorozott ZigBee szenzorok adatait egy Zigbee2MQTT integráció szállította MQTT-n keresztül a HomeAssistantnak. Az egész hóbelevanc ment magától a kezdetektől fogva, így nem is sejtettem, hogy egy külső script bármi galibát okozhatna.

Összeraktam a scriptet, elindítottam és benéztem a Mosquitto brókerbe, de a script által publikált modbus topicnak nyoma nem volt – WTF?

A megoldás

Ahhoz, hogy mindenki megkapja a maga releváns szeletét a brókerből, dedikált userek és access control lista kell.

Először csináld meg az usereket az MQTT bróker configjában:

certfile: fullchain.pem
customize:
  active: true
  folder: mosquitto
keyfile: privkey.pem
logins:
  - username: external_user
    password: external_pass
  - username: internal_user
    password: internal_pass
  - username: observer_user
    password: observer_pass
require_certificate: false

A logins blokk definiálja a brókerhez hozzáférő usereket. Amint látod, én hármat csináltam: az internal_usert kapják a belső integrációk, az external_user a modbus scripté, az observer_user pedig nekem egy külső monitoring toolhoz hasznos.

A customize blokkon belüli active: true mondja meg neki, hogy extra cfg file-okat kell még olvasgatnia induláskor, a folder: mosquitto pedig azt, hogy a share/mosquitto folderen belül lakó összes .conf végződésű file az övé.

Így már csak létre kell hoznod a share/mosquitto/acl.conf file-t benne a definícióval, ami megmondja a brókernek, hogy hol lesz az access control file:

acl_file /share/mosquitto/accescontrollist

Végül ebben a /share/mosquitto/accescontrollist fileban jogot kell adnod az egyes usernek:

user internal_user
topic readwrite #

user external_user
topic readwrite modbus/#

user observer_user
topic read #

Még a Zigbee2MQTT configjában kell definiálni az MQTT usert az MQTT blokkban és meg is vagyunk:

data_path: /config/zigbee2mqtt
external_converters: []
devices: devices.yaml
groups: groups.yaml
homeassistant: true
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  user: internal_user
  password: internal_pass

Már csak a Modbusról jövő MQTT szenzorok HomeAssistantba gyógyítása van hátra, de az majd inkább egy következő post lesz.

Homeaut: mosógép tuning

A héten valahogy bekattant, hogy milyen jó lenne ha a mosógép szólna amikor végzett a mosással. Persze ezt a szexi új cuccok tudják, de ezért le nem cserélnék egy működő mosógépet, szóval más megoldás kell. Majd a fogyasztásából én kitalálom!

Otthon még csak-csak odavinnék a mosógép dugaljához egy dedikált drótot és a kiindulási pontban méregetném valami indukciós elven, de itt a holland albérletben ez nem járható út. Viszont van rengeteg rádiós fogyasztásmérő dugalj, úgyhogy be is szereztem egy ilyen csini helyi darabot.

Innen már nem volt messze a megoldás:

  • a fogyasztásmonitor dugalj megmondta, ha a mosógép elkezdte enni az áramot – ekkor beállítottam egy mosás flaget
  • ha a mosás flag aktív volt, figyeltem, hogy mikor szűnik meg a dugaljon a fogyasztás legalább 10 másodpercig és amint ez megtörtént, küldtem egy üzenetet, majd reseteltem a flaget is

Nem egy rocket science, mégis milyen hasznos cucc ez – simán szól, ha kész a mosó/szárító/mosogatógép, vagy bármi, ami árammal megy!

Ha már egyszer naplóztam a fogyasztást, akkor megnéztem közelebbről, hogy hogy eszik a mosógépünk:

Nagyon szépen látszanak a fázisok:

  1. eligazgatja a dobban a ruhákat
  2. megy a fűtőszál, csinálja a meleg vizet
  3. forgatja a ruhát a motor
  4. centrifugál – lépcsőzetesen emelkedik a fogyasztás, ahogy emeli a fordulatszámot

Csini, mi?