Az előző Openhab-os post-ban a ping parancs segítségével állapítottuk meg, hogy egy adott eszköz elérhető-e a hálózaton, vagy sem. Ezzel a gyakorlati használat során több probléma is adódott. Példának okáért a telefonok teljesen ad-hoc módon eldobják a wifi jelet. Arról nem is beszélve, hogy az ‘{ exec=”<[‘ típusú változók a megadott polling intervallumon belül mindig frissülnek, aminek következtében az event log szépen szemetelődik a “Sh_VojiPcIsUp state updated to ON” üzenetekkel, akor is, ha nem változott semmi, az előző állapothoz képest.
Ha az IP cím és a wifi kapcsolat nem használható az aktuális helyünk meghatározására, akkor nem marad más, mint a GPS pozíció. Szerencsére ez az ötlet már másnak is eszébe jutott, és el is készítette az OwnTracks nevű alkalmazást. Az alkalmazás pont annyit tud, mint amire nekünk szükségünk van, időnként elküldi az aktuális helyzetünket, egy megadott címre.
Az első ilyen buktató, amibe belefutottam a HTTP alapú működés. Itt van fekete fehéren, hogy aki nem akar az MQTT-vel szívni (én pedig nem akartam, mert azt sem tudtam mi az, és úgy is rég php-ztem, gondoltam itt a remek alkalom, hogy kicsit újra elővegyem) annak készítettek egy szuper HTTP módot.
Ezen, és az ott látható példa POST híváson annyira fellelkesedtem, hogy telepítettem gyorsan egy apache-ot, beállítottam a plain http security-t (+ a fail2ban-t, amiről remélem Ti sem feledkeztek meg soha ha plain security-t használtok), készítettem php oldalt, ami megetetve a REST kéréssel tovább postolta azt az OpenHab rest api-nak…
Ami elkerülte a figyelmemet, az az oldalon lévő táblázat, ahol valami ilyesmi szerepel:
_typeiOS Android Usage locationY – Can return friend location objects.
Az egész oldalon a “-” jelnyi szó esik arról, hogy bármilyen szuper is ez a HTTP alapú kommunikáció, android-on sajna még nem csinálták meg. Én sajnos nem ebből jöttem rá, hanem abból. hogy bármennyire is kerestem ezt az opciót, nem találtam az alkalmazásban, és eztán egy forum post-ból, ahol éppen azon örömködnek, hogy mekkora királyság lesz ez a HTTP mode, és odaírták, hogy az Androidos verzió majd lesz… Amikor a “Spread the word, and tell us what you think about it” résznél tartottam, nagyon nagy önuralomról tettem tanúbizonyságot, hogy ennyi felesleges ráfordítás után sem írtam oda a véleményem.
Na de ne ragadjunk le a részleteknél, ha nincs HTTP mód, akkor csak az MQTT mód van, bármi legyen is az, jó ötletnek tűnt arra indulni. Az előzmények eltakarítása után (sok apt-get remove, és rm) el is jutottam a konklúzióig, hogy az MQTT egy message bróker, üzenetet lehet beküldeni, és aki fel van rá iratkozva, annak a kapott üzeneteket továbbküldi. Jan-Piet Mens aki a profilképén pont úgy néz ki mint egy shaolin pap (na nem mintha bármi bajom lenne a shaolin papokkal) egész érdekes dolgokkal foglalkozik. Többek között készített telepítési leírást az MQTT brókerhez Raspberry-hez, ami alapján a mosquitto-t én is telepítettem. A leírásban hivatkozott mosquitto-setup.sh-t is használtam, de azért ezzel óvatosan, nekem nem kicsit kusza beállításokat generált.
Telepítés után azok a dolgok amiket módosítottam a mosquitto configban:
- Minden esetben kérjünk jelszót: allow_anonymous false
- A jelszavakat itt tároljuk: password_file /etc/mosquitto/passwd
- Kicsit visszavettem a logolásból, mert a debug azért túlzásnak tűnt: #log_type debug
- Kulcsok helye, amit nem sikerült valami jól eltalálni elsőre
- A titkosítás nélküli listener beállításait: listener 1883 127.0.0.1 ezt módosítottam: listener 1883
Az utolsó lépés nálam azért releváns, mert a szervert két helyről lehet elérni. LAN-on használható a 1883 port, ahol nem szükséges a titkosított adattovábbítás, kiajánlásra pedig úgyis csak a 8883 port kerül, ahol követelmény.
Ezután még létre kell hozni felhasználókat, melyre a mosquitto_passwd nevű programot használhatjuk, valahogy így:
sudo mosquitto_passwd /etc/mosquitto/passwd testuser
A gyors konfiguráció után el is érkezett az ideje a tesztelésnek. Ezt a legegyszerűbben úgy tehetjük meg, hogy feliratkozunk a friss mqtt brókerünk várva várt eseményeire, és megnézzük, hogy érkeznek e. Ehhez első körben be kell állítani az OwnTracks alkalmazást,de ott nincs sok bonyodalom, megadjuk az ip címet, a felhasználói adatokat, és a szerveren generált ca.crt-t.
A sikeres beállítás után el is post-olja az alkalmazás az aktuális pozíciónkat, amit a képen pirossal keretezett ikon segítségével igény szerint tetszőleges számban megismételhetünk.
Az eseményekre történő feliratkozás a szerveren:
mosquitto_sub -t ‘owntracks/#’ -d -u testuser-P aaaaa
Sikeres üzenet fogadása esetén ilyesmit kell látnunk:
Client mosqsub/22511-raspberry received PUBLISH (d0, q0, r1, m0, ‘owntracks/voji/voji_phone’, … (109 bytes))
{“_type”:”location”, “lat”:99.4484811, “lon”:99.9012079, “tst”:1458742457, “acc”:30, “batt”:68, “t”:”u”, “tid”:”ne”}
Ha már küldjük a szerverre az adatokat, érdemes lehet ezeket menteni is, hogy igény esetén vissza is tudjuk nézni, mikor merre jártunk, beazonosíthassuk a frekventált területek koordinátáit (vagy segítségével megkereshessük az elhagyott telefonunkat).
Erre az ot-recorder nevű alkalmazást érdemes használni, ami szintén az owntracks projekt része és elég jól használható, lekérdezhető. A telepítését nem kell túlbonyolítani, egy egyszerű apt-get-tel megoldható. Az indítása már keményebb dió, alapból nem készül hozzá init.d script, én pedig lusta voltam demonizálni, így nálam cron-ból indul.
Az indítást végző sh fájl:
#!/bin/sh export OTR_USER="otrecorder" export OTR_PASS="****" /usr/local/sbin/ot-recorder --http-host 192.168.1.11 --http-port 8083 'owntracks/#' &
A crontab bejegyzés:
@reboot /home/openhab/scripts/ot-rec.sh
A sikeres indítás és üzenetelvétel után elviekben láthatóvá vállnak az adatok a fenti címen.
Ha ez működik, akkor innen már egyszerű dolgunk van, el kell érnünk, hogy az openhab-ban is megjelenjenek ezek a pozíciók. Itt két irányban indulhatunk el. Ha csak arra van szükségünk, hogy valaki egy adott helyen tartózkodik e vagy sem, akkor használhatjuk az openhab számára készített Mqttitude Binding-et.
Én (vesztemre) ennél egy kicsit komplexebb dolgot képzeltem el, amiben fontos szerepe van az adott helytől történő távolságnak, és a mozgás irányának. Ezt oly módon tudjuk megvalósítani, hogy az Mqttitude binding helyett a sima mqtt bindinget használjuk. így ugyan nekünk kell az üzenetet parse-olni, távolságokat méregetni, státuszokat állítani, de bárki beláthatja, hogy minden ezzel töltött perc megtérül (nem).
Szóval akkor haladjunk sorjában, nézzük először a működéshez szükséges item-ek listáját:
Switch locSomeAtHome "Someone at home [%s]" &amp;amp;lt;house&amp;amp;gt; (S_Location)
String mqttPositionVoji "Voji Location Raw Data" { mqtt="&amp;amp;lt;[rpi:owntracks/voji/voji_phone:state:default]" }
Location locVoji "Voji Location" (S_Location, T_LocationMaps)
Number locVojiDistFromHome "Voji distance from home [%.1f m]" (S_Location)
Switch locVojiAtHome "Voji at home [%s]" &amp;amp;lt;phone&amp;amp;gt; (S_Location)
Itt a mqttPositionVoji a lényeges, ide érkezik az OwnTracks által küldött lokáció. A többi változó csak a számított értékek tárolására szolgál.
A kapcsolódó szabályok:
/*
* process mqtt location message
*/
val org.eclipse.xtext.xbase.lib.Functions$Function1 processLocationMsg = [
StringItem mqttLocationMsg |
val PointType homeLocation = new PointType("99.4484713,99.9011735")
val int homeRange = 100
val String userName=mqttLocationMsg.name.substring(12)
val String locItemName="loc"+userName
val String distanceItemName=locItemName+"DistFromHome"
val String locAtHomeItemName=locItemName+"AtHome"
val LocationItem locationItem = S_Location.members.findFirst[ name.equals(locItemName) ] as LocationItem
val NumberItem distanceItem = S_Location.members.findFirst[ name.equals(distanceItemName) ] as NumberItem
val SwitchItem atHomeItem = S_Location.members.findFirst[ name.equals(locAtHomeItemName) ] as SwitchItem
val String json = (mqttLocationMsg.state as StringType).toString
/*
* {"_type":"location","lat":99.4484713,"lon":99.9011735,"tst":1458648216,"acc":33,"batt":27,"tid":"ne"}
*/
val String type = transform("JSONPATH", "$._type", json)
if (type == "location") {
val String lat = transform("JSONPATH", "$.lat", json)
val String lon = transform("JSONPATH", "$.lon", json)
/*val String acc = transform("JSONPATH", "$.acc", json)
val String batt = transform("JSONPATH", "$.batt", json)*/
val PointType locationPoint = new PointType(lat + "," + lon)
if (locationItem!=null) {
locationItem.postUpdate(locationPoint)
} else {
logInfo("System", "Unable to update location, because item not found: " + locItemName)
}
val DecimalType homeDist = homeLocation.distanceFrom(locationPoint)
logInfo("System", "Updating location: " + userName + " Dist: " + homeDist.doubleValue)
if (homeDist&gt;homeRange) {
atHomeItem.postUpdate(OFF)
} else {
atHomeItem.postUpdate(ON)
}
if (distanceItem!=null) {
distanceItem.postUpdate(homeDist)
} else {
logInfo("System", "Unable to update distance, because item not found: " + distanceItemName)
}
} else {
logInfo("System", "Unknown location message. Type: " + type)
}
true
]
rule "MqttLocationChanged"
when
Item mqttPositionVoji changed
then
processLocationMsg.apply(mqttPositionVoji)
end
</pre>
Itt a mágia a processLocationMsg XBase funkcióban történik. A kapott String mqtt üzenetből kihámozzuk az aktuális lokációt (lat, lon), amit elrakunk egy PointType típusú változóba, és a kapott értékek alapján számolgatunk kicsit (például otthontól mért távolságot).
A funkciók használata során még annyi változás történt, hogy meguntam a paraméterek használatát, így egy változóhoz tartozó egyéb változókat név alapján próbálom előkeríteni. Ezáltal csak a megfelelő névkonvenciót kell tartani, és elég egy paramétert átadni a függvénynek.
És amikor azt hittem, hogy vége, azt tapasztaltam, hogy valamiért az egész mégsem működik. Olyan ötven méter után egy lokáció report sem érkezett meg. Mint kiderült ennek a T-Com által árult csoda Speedport W 724V dsl modem az oka. Ugyanis ha egy olyan dns bejegyzéssel találkozik, ami a külső lábára mutat, akkor azt meg sem próbálja belső címre fordítani, hiába van rá port forward szabály. Ezen a problémán sokat gondolkoztam, nem akartam a teljes belső hálózatomat feltúrni. A megoldás végül az lett, hogy a raspberry-re telepítettem egy dnsmasq csomagot, ami egy dhcp szerver, és egy dns forwarder, amit rendesen lehet konfigurálni. A modemen kikapcsoltam a dhcp-t, de gateway továbbra is maradt ő, és a dns fordításnál megadtam szabálynak, hogy ha belső hálózatról a szerver dns-ére hivatkoznak, akkor annak a belső ip címét adja meg.
A kapcsolódó dnsmasq config:
bogus-priv no-resolv server=8.8.8.8 server=8.8.4.4 no-hosts dhcp-range=192.168.1.50,192.168.1.150,12h dhcp-range=192.168.1.1,192.168.1.49,static,255.255.255.0,infinite dhcp-option=3,192.168.1.254 dhcp-option=option:router,192.168.1.254 dhcp-authoritative address=/speedport.ip/192.168.1.254 address=/home.server.hu/192.168.1.10 address=/mqtt.server.hu/192.168.1.11 dhcp-host=ff:ff:a5:6f:ff:ff,voji-pc,192.168.1.30 dhcp-host=ff:ff:23:28:ff:ff,milight,192.168.1.20
Az openhab projekt a fűtés miatt jelenleg romokban van, de hamarosan jön az újabb, felturbózott verzió.
