Obgleich wir uns hin und wieder darüber unterhalten hatten, war das Weihnachtsgeschenk, das das Partnerdings mir überreichte, eine echte Überraschung: ein RaspberryPi B+ mit WLAN-Adapter, MicroSD-Karte und der c’t Wissen »Smart Home«. Ich war (und bin!) hin und weg! Installiert war die kleine Kiste schnell, und ich begann, mit openHAB-1.6.1 zu spielen.
Es hat einen gewissen Suchtfaktor, das gleich vorweg. Ich richtete uns eine Radio-Station ein, die wir per Handy (via openHAB-App) bedienen können. Parallel dazu recherchierten wir, was die weitergehende Technik angeht, und entschieden uns, den Einstieg mit Homematic zu machen. Zwischenzeitlich zeigte sich die Himbeere leicht überfordert von meiner openHAB-Installation — das Durchstarten dauerte gute zehn Minuten, was das Testen zur Geduldsprobe werden lies, und die Java Heap Space-Fehlermeldungen häuften sich. Kurzerhand transportierte ich meine Konfiguration auf den Mac, aktualisierte dort meine Java-Installation (auf 1.8.0_25). Dort läuft erwartungsgemäss alles bedeutend flüssiger, jedoch nicht unbedingt stabiler.
Grundsätzliche Überlegungen
Auf lange Sicht würde openHAB dazu dienen, die verschiedenen Techniken unter einen Software-Hut zu quetschen, denn nicht alles, was wir umsetzen möchten, ist mit Homematic machbar. Für den Einstieg entschied ich mich dann für die Anschaffung einer CCU2, einer Steckdose und eines Tür-/Fenstersensors für den Innenbereich. Die CCU2 übernimmt (zumindest überwiegend) die eigentliche Logik, und openHAB dient eher der Darstellung und zum Experimentieren.
Viele Aktionen stehen in direktem Zusammenhang dazu, ob zumindest einer von uns zu Hause ist. Doch wie setze ich eine Anwesenheitserkennung um? RFID wäre eine technische Machbarkeit, die kostet allerdings wieder zusätzlich. Unsere iPhones hingegen tragen wir eigentlich immer bei uns. Bluetooth scheidet aus, da die Reichweite zu gering ist (die Akku-Laufzeit spielt da inzwischen tatsächlich eine eher untergeordnete Rolle). Eine App, die das Ganze per GPS abfragt, kostet ziemlich viel Kohle und saugt dem iPhone den Akku leer. Aber WLAN? Ist das Gerät im heimischen WLAN eingebucht, ist es zu Hause, also ist in der Regel auch der Besitzer zu Hause. Ein Ansatzpunkt.
Nun haben gerade die iPhones die in diesem Zusammenhang ärgerliche Eigenschaft, im Sperrbildschirm das WLAN zu deaktivieren — das spart Energie und ist auch keine Option, an der sich etwas ändern liesse (es sei denn, man entscheidet sich für Jailbreak — wozu ich aber keine Lust hatte). Es macht auch keinen Unterschied, ob man WLAN-Sync aktiviert oder nicht, ob man Mobile Daten aktiviert oder nicht — wenige Sekunden, nachdem das Display sich abgeschaltet hat, läuft jeglicher ping ins Leere.
Bei vernünftigen Routern hat man die Möglichkeit, SNMP-Abfragen zu initiieren — wir haben für unser VDSL jedoch einen dummen Speedport, der kann sowas nicht. Und auf ether-wake reagiert das iPhone wiederum nicht. Die Logik lässt sich jedoch umdrehen: alles, was das Display des iPhones kurz angehen lässt, »weckt« auch das WLAN. Und was im Sperrbildschirm angezeigt werden darf, konfiguriert man ja wiederum im iPhone.
Über openHAB hat man da ziemlich viele Möglichkeiten: so hat unser Haus einen XMPP-Account »haus« und lässt, wenn es gut drauf ist, mit sich chatten. Es hat inzwischen auch einen geschützten Twitter-Account und kann uns Direktnachrichten senden. Direktnachrichten wiederum erscheinen auf meinem Sperrbildschirm, das WLAN geht an und… ihr versteht. Theoretisch könnte man es vielleicht sogar per Mail lösen, aber das ist dann wieder zeitkritisch, man müsste minütlich Mails checken — auch doof. Da ich alles innerhalb der CCU2 lösen wollte, habe ich mich für Prowl entschieden — die App ist nicht kostenfrei, ich nutzte den Dienst aber vorher schon (ebenso wie Growl auf dem Mac) und mag ihn. In meinem Account legte ich mir einen API-Key namens »openHAB« für genau diese Zwecke (im weitesten Sinne) an.
Also wie? Der Dienst sendet den iPhones eine Nachricht; die Displays gehen an, das WLAN erwacht, ein ping liefert jeweils ein Ergebnis. Wie oft tut man das? Alle 10 Minuten? Alle 30 Minuten? Wie lästig! Aber: wir verlassen das Haus in der Regel durch die Haustür, durch die Fenster gehen wir eher selten :D Also lässt sich die Aktion mit dem Türsensor koppeln: bei Aktivität wird geprüft. So, und jetzt genug gelabert, jetzt mal…
… die Umsetzung
Ich startete damit, dass ich für jedes iPhone eine binäre Systemvariable in der CCU2 anlegte (Einstellungen => Systemvariable => Neu): phone-ms und phone-rj — true bedeutet »anwesend«, false bedeutet »nicht anwesend«. Und weil ich faul bin, definiere ich darüber hinaus noch Anwesenheit, die auf true geht, sobald irgend jemand von uns zu Hause ist — weitere Aktionen kann ich dann von der Anwesenheit-Variable abhängig machen und muss nicht immer alle Telefone (die Kinder werden potentiell auch irgendwann welche haben) abklappern. Die aktuellen Werte der Variablen lassen sich in der CCU2 über Status und Bedienung => Systemvariable abrufen.
Im nächsten Schritt habe ich dem Ereignis »Türsensor wird ausgelöst« Aktion zugewiesen: es könnte ja sein, dass einer von uns nach Hause kommt, sprich schon im Flur steht — also wird direkt ein ping abgesetzt und der der Variablen der entsprechende Wert zugewiesen. Bringe ich nur kurz den Müll raus, wird zwar geprüft, mein Status bleibt aber auf »anwesend«. Verlasse ich hingegen das Haus, muss ich erst das Auto einladen, die Kinder anschnallen — je nach Bockigkeit der Kinder dauert das variabel lange, ich weiss aber, dass ich nach spätestens 10 Minuten die Schnauze voll habe, und deshalb lasse ich den Status danach erneut testen. Ich trenne dabei das Absenden der Prowl-Message und das Pingen zeitlich voneinander, da es zu falschen Ergebnissen führt, wenn die iPhones noch nicht »aufgewacht« sind.
Das Script zum Versenden der Prowl-Nachricht sieht so aus (Obacht bei Umlauten!):
string stdout; string stderr; string text; text = "was ist da an der Haustuer der ELW los?"; system.Exec("wget -q -O /dev/null 'http://prowl.weks.net/publicapi/add?apikey=<YOUR_API_KEY>&application=<YOUR_APPLICATION_NAME>&priority=1\&description=fragt%20sich%20" # text # "' ", &stdout, &stderr); |
Das Script zum Pingen unserer Kisten sieht so aus — die iPhones haben natürlich feste IPs und beziehen sie nicht mehr dynamisch per DHCP:
string stderr; string stdout; integer phonems; integer phonerj; system.Exec("ping -c 1 192.168.2.4",&stdout, &stderr); phonems = stdout.Find("ms"); system.Exec("ping -c 1 192.168.2.5",&stdout, &stderr); phonerj = stdout.Find("ms"); if ( phonems == -1 ) { dom.GetObject('phone-ms').State(0); } if ( phonems > 0) { dom.GetObject('phone-ms').State(1); } if ( phonerj == -1 ) { dom.GetObject('phone-rj').State(0); } if ( phonerj > 0) { dom.GetObject('phone-rj').State(1); } |
Und das Ganze habe ich dann als CCU2-Programm zusammengefügt und zeitlich in Reihenfolge gebracht (Programme & Verknüpfungen => Programme und Zentralenverknüpfung => neues Programm iPhoneWakeUp anlegen, vgl. Screenshot). Und auch das Setzen der Anwesenheits-Variable ist solch ein Programm.
Das hat nun den Charme, dass, wenn die Haustür geöffnet und anschliessend keines unserer iPhones entdeckt wird, wir eine entsprechende Warnung erhalten können: im günstigsten Falle hat lediglich jemand das Haus betreten, der einen Schlüssel dazu hat, im schlimmsten Falle wäre es ein Einbruch — oder der WLAN-Router ist kaputt, das WLAN am iPhone ist ausgeschaltet oder kaputt… *lach*. Okay, eine Alarmanlage davon abhängig zu machen wäre… mutig.
Saisonal bedingt wollte ich dann gerne die Weihnachtsbaumbeleuchtung automatisieren: ist jemand zu Hause, darf sie brennen — aber nicht in der Zeit zwischen 21h00 und 7h00. Ist niemand zu Hause, soll sie natürlich auch aus sein. Es ist völlig gestört, wie gut das funktioniert, es ist schlimm, wie faul man wird, und die Grenzen zwischen nützlicher Automatisierung und kompletter Überwachung sind ziemlich fliessend: so ist ein Hinweis, dass es nun regnet und noch ein Dachfenster offen ist, grundsätzlich sehr nützlich — wohingegen das automatische Abschalten jeglicher Beleuchtung in den Kinderzimmern nach 19h00 schon sehr »überwachend« wäre. Technisch ist unglaublich viel möglich.
openHAB kommt ins Spiel
Ich habe dann openHAB an die CCU2 angeknüppelt; in der openhab.cfg ist da nicht viel Zauber notwendig (den Host ccu2 habe ich zuvor fest in die /etc/hosts eingetragen und das entsprechende JAR-File nach $OPENHAB/addons geschoben):
############################### Homematic Binding ##################################### # homematic:host=ccu2 # homematic:callback.host=auto-discovery # homematic:callback.port=9123 # homematic:alive.interval=300 |
Im Ordner $OPENHAB/configurations/transform habe ich das File anwesenheit.map hinterlegt — es »übersetzt den jeweiligen Status fürs Webinterface:
true=anwesend false=nicht anwesend -=undefiniert |
Dann hinterlege ich eine Item-Definition in $OPENHAB/configurations/items/$MEIN_ITEM_FILE.items:
// Wer ist gerade zu Hause? Group Mobiltelefone <cellular> String Phone_MS "Marianne [MAP(anwesenheit.map):%s]" (Mobiltelefone) { homematic="variable=phone-ms" } String Phone_RJ "Rainer [MAP(anwesenheit.map):%s]" (Mobiltelefone) { homematic="variable=phone-rj" } |
Und hinterlege in meiner Sitemap-Definition ($OPENHAB/configurations/sitemaps/$MEIN_SITEMAP_FILE.sitemap)die benötigten Angaben:
Frame label="Kram" { Group item=Mobiltelefone { Text item=Phone_MS Text item=Phone_RJ } } |
Diese Werte kann man sich nun wiederum hier abgreifen, wenn man scharf darauf ist, und weitere Aktionen durchführen: twittern, jabbern, Mails verschicken, Alarme auslösen… ich stehe ganz am Anfang.
Nun ist es jedoch so, dass die Werte sich ja in der CCU2 ändern, nicht im Webinterface; greift man an dieser Stelle nicht ein, zeigt openHAB also irgendwann falsche Werte an. Hier ist sehr gut erklärt, wie mittels einer »Virtuellen Fernbedienung« der CCU2 eine Synchronisierung erzwingen kann.
Und wohin geht die Reise?
Es wird noch eine ganze Weile dauern, sich die Basics hinreichend zu Gemüte zu führen. Die ganz kritischen Punkte des (grossen und etwas unübersichtlichen) Hauses sollen schon gesichert werden — beide Haustüren, das Notausstiegsfenster, die Rauchmelder — aber wie genau ist noch unklar. Ich habe gesehen, dass es Sensoren für Blumentöpfe gibt — aber möchte ich wirklich von meinem Kaktus eine Mail mit Subject »Giess mich!« erhalten? Man könnte einen Sensor an den Briefkasten fummeln und einen Tweet »Da hat grad jemand was reingesteckt!« erhalten. Regensensoren, Wetterstation (okay, die interessiert mich wirklich!), Dimmaktoren, Heizungsthermostate, Bewegungsmelder… mal schauen, was uns das Leben tatsächlich erleichtern könnte.
Pingback: OpenHAB und Twitter · /sys/adm/ama
Supergeil!! Ich bin fasziniert – las ich doch gerade eben hier auch über sowas :).