Tag Archives: home automation

Mentem volna el inkább kapálni?

Beköltöztünk egy házba, ahol a földszinten levő négyféle lámpát négyféle RF remote irányít, a sötét mosogató feletti ledcsíkot pedig nem kapcsolja mozgásérzékelő, amitől én agyf@szt kapok. Szerencsére mindig van nálam ilyen szet, úgyhogy nekiálltam hackelni.

Feltettem egy Philips Hue ledcsíkot meg egy ahhoz tartozó mozgásérzékelőt. Ez eddig sima liba – pár klikkel rá lehet venni a Hue appban a hubot, hogy ha setét van és mozgás akkor kapcsolja bé a ledeket. Na de van egy böszme nagy konyhasziget is, ami ugyanolyan sötét és felette 6 darab másféle led lakik – az is mind kéne, pont akkor, amikor a Hue ledcsík bekapcsol.

Felmásztam a ledekhez, kibányásztam egyet és kiderült, hogy ez valami custom vadállat, brutális alubordába hegesztve, úgyhogy esélytelen, hogy én ebbe egy smart bulbot rakjak.
Arról nem beszélve, hogy 6 smartbulb már nem ugorja meg a budget küszöböt, amit erre szánnék. Elkezdtem hát kutatni.

Először onnan indultam, hogy majd faragok én kis hülye egy Arduino eszközt, ami lesniffeli az RF remote 433 MHzes szekvenciáját – már ha szerencsém van ugye és ezek a hulladékok tényleg 433 MHz-en beszélnek. Elkezdtem utánaolvasni ennek, majd rövid úton akkor párolgott el az RF sniffer építés iránti vágyam, mikor kiderült, hogy 1 mm-rel elmért antenna már totál használhatatlan lesz. Aki látta már a lapát kezeimet, az tudja, miért nem tetszett meg a saját antenna tekerésének ötlete. Szóval inkább valami célszerszám kéne erre, nem igaz, hogy nincs.

Találtam egy Sonoff RF bridge nevű jószágot, 25 EUR. arra találták ki, hogy a Sonoff RF-es cuccait tudja vezérelni – pont jó lesz, mivel azok is 433 MHz-en mennek. Persze ahogy Móriczka elképzeli – hiába ugyanaz a 433 MHz, a gyári fimrware bizony megfilterezi a packeteket és így egyik RF adó jelét sem látja, ami a házhoz tartozik.

Még egy kis research, majd kiderül, hogy van hackolt firmware.

Felteszem.

Nem mén.

Naná, hogy nem mén, mert ehhez a trükkhöz két firmware-t kell cserélni – a másik az RF csipé, amihez viszont 2 db GPIO vezetéket fel kéne kaparni a nyákon. Ha már lúd legyen kövér, felkaparom. Hihetetlen, de felmén az RF firmware is.

Itt jött vagy 6 óra anyázás, hogy mégsem jó az egész és továbbra sem látja a bridge az RF remote-jaimat. Aztán elmentem aludni, másnap reggel hideg fejjel újra az egész és voila: ott volt a sniffelt raw data!

Kis üröm az örömben, hogy az elmeroggyant remote ugyanazzal a szekvenciával kapcsolja ki és be is a lámpát, de sebaj, már tudom a konyhasziget feletti fényt kapcsolgatni a Macről.
Ööö mondjuk igaz, hogy kell hozzá egy brózer, aztán egy login, aztán egy konzol, aztán két sor data, de mén.

Innentől már csak egy ugrás volt a homeassistant nevű feneketlen kút.

A homeassistant egy open source homeaut server, messze többet tud, mint bármi más, amit eddig láttam, viszont kb. mintha kernelt fordítanál úgy, hogy nincsenek tömör egyszerű HOWTO-k meg példák. Persze bennem is van hiba, mert nem akartam 900 oldal manualt elolvasni, tuti ott van leírva, amit az előző 2-3 napban szedtem össze.

Szóval homeassistant installál egy RPi-re. Felismeri a Philips HUE cuccokat, megtalálja a Tasmota firmware-rel hackelt RF bridge-t is.

Innentől már csak 2-3 műszak volt rájönni, hogy az RF bridge-et úgy tudom rávenni a szekvencia kiküldésére, hogy installálok egy MQTT brókert, csinálok benne usert, ezeket beállítom az RF bridge-ben, majd topicot konfigurálok és összerakok indentálás érzékeny yaml-ban egy MQTT publish csomagot, RFRaw payloaddal. Amint ez megvolt, a Homeassistant tudta kapcsolgatni a konyhasziget lámpáját.

A mai este még azért kellett ahhoz, hogy csináljak egy automationt a homeassistantban, ami azt figyeli, hogy átkapcsolódik-e a Philips HUE ledcsík állapota és ha igen, akkor ő küldje ki rögtön az mqtt.publish service-ban a mnd/SonoffRFBridge/rfraw topicba a AA B0 1B 03 08 0190 0294 3BCE 28180918180909091818180909091818181818 55 payloadot.

Ez úgy 10 perce sikerült, úgyhogy most elmegyek aludni.

Kisebb megszakításokkal úgy egy hétig baszakodtam vele, de cserébe holnap amikor lejövök reggelit csinálni, azonnal bekapcsol mindkét sötét helyen a lámpa, amint odamegyek a kávéfőzőhöz.

Home automation: építsünk detektívet!

Preface 2012 márciusában lecseréltük a hagyományos kazánt kondenzációsra és ha már lúd legyen kövér alapon telepítettünk mellé 5 m² váklumcsöves napkollektort is a hozzá való köcölékekkel (hőtároló puffer, hőcserélő, frissvíz modul, vezérlés, etc.) egyetemben. A választás némi kutatás után a Vaillant termékére esett. 2016 augusztus közepén egy meleg nyári napon forró etilénglikol szaga áradt a kazánházból. Elég volt egy pillantás a szabályzóra, hogy észrevegyük: a kinti hőség ellenére a kollektorokból egy csepp meleget sem szed le a rendszer. Ráadásul ekkor tűnt csak fel, hogy a baj már 2016 júniusában bekövetkezett, csak akkor nem vettük észre.

Melegcsináló HOWTO

Mielőtt a lényegre térnék, muszáj dióhéjban ideMórickázom, hogy működik a fűtésünk: r9-heating Gondolom rájössz magadtól, de azért: a rajzon a zöld az áramlási irányokat jelöli, a piros a meleg közeget, a kék a hideget. Az 1. napkollektoroktól a 2. szivattyú behúzza a hőszállító etilén-glikolt a 3. hőcserélőbe, aki a glikol melegét beletolja a 4. puffertartályba. Ha a háznak melegre van szüksége, akkor az 5. hőcserélővel a 6. szivattyú csinál a csapvízből meleget, vagy a 7. szivattyú a fűtési körökben levő folyadékokra melegít rá egy kicsit. Az egészhez persze csatlakozik még egy kazán is, de azzal most semmi dolgunk, úgyhogy ezért lehagytam a Mórickáról. A solar körön a 3. hőcserélő után van egy nyomásmérővel ellátott biztonsági szelep, amiből egy hosszú rézcső megy be egy nyitott puffertartályba. Erre azért van szükség, hogy ha valami hiba folytán a nyomás alatt levő solar kör belső nyomása elérné az 5 bar-t, akkor ez a biztonsági szelep egyszerűen leengedi a glikolt ahelyett, hogy hagyná felrobbanni a csöveket.

Nyomozás v1.0

Az augusztus közepén detektált problémát a szerelő úgy korrigálta, hogy újratöltötte a glikolt a nyomás alatt üzemelő rendszerben. A szakember arra tippelt, hogy valószínűleg hosszabb ideig nem voltunk otthon, így nem volt hőelvétel a pufferből és a termelődött meleget a vezérlés már nem tudta hova rakni, így ennek megfelelően a túlmelegedő glikol nyomása elérte az 5 bar-t, a biztonsági szelep leeresztett és onnantól nem volt ami lehozza a meleget a tetőről. Ezt el is fogadtam, viszont nagyon nem hagyott nyugodni, hogy a problémáról a rendszer semmiféle módon nem tájékoztat. A dolgot úgy veszed észre, hogy a kinti hőség ellenére azt látod a vezérlő kijelzőin, hogy aznap semmi hőt nem termelt a solar kör, illetve a hosszabb időtartamú kiesés is megfigyelhető egy buta havi bontású oszlopdiagrammon. Nekem ez kevés. Én tudni akarom, hogy pontosan mi történik a solar körben, illetve elektronikusan akarom detektálni azt, amikor ismét előáll a probléma és erről push notificationt akarok küldeni a fiúknak, akik majd riasztják a szervizest. Persze az igazi az lenne, ha a solar kör nem hibázna, ám mint pár óra telefonálgatás után megtudtam, erre a nyomás alatt levő solar rendszerek nem alkalmasak, csak a mostanában gyártott, önmagukat leereszteni és újratölteni képes kollektoros installációk. A sajátom természetesen ezekkel nem kompatibilis. Azt találtam ki, hogy a glikolt szállító csőre hőcserélő bemeneténél és a biztonsági szelepnél is teszek fel egy-egy PT-1000-es hőmérőt, 10 percenként mérek velük egyet és a mért értékeket naplózom egy sql táblába. Ezen felül azt gondoltam, hogy talán jó indikátor lesz a meghibásodásra, ha a bizontsági szelepnél mért hőmérséklet elér egy határértéket (70 ℃-ra saccoltam), aminek hatására már küldhetem is a figyelmeztetést a gyerekeknek. Felszereltem a hőmérőket, beállítottam a homeaut serverben a naplózást, megcsináltam a vizualizáló interfészt, körbeteszteltem szépen mindent és úgy gondoltam kész vagyok, de persze tévedtem. A következő meghibásodás kb. 2 héttel az előző hiba kijavítása után következett be. Sajnos a biztonsági szelep utáni hőmérséklet teszt nem bizonyult hatásosnak: a cső nem melegedett 45 ℃ fölé. Ennek ellenére a hőmérő naplózás nem bizonyult hiábavalónak – mindjárt meg is mutatom! A biztonsági szelepnél levő hőmérővel most nem foglalkozunk, elég tanulságos lesz a solar kör hőcserélőjének bemeneti hőmérséklete. Az első grafikonon azt látod, amikor a rendszer normálisan működik két egymást követő, kb. egyformán meleg napon: solar-temp-log-OK Ezen pedig jól látszik, hogy a 2. napon 9:30 tájban pusztul meg ismét a rendszer: solar-temp-log-FAILURE Két egymást követő kb. egyforma napon a normál működést tanulmányozva nagyon jól látszik, hogy mi történik a rendszerben:
  • 6:10: az éjszaka után beindul a solar szivattyú. Az ezt követő 10 percben ~10 ℃-t esik a hőmérséklet, mivel az éjszaka során meghűlt a kollektorban levő glikol és a szivattyú épp ezt a hidegebb folyadékot hozza le a hőcserélőbe. A kollektor és a hőcserélő közti csőszakasz valamint a padlástér is vastagon szigetelt, ezért abban csak nagyon lassan hűl ki a hőszállító folyadék – ez láthatod az éjféltől kezdődő első szakaszon.
  • 7:20: felkel a nap, a kollektorok elkezdik termelni a meleget.
  • 15:00: a hőtermelés csúcsa, kb. ekkor süti optimális szögben a nap a kollektorokat. Innentől kezdve lassan csökken a glikol hőmérséklete, de még mindig van bőven hőmermelés.
  • 20:00: lemegy a nap, a hőmermelés megszűnik. A hőtároló pufferben már legalább 60 ℃ hőmérsékletű víz van, így az ennél hűvösebb glikolból a hőcserélő már nem vesz el meleget. A görbe simulása egyenletesebbé válik, ami azt is jelzi, hogy a szivattyú már nem keringtet, a csőben levő hőszállító folyadék magától hűl le lassan.
Ha ránézel a 2. ábrára, akkor arról a fentiek alapján a meghibásodás napján (=kék diagram) ugyanígy leolvasható a történet:
  • 9:00: A lassan hűlő glikolt 6:10 helyett 9:00-kor mozdítja meg a keringtető szivattyú. A hőcserélő visszahűlése jóval kevesebb ideig tart, mivel a kollektor ilyenkor már baromi meleg.
  • 9:30: a hőmérséklet ezerrel emelkedik.
  • 9:50: az utolsó mért meleg érték – a nyomás alatt levő csőrendszer itt éri el az 5 bar határértéket, a biztonsági szelep leereszti a glikolt. Innentől már csak a lassú kihűlés marad, mivel nincs hőszállító közeg.
A fentieket megmutattam a szerelőnek, aki a rendszert ismét átnézve arra jutott, hogy a hőcserélő szivattyúja adta meg magát. Én továbbra is azt látom a diagrammokon, hogy az eltelt 2 hétben a szivattyú minden nap 6:10-kor indul, kivéve a meghibásodás napját, amikor 9:00-kor mozdította meg először a folyadékot. Szerintem inkább a vezérléssel nem stimmel valami. A második hiba után szeptember 5-én a csöveket trisóval átmosták, a hibásnak gondolt szivattyút kicserélték, majd 2 nappal ezután a következőt rajzolta nekem reggelire a log: solar-temp-log-WARNING A kék vonal megint azt mutatja, hogy a szivattyú egy órával később kapcsol. A vezérlésnek nincs internetkapcsolata, tehát nem tud az időjárásról, mindössze annyit ismer a környezetéből, hogy Magyarországra telepítették és hogy épp mennyi a pontos idő.

Nyomozás v2.0

A fentiek alapján azt feltételezem, hogy a rendszer hamarosan ismét megadja magát. A logok nekem már most is egyértelműek, viszont ettől lehetnének egy picit még precízebbek is, ezért a következő tuningot eszeltem ki:
  • A biztonsági szelepen levő hőmérő átkerül a hőcserélő kimeneti oldalára, így a két mért értékből jól látszik majd, hogy a puffer felvette-e a tetőről lehozott hőt.
  • A szivattyú tápellátására párhuzamosan rákötök egy 230 V AC-re kapcsoló relét, aminek a kapcsolt NO lábát odaadom egy digitális bemenetnek a homeaut buszon. Ezzel értesülni fogok arról, hogy mikor indult és mikor állt le a szivattyú.
  • Ha már tudom, hogy mikor megy a solar szivattyú, akkor elég lesz akkor megmérnem a két hőmérsékletet – illetve egész pontosan mondjuk 30 másodperccel a szivattyú indulása után, hogy biztosan a lehozott hőszállító folyadékot mérjem.
Amióta ern0vel összeraktuk a dataflow alapú homeaut servert, nincs az a probléma, aminek a megoldását ne lenne élvezetes implementálni homeaut oldalon egy kis dataflow script módosítással. Lényegében az egész terjengős posztot azért kellett végigrágnod, hogy meg tudjam mutatni neked, hogy csináltam!-) A fizikai adatbuszról a fenti probléma megoldásához kétféle adatra van szükségünk: egy digitális bemenetére (amire a keringtető szivattyú tápjával vezérelt 230 V AC-s relét kötöm) és a PT-1000-es hőmérők által mért analóg értékekre. A digitális inputokat 100 msec-enként lekérdezem egyben, úgyhogy az már kész, viszont a házban levő 8 darab PT-1000-es hőmérőt csak 10 percenként kérdeztem le eddig, mert a többit bőven elég ilyen lépesközzel naplózni, a két solar hőmérő naplózását viszont a szivattyú bekapcsolásának kellene vezérelni mostantól. A dolog azért problémás, mert a 8 darab hőmérőből 4-et csak egyszerre tudok lekérdezni a Wago MODBUS interface-en. Szerencsére itt van a kezem alatt a dataflow nevű rágógumi, amit a végtelenségig lehet nyújtani – nézzük meg, hogy hogyan csinálom!

Dataflow gyorstalpaló

Ha tudod, mi az a dataflow, akkor menni fog az is, ami lejjebb következik – ha viszont nem, akkor ern0 barátom eldarálja neked elképesztő sebességgel 10 percben (amiből a második ~5 perc már csak a kérdésekre adott válasz):

Dataflow from Budapest New Tech Meetup on Vimeo.

ern0 közben feltöltötte youtube-ra a tavalyi hosszabb dataflow meetup videót is – hardcore rajongóknak kötelező ez is:

Megoldunk

Ezek után lássuk, hogy raktam mindezt össze: log_df_visualized Ha inkább a scriptet olvasnád, mint a vizualizált ábrát, az így néz ki (btw a fenti rajzot ern0 kódja generálja graphvizzel a lenti dataflow scriptből :)):
component Main {
	implementation {
		carpet log {
			// create pulsars
			p100ms: RTCPulsar
			p100ms.freq = 100000
			p1s: RTCPulsar
			p1s.freq = 1000000
			// create 10 min scheduler
			p100ms.out >> sched10min.clock
			sched10min: Scheduler
			sched10min.mask := "schedule={mi=0,10,20,30,40,50 se=0}"
			// feed Wago digital poll
			p100ms.out >> wdp.digipoll
			wdp: WagoPoll
			wdp.digibase = 0
			wdp.digipollsize = 96
			wdp.anabase = 0
			wdp.anapollsize = 4
			wdp.serout >> s1.in
			s1: Serial
			s1.device := "wago_ip:502"
			s1.out >> di4_1.serin
			di4_1: WagoDigiIn
			di4_1.base = 48
			// feed Wago analog poll
			p1s: RTCPulsar
			p1s.freq = 1000000
			p1s.out >> wap.anapoll
			wap: WagoPoll
			wap.anabase = 0
			wap.anapollsize = 4
			wap.serout >> s2.in
			// Wago bus
			s2: Serial
			s2.device := "wago_ip:502"
			// split Wago analog input msg
			s2.out >> ai1.serin
			ai1: WagoAnaIn
			ai1.base = 0
			ai1.size = 8 // 4 input, 2 byte/input
			// store temps in Value components
			ai1.out1 >> temp1.setvalue
			ai1.out2 >> temp2.setvalue
			ai1.out3 >> temp3.setvalue
			ai1.out4 >> temp4.setvalue
			temp1: Value
			temp2: Value
			temp3: Value
			temp4: Value
			// send measured temps to sql loggers from the first 3 thermometers
			sched10min.out >> temp1.in
			sched10min.out >> temp2.in
			sched10min.out >> temp3.in
			temp1.out >> sql1_1.in
			temp2.out >> sql1_2.in
			temp3.out >> sql1_3.in
			temp4.out >> sql1_4.in
			// define sql loggers for all 4 thermometers
			sql1_1: Shell
			sql1_1.command := "./log_temp.py r9_nagyhaz_nappali"
			sql1_2: Shell
			sql1_2.command := "./log_temp.py r9_solar_test"
			sql1_3: Shell
			sql1_3.command := "./log_temp.py r9_utca"
			sql1_4: Shell
			sql1_4.command := "./log_temp.py r9_napkollektor"
			// di4_1.out1 = solar pump power state change
			di4_1.out1 >> change4_1.value
			change4_1: Change
			change4_1.last = 0
			change4_1.zero >> log_solar_pump.in = 0    // log pump OFF state
			change4_1.nonzero >> log_solar_pump.in = 1 // log pump ON state
			change4_1.nonzero >> d30s_4_1.in           // log temp with delay after pump switched on
			// log solar pump state
			log_solar_pump: Shell
			log_solar_pump.command := "./log_di.py r9_solar_pump"
			// log thermometer wiuth a 30 sec delay
			p100ms.out >> d30s_4_1.clock
			d30s_4_1: Delay
			d30s_4_1.delay = 300
			d30s_4_1.out >> temp4.in // log temp with 30s delay after pump has started
		}
	}
}
Elmagyarázom a rajzot – a legjobb, ha kinyitod teljes méretben 🙂
Start
Kezdetben azt csináltam, hogy egy 10 perces scheduler (=sched10min) lökdöste meg az analog inputokat pollozó wap komponenst és az abból kiálló ai1 analóg poll értelmező meghívott négy darab, sql insertet elvégző scriptet (sql1_1..sql1_4), akik megcsinálták a naplózást. Ezzel az a baj, hogy a 4. hőmérőt csak akkor akarom naplózni, amikor a szivattyú beindul, a többi meg maradhat 10 percenként.
Flow detection
Első körben detektálni kellett a szivattyú indulását. Ehhez csak a solar vezérlőből a szivattyúnak adott 230 V AC tápra kell párhuzamosan rákötni egy 230 V AC által kapcsolt relét, aminek a másik végébe jön a 24 V DC kimenetünk, akit a buszon a di4_1 modul out1 lábára kötünk. Nekem akkor kell naplóznom a solar folyadék hőmérsékletét, ha a szivattyú megindul (egész pontosan kicsivel utána), így a di4_1.out1 láb 0-ról 1-re történő állapotváltozása kell, hogy kiváltsa a naplózást. Az állapotváltozás detektálására ott van a change4_1 komponensünk, aminek a zero illetve nonzero lábain csak akkor jelenik meg trigger, ha a bemenetén az előző inputhoz képest más adat jelenik meg.
Logging
Innentől már nincs nehéz dolgunk, csak be kell kötni a change4_1.nonzero kimenetet a d30s_4_1 30 másodpercre állított delay komponensbe, akinek az out kimenetével indíthatjuk a naplózást.
Analog poll
Az analóg input olvasásán is változtatni kellett. Egyrészt a 10 perces kérések helyett másodpercenként kérdezzük le a modult (ezért bökdösi a p1s 1 másodperces Pulsar komponens a wap analóg input poll generátort a korábbi sched10min 10 perces trigger helyett), másrészt az ai1 analóg input választ feldolgozó komponens lábait a közvetlen naplózás helyett a temp1..temp4 Value komponensekbe kötögettem. A temp1..temp4 value komponensek tárolják a mért értékeket, a kimenetük indítja meg a bennük levő érték naplózását, amit az sql1_1..sql1_4 Shell komponensek végeznek el. A temp1..temp4 komponensekből az első hármat a sched10min 10 perces időzítő triggereli, míg a negyediket (amiben a solar folyadék hőmérsékletét tároljuk) a di4_1.out1 komponens kimeneten megjelenő 0->1 érték változás indítja.
Extras
Ha már egyszer detektálom a szivattyú indulását (és leállását is, hiszen a change4_1 komponens mindkét állapotváltozást megadja), akkor ezt is simán lehet naplózni – erre való a change4_1 zero és nonzero lábaira kötött log_solar_pump komponens. Innentől a következő hibánál nincs vita, hogy mikor indította el a solar vezérlés a szivattyút.

Szummárium

Hétvégén megcsinálom a hardveres részt is, aztán még készül hozzá egy olyan diagram, ami a solar kör hőmérő által mért értékeket együtt mutatja a keringtető szivattyú állapotváltozásával és onnantól már kellőképpen felvegyverkezve várom a következő hibát.]]>

Kismalac, kismalac, let me in!

Na de a telefon nem szólt, hogy csengettek… 🙂 írta ma Ákos nekem. Summa summarum, ma telefonos kapucsengőt szerelünk. Sokszor előjött már a probléma, hogy a lakásban levő csengőt nem halljuk, amikor kint vagyunk a kertben, sőt ez még inkább gond, ha épp valahol a városban bócorgunk és egy futár épp megáll az ajtó előtt. Mivel a kapucsengő is csak egy mezei kontaktus, ami a homeaut serverben egy digitális input formájában jelenik meg, így nem nagy dolog az egészet bárhová elirányítani. A bejáratot látja egy IP kamera is, úgyhogy akár meg is nézhetjük, ki tenyerelt rá a csengőre. Mindezekből a következő recept állt össze:

  • a csengő megnyomása generáljon egy push notificationt a fiúk és eFi telefonjára
  • a push üzenetből azonnal el tudjak navigálni abba az iOS alkalmazásba, amin látom a bejárati IP kamera képét
  • egyúttal tegyük el a kameraképet egy network storage-ra, plusz küldjük el eFinek emailben
  • mindezt tegyük védetté a csengőt N alkalommal kényszeresen egymás után megnyomókkal szemben
Az iOS oldalhoz az alapot két alkalmazás szolgáltatta: az IP kamera képét mutató IP Cam Viewer Pro, valamint a user által gyártott push notifikációk küldözgetésére kitalált Pushover. Az ismétlődő csengetés elleni védelmi logika simán maradhatott volna a dataflow homeaut serverben (mindössze egy Delay és egy Blocker komponens kell a megvalósításához), ám valami miatt ez később jutott eszembe és így beledolgoztam az egész folyamatot levezénylő shell scriptbe – íme:
#!/bin/bash
lastrun () {
	TESTFILE="./kapucsengo.timestamp"
	if [ -e $TESTFILE ]
	then
		LASTRUNDATE=`date +%s -r $TESTFILE`
	else
		LASTRUNDATE="0"
	fi
	NOW=`date +%s`
	DIFF=$((NOW-LASTRUNDATE))
	touch $TESTFILE
	return $DIFF
}
MIN_REPEAT=30 # 30 másodpercen belül nem reagálunk újra
lastrun
LR=$?
if [ $LR -gt $MIN_REPEAT ]
then
	# ask pushover.net to send notification
	curl -s \
	  -F "token=MY_PUSHOVER_TOKEN" \
	  -F "user=MY_PUSHOVER_USERID" \
	  -F "message=CSENGETTEK" \
	  -F "title=ihome - r9" \
	  -F "url=ipcamviewer://launch?groupName=kapucsengo" \
	  -F "url_title=View cameras" \
	  https://api.pushover.net/1/messages.json 2>&1 /dev/null
	# save streetcam image on ring
	NOW=`date +%Y%m%d_%H%M%S`
	curl -u CAM_USER:CAM_PASS http://cam_url/cgi-bin/viewer/video.jpg >/media/cam_offline/$NOW.jpg
	cp /media/cam_offline/$NOW.jpg /media/camstorage/kapucsengo/
	/usr/bin/mpack -s "Csengettek - r9" /media/cam_offline/$NOW.jpg EFI_EMAIL_ADDRESS
	find /media/cam_offline/* -mtime +365 -exec rm{} \;
	exit 0
else
	# Repeated call within $MIN_REPEAT seconds - script cancelled
	exit 1
fi
A fenti scriptet egy Shell komponens indítja el, amint megjön a kapucsengő digitális bemenetén a kontaktus. A script megnézi, hogy utoljára 30 másodpercnél később indult-e és ha igen, teszi a dolgát:
  • szól a curl-nak, hogy küldjön a pushover.net felé egy notifikációs üzenetet JSON formátumban
  • szintén a curl-t kéri meg, hogy cibálja le az IP kamerából az épp látott képet
  • felmásolja az előbb letöltött képet a NAS-ra
  • megkéri az mpack binárist, hogy küldje el nekem a fotót attachmentben
  • végül a lokális storage-ből törli az esetlegesen meglevő, 365 napnál régebbi kameraképeket
Nálam a homeaut server csillió más dolgot is csinál, így kézenfekvő volt simán beleintegrálni az ő workflowjába a feladatot. Ha te csak egy “telefonálós” kapucsengőt szeretnél, az sem rocket science: elég egy Raspberry Pi, annak egy GPIO portja és egy Python script, hogy az egészet levezényeld, pont úgy, ahogy maandag megírta a blogján tegnapelőtt.]]>

Home automation a New Tech Meetupon: part 2/2

múltkori “homeaut dióhéjban” előadás után az általunk gyártott rendszer technikai megvalósításának demóját így sikerült összeraknunk szerdán 2*5 percben:

Dataflow from Budapest New Tech Meetup on Vimeo.

Ern0 elképesztő sebességgel beszélt, a dataflow témát szinte esélytelen ebben a formában átadni, mégis megpróbálta. Jól látszott az infoshock hatása az előadás végén: mindössze egy ember kérdezett, mindenki más csak kamillázott ezerrel 🙂 ]]>