Auf ifttt.com klickt der User einfach Home-Automation-Komponenten wie den Ein/Aus-Schalter von WeMo zusammen, statt sie mühselig selbst programmtechnisch zu integrieren.
Fährt bei einem aufziehenden Gewitter wie von Geisterhand am Haus die Außenjalousie hoch, ist klar: Aha, Home-Automation am Werk [2]. Leider ist es aber gar nicht so einfach, die einzelnen Komponenten in einem Smart Home zu einem Gesamtsystem zu integrieren, da viele Hersteller ihr eigenes Süppchen kochen, das absichtlich geschmacklich nicht zur Konkurrenz passt.
Neulich kaufte ich aus einer Laune heraus den Fernschalter der Firma WeMo Switch (Abbildung 1), der sowohl mechanisch als auch mittels mobiler Telefon-App, entweder übers heimische WLAN oder gar übers offene Internet elektrische Verbraucher ein- und ausschaltet.
| |
| Abbildung 1: Der WeMo-Switch verspricht schnurloses Einschalten von Elektrogeräten mittels mobiler App. |
 |
| Abbildung 2: Die WeMo-App schaltet den Schalter übers WLAN oder das Internet ein und aus. |
Zur Installation erzeugt der Fernschalter nach dem Einstöpseln in die Steckdose sein eigenes WLAN mit der Kennung "WeMo-xxx". Lädt der User dann die mobile App für iOS (Abbildung 2) oder Android aufs Smartphone herunter und nordet dessen WLAN auf das temporäre WeMo-WLAN ein, verbindet sich die App mit dem Fernschalter und fordert anschließend den User auf, die SSID und das Passwort des heimischen WLANs einzugeben. Die App schickt die Daten dann an den Minicomputer im Schalter, der daraufhin über das heimische WLAN aufs Internet zugreift und sich selbständig beim Belkin-WeMo-Service anmeldet. Keinerlei Registrierung per Email ist erforderlich, alles läuft anonym ab. Die App kommuniziert dann mit dem Fernschalter entweder übers WLAN oder, falls das Telefon außerhalb dessen Reichweite ist, über den Belkin-Service auf dem offenen Internet (Abbildung 3).
 |
| Abbildung 3: Über einen Server auf dem offenen Internet kommunizieren Smartphone App und der hinter einer Firewall befindliche WeMo Switch miteinander. |
 |
| Abbildung 4: Auf Amazon.de kostet der WeMo-Switch etwa 45 Euro. |
Statt nun bloß mechanisch auf der Telefon-App herumzutippen, bietet es sich an, den Schalter programmatisch auszulösen. Wer nimmt schon gerne die Hände von der Tastatur, nur um das Licht anzumachen? Aber im Ernst: Erst durch die Verknüpfung des Schalters mit Sensoren im Haus und etwas Logik entsteht ein sogenanntes Smarthome, das zum Beispiel nur dann das Licht im Carport anschaltet, wenn es dunkel ist und das Blutooth-Signal des Smartphones des Hausherrn sich nähert.
Der WeMo-Schalter betreibt einen kleinen Webserver auf dem WLAN, den
ein einfaches Perl-Skript wie in Listing 1 durch HTTP-Abfragen zum
Umlegen des mechanischen Schalters überreden kann. Dazu nutzt es das
CPAN-Modul Power::Outlet::WeMo, dessen Konstruktor die IP-Adresse des
Schalters im WLAN entgegennimmt und anschließend mit den Methoden
on() und off() hinter den Kulissen als HTTP-Client mit dem
lokalen Server redet. Weiter unterstützt das Modul die Methoden switch()
(zum Umschalten in den entgegengesetzten Zustand), sowie query zur
Abfrage des aktuellen Zustands. Das Ganze ließe sich auch recht einfach
über einen simplen Webclient erledigen, aber das Modul abstrahiert die
zugrundeliegenden URLs und erlaubt so bequeme und saubere Programmierung.
01 #!/usr/bin/perl -w
02 use strict;
03 use Power::Outlet::WeMo;
04
05 my $lamp = Power::Outlet::WeMo->new(
06 host => "192.168.1.139" );
07
08 $lamp->on;
09 sleep 1;
10 $lamp->off;
Da der WLAN-Router dem Schalter die IP-Adresse dynamisch zuweist, bietet es
sich an, jenem per Einstellung beizubringen, an anfragende Geräten mit der
MAC-Adresse des Schalters immer die gleiche IP via Static Lease zu vergeben.
Aber da der Schalter das
UPnP-Protokoll implementiert, kann das Skript in
Listing 2 die IP-Adresse auch mit dem
CPAN-Modul Net::UPnP::ControlPoint herausfinden. Als "Search Target"
spezifiziert das Skript mit dem Parameter st und dem Wert
"upnp:rootdevice", dass es an allen Root-Devices im Netz interessiert ist.
Mit dem Parameter mx und dem Wert 3 gibt es die maximale Wartezeit
von 3 Sekunden vor, bis sich ein Gerät meldet oder das Skript abbricht.
In meinem Netz zuhause befand sich zum Testzeitpunkt nur ein UPnP-Gerät,
und die Ausgabe in Abbildung 5
zeigt unter anderem, dass die UPnP-Abfrage den Webserver des Schalters auf IP
192.168.1.139 gefunden hat.
Da der Schalter sich nicht nur über Steuerungsgeräte im lokalen LAN betätigen lässt, sondern auch übers Internet, überwindet das Gerät die NAT-Firewall des heimischen Routers, in dem es das STUN-Protokoll mit einem Belkin-Server auf dem Internet spricht. Das ist natürlich sicherheitstechnisch nicht unbedenktlich, denn ein kleiner Fehler in der Implementierung erzeugt so plötzlich ein riesiges Darknet an fernsteuerbaren elektrischen Geräten über das offene Internet ([5]). Vom Betreiben kritischer Komponenten wie Boden-Luft-Abwehrsystemen, Saunaheizungen oder Zahnarztbohrern muss daher abgeraten werden.
01 #!/usr/local/bin/perl -w
02 use strict;
03 use Net::UPnP::ControlPoint;
04
05 my $upnp = Net::UPnP::ControlPoint->new();
06
07 my @devices = $upnp->search(
08 st => 'upnp:rootdevice',
09 mx => 3 );
10
11 foreach my $device (@devices) {
12 print $device->getdevicetype(), "\n";
13 print $device->getfriendlyname(), "\n";
14 print $device->getssdp(), "\n";
15 }
 |
| Abbildung 5: Das Skript lanciert eine UPnP-Abfrage im WLAN und findet den WeMo-Switch auf IP 192.168.1.139. |
Ein gravierender Nachteil des Geräts ist offensichtlich, dass es überflüssigerweise schon wieder ein völlig neues proprietäres Protokoll benutzt. Das ist leider die Norm unter den Heim-Automation-Produkten, die folglich nur mit den meist nicht sonderlich originellen Apps des Herstellers zusammenarbeiten, weil die Open-Source-Community in die Röhre schaut.
 |
| Abbildung 6: Der Service auf ifttt.com löst Aktionen aus, wenn vordefinierte Ereignisse eintreten. |
Aber zum Glück hat sich die hippe Internetfirma ifttt.com aufgemacht, diesen Protokollwirrarr zu abstrahieren und für ihre User unter dem Motto "If This then That" durch einfaches Menüklicken logische Verknüpfungen zwischen Ereignissen herzustellen, deren Integration in der rauhen Wirklichkeit einiges Gehirnschmalz erfordern würde. Der Service erzeugt aus Bedingungen ("This") und ausgelösten Aktionen ("That") Regeln, die der Benutzer mit ein paar Mausklicks dauerhaft aufstellt.
"This" ist dabei ein Eingabe-Kanal wie "Um diese Uhrzeit" oder "Wenn es regnet" oder "Wenn dieses Youtube-Video viral geht". "That" bezeichnet die eingeleitete Aktion wie "Schicke mir eine Email" oder "Poste diese Twitter-Nachricht" oder "Schalte dieses Gerät ein". Das Beispiel in Abbildung 6 illustriert wie ifttt.com eine Email schickt, falls es morgen regnet.
Auf ittt.com finden sich schon allerlei vorgefertigte Kanäle, die einen Input-Event auslösen: Der Sunrise-Kanal triggert bei Sonnenaufgang, der Wetter-Kanal bei Sonnenschein oder Regen und diverse Security-Komponenten lösen bei Einbrüchen Alarm aus. Fallende oder steigende Börsenkurse können genauso Ereignisse auslösen wie ein Voice-Kommando an einen in der Wohnung herumstehenden Amazon Echo.
Wer einen Kanal auf zugangsgeregelnden Servern wie Github oder Gmail benutzen möchte, muss keineswegs sein Passwort auf ifttt.com hinterlegen. Vielmehr lotst ifttt.com den User per Web-Flow vorschriftsmäßig durch den OAuth-Flow der Applikationen, die vom authentifizierten User dann nochmal die Bestätigung abholen, dass ifttt.com nun einige ausgewählte Aktionen unter deren User-ID ausführen darf. Der User kann, wie in OAuth üblich, jederzeit seine Genehmigung wieder zurückziehen, und das Passwort verlässt niemals den Originalservice, während ifttt.com mit begrenzt gültigen Tokens arbeitet.
Und da die Programmierer bei ifttt.com, die sich oft auch aus der Open-Source-Szene rekrutieren, die Integration mit einem Service jeweils nur einmal vornimmt, während der End-User nur Knöpfe klicken muss, sind die Kanäle durchweg sehr gut und sicherheitstechnisch anstandslos implementiert.
Im Arsenal der durch Events ausgelösten Output-Aktionen Events finden sich Email-Nachrichten, SMS, Push-Notifications, An/Aus-Schalter wie den WeMo, und vieles mehr. Die daraus resultierenden Kombinationsmöglichkeiten bei Rezepten mit Inputs und Outputs scheinen daher beinahe unbegrenzt, und die Fantasie der beitragenden Entwickler scheint in der Tat teilweise erstaunliche Ausmaße anzunehmen.
Die Kommunikation zwischen der Smartphone-App und dem Belkin-Server ist nur mit einem SDK zu bewerkstelligen, aber die WeMo-App hat bereits die Integration mit ifttt.com eingebaut. Wer mit ifttt.com den WeMo-Switch ein- und ausschalten möchte, abonniert dort einfach den Channel "WeMo-Switch" und gibt ifttt.com die PIN, die die WeMo-App auf Anfrage im Settings-Menü generiert (Abbildungen 6 und 7).
 |
| Abbildung 7: Die WeMo-App generiert eine PIN ... |
 |
| Abbildung 8: ... die ifttt.com entgegennimmt und damit den WeMo-Switch fernsteuern kann. |
Damit hat ifttt.com die Schlüssel zur Fernsteuerung des WeMo-Schalters
und in Verbindung mit einem auslösenden Input-Kanal können heimische
Elektrogeräte jetzt auch aufgrund ungewöhnlicher Ereignisse wie steigender
Börsenkurse oder Twitternachrichten angeschaltet werden.
Um zum Beispiel bei jedem neu erzeugten Github-Issue in einem vom User geführten Projekt eine Lampe oder eine Sirene im Haus anzuwerfen, erzeugt der User auf ifttt.com einfach ein neues Rezept. Dazu abonniert der registrierte User sowohl den Github-Kanal als auch den WeMo-Switch-Kanal auf der Webseite und verknüpft anschließend den "New Issue"-Bereich des Github-Kanals als Input mit dem Wemo-Switch-Kanal also Output (Abbildung 8). Da der ifttt-Server laufend viele solcher Rezepte prüfen muss, dauert es teilweise etwas nach dem Einleiten des Inputs, bis der Output aktiviert wird. Im Test betrug die die Verzögerung zwischen dem Anlegen eines Github-Issues und dem Anschalten der Lampe etwa 2 Minuten. Aber dennoch ist es faszinierend, dabei zuzusehen, wie leicht diese Art der Verknüpfung von der Hand geht und wieviele Möglichkeiten der Home-Automatisierung sich so auftun.
 |
| Abbildung 9: Jeder neue Github-Issue schaltet den WeMo-Schalter ein. |
Außerdem hat sich noch eine Startup-Firma namens "Smartthings" [7] im Silicon Valley daran gesetzt, alle diese mehr oder weniger proprietären Home-Automation-Protokolle wie Z-Wave ([6]), ZigBee oder WeMo in einem sogenannten Smartthings-Hub zu vereinen und mittels offenen Protokollen sowie einer aktiv eingebundenen Developer-Community in neue Dimensionen vorzudringen.
 |
| Abbildung 10: Der Smartthings-Hub der Firma Samsung bringt verschiedene proprietäre Protokolle unter einen Hut. |
Leider funktioniert der Smartthings-Hub, den ich als Automatisierer der ersten Stunde natürlich längst zuhause betreibe, bislang nur in den USA, und es ist auch noch kein europäisches Modell in Sicht. Sollte er eines Tages doch auftauchen, wird bestimmt an dieser Stelle darüber zu lesen sein.
Listings zu diesem Artikel: ftp://www.linux-magazin.de/pub/listings/magazin/2016/07/Perl
"Heimautomation", Stefan Heinle, Rheinwerk 2015
WeMo Switch bei Amazon.de, http://www.amazon.de/dp/B008TPVZNY
STUN (Session Traversal Utilities for NAT), https://en.wikipedia.org/wiki/STUN
Sicherheitslücken im Wemo-Switch, https://threatpost.com/researchers-find-serious-flaws-in-wemo-home-automation-devices/104300/
"Licht gestalten", Michael Schilli, Linux-Magazin 2016-02, http://www.linux-magazin.de/Ausgaben/2016/02/Perl-Snapshot
Smartthings Hub der Firma Samsung: https://www.smartthings.com
 |
Michael Schilliarbeitet als Software-Engineer in der San Francisco Bay Area in Kalifornien. In seiner seit 1997 laufenden Kolumne forscht er jeden Monat nach praktischen Anwendungen der Skriptsprache Perl. Unter mschilli@perlmeister.com beantwortet er gerne Ihre Fragen. |