© Steven Cukrov, 123RF

Mit dem Webservice “If This then That” klickt der User einfach Home-Automation-Komponenten zusammen, statt sie mühselig selbst programmtechnisch zu integrieren. Heimautomations-Pionier Mike Schilli ist begeistert, legt aber trotzdem selbst Hand an.

Fahren bei einem aufziehenden Gewittersturm wie von Geisterhand am Haus die Außenjalousien hoch, ist klar: Aha, da ist Home-Automation am Werk [2]. Leider ist es aber gar nicht so einfach, die einzelnen Komponenten in einem Smarthome zu einem stimmigen Gesamtsystem zu integrieren, da viele Hersteller gerne ihr eigenes Süppchen kochen, das absichtlich geschmacklich nicht zu dem der Konkurrenz passt.

Neulich kaufte ich aus einer Laune heraus den Switch der Firma Wemo (Abbildung 1, [3]), der sowohl mechanisch als auch mit mobiler Telefon-App elektrische Verbraucher entweder übers heimische WLAN oder gar übers offene Internet ein- und ausschaltet.

Abbildung 1: Der Wemo-Switch verspricht schnurloses Einschalten von Elektrogeräten mittels App.

Registrierungsfrei

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 I-OS (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 danach den User auf, die SSID und das Passwort des heimischen WLAN einzugeben. Die App schickt die Daten an den Minicomputer im Schalter, der daraufhin über das heimische WLAN aufs Internet zugreift und sich selbstständig beim Belkin-Wemo-Service anmeldet.

Abbildung 2: Die App bedient den Schalter übers WLAN oder Web.

Keinerlei Registrierung per E-Mail ist erforderlich, alles läuft anonym ab. Die App kommuniziert mit dem Fernschalter entweder übers WLAN oder, falls das Mobiltelefon außerhalb dessen Reichweite ist, über den Belkin-Service auf dem offenen Internet (Abbildung 3).

Abbildung 3: Über einen Server im offenen Internet kommunizieren die Smartphone-App und der hinter einer Firewall befindliche Wemo-Switch miteinander.

Statt nun bloß mechanisch auf der Telefon-App herumzutippen, bietet es sich an, den Schalter per Skript 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 so genanntes Smarthome, das zum Beispiel nur dann das Licht im Carport anschaltet, wenn es dunkel ist und das Bluetooth-Signal des Smartphones des Hausherrn sich nähert.

Kommando Ein/Aus

Der Wemo-Schalter betreibt einen kleinen Webserver im WLAN, den ein einfaches Perl-Skript wie 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.

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;

Zudem 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 zugrunde liegenden URLs und erlaubt so bequeme und saubere Programmierung.

Wemo, vobiscum?

Da der WLAN-Router dem Schalter die IP-Adresse dynamisch zuweist, bietet es sich an, jenem per Einstellung beizubringen, an anfragende Geräte 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 erfahren.

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 }

Als Search-Target spezifiziert das Skript mit dem Parameter »st« und dem Wert »upnp:rootdevice« , dass es an allen Rootdevices 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 befand sich zum Testzeitpunkt nur ein UPnP-Gerät, und die Ausgabe in Abbildung 4 zeigt unter anderem, dass die UPnP-Abfrage den Webserver des Schalters auf IP 192.168.1.139 gefunden hat.

Abbildung 4: Das Skript lanciert eine UPnP-Abfrage im WLAN und findet den Wemo-Switch auf IP 192.168.1.139.

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, indem das STUN-Protokoll [4] mit einem Belkin-Server im Internet spricht. Das ist natürlich sicherheitstechnisch nicht unbedenklich, denn ein kleiner Fehler in der Implementierung erzeugt so plötzlich ein riesiges Darknet an fernsteuerbaren elektrischen Geräten im offenen Internet [5]. Vom Betreiben kritischer Komponenten wie etwa Boden-Luft-Abwehrsystemen, Saunaheizungen oder Zahnarztbohrern muss daher dringend abgeraten werden.

“Wenn dies, dann das”

Ein gravierender Nachteil des Geräts ist offensichtlich, dass es überflüssigerweise wieder ein neues proprietäres Protokoll benutzt. Das ist leider die Norm unter den Heimautomations-Produkten, die folglich nur mit den meist nicht sonderlich originellen Apps des Herstellers zusammenarbeiten, weil die Open-Source-Community in die Röhre schaut.

Aber zum Glück hat sich die hippe Internetfirma Ifttt.com aufgemacht, diesen Protokollwirrwarr 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 rauen 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 Eingabekanal, etwa “Um diese Uhrzeit” oder “Wenn es regnet” oder “Wenn dieses Youtube-Video viral geht”. »That« bezeichnet die eingeleitete Aktion wie “Schicke mir eine E-Mail” oder “Poste diese Twitter-Nachricht” oder “Schalte dieses Gerät ein”. Das Beispiel in Abbildung 5 illustriert, wie Ifttt eine Mail schickt, falls es morgen regnet.

Abbildung 5: Der Service auf Ifttt.com löst Aktionen aus, wenn vordefinierte Ereignisse eintreten.

Bei Ifttt.com finden sich allerlei vorgefertigte Kanäle, die einen Event auslösen: Der Sunrise-Kanal triggert bei Sonnenaufgang, der Wetter-Kanal bei Sonnenschein oder Regen, diverse Security-Komponenten lösen bei Einbrüchen Alarm aus. Fallende oder steigende Börsenkurse können ebenso Ereignisse auslösen.

Wer einen Kanal auf zugangsgeregelten Servern wie Github oder Gmail nutzen möchte, muss sein Passwort nicht 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 nochmals die Bestätigung abholen, dass Ifttt.com nun ausgewählte Aktionen unter deren User-ID ausführen darf. Der User kann, wie in Oauth üblich, jederzeit seine Erlaubnis zurückziehen. Das Passwort verlässt niemals den Originalservice, während Ifttt.com mit begrenzt gültigen Tokens arbeitet.

Und da Programmierer, die sich oft aus der Open-Source-Szene rekrutieren, die Integration mit einem Service jeweils nur einmal vornehmen – während der Nutzer nur klicken muss –, sind die Kanäle durchweg sehr gut und sicherheitstechnisch anstandslos implementiert.

Im Arsenal der durch Events ausgelösten Output-Aktionen finden sich Mail-Nachrichten, SMS, Push-Notifications, An/Aus-Schalter wie Wemo und vieles mehr. Die Kombinationsmöglichkeiten bei Rezepten mit Inputs und Outputs scheinen daher beinahe unbegrenzt und die Fantasie der beitragenden Entwickler nimmt erstaunliche Ausmaße an.

Schaltregeln per Mausklick

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 6: Die Wemo-App generiert zuerst eine PIN …

Abbildung 7: … die Ifttt.com entgegennimmt und damit den Wemo-Switch fernsteuern kann.

Damit besitzt Ifttt.com die Schlüssel für die Fernsteuerung des Wemo-Schalters und in Verbindung mit einem auslösenden Input-Kanal können damit heimische Elektrogeräte jetzt angeschaltet werden. Das funktioniert auch mit ungewöhnlichen Ereignissen als Auslöser, zum Beispiel bei steigenden Börsenkursen oder beim Eintreffen von Twitter-Nachrichten.

Alarm bei Github-Issue

Um etwa bei jedem neu erzeugten Github-Issue in einem vom User geführten Projekt eine Lampe oder eine Sirene anzuwerfen, erzeugt der User auf Ifttt.com einfach ein neues Rezept. Dazu abonniert der registrierte Anwender den Github-Kanal sowie den Wemo-Switch-Kanal auf der Webseite und verknüpft dann den »New Issue« -Bereich des Github-Kanals als Input mit dem Wemo-Switch-Kanal, also dem Output (Abbildung 8).

Abbildung 8: Jeder neue Github-Issue schaltet den Wemo-Schalter ein.

Da der Ifttt-Server laufend viele solcher Rezepte prüfen muss, dauert es manchmal etwas nach dem Einleiten des Inputs, bis der Output aktiviert wird. Im Test betrug die Verzögerung zwischen dem Anlegen eines Github-Issue 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 wie viele Möglichkeiten der Home-Automatisierung sich so auftun.

Smartthings integriert

Zudem hat sich ein Startup namens Smartthings (Abbildung 9, [6]) im Silicon Valley vorgenommen, die mehr oder weniger proprietären Home-Automation-Protokolle wie Z-Wave [7], Zigbee oder Wemo im so genannten Smartthings-Hub zu vereinen und mit offenen Protokollen und einer aktiv eingebundenen Developer-Community in neue Dimensionen vorzudringen. Das Startup gehört inzwischen zu Samsung.

Abbildung 9: Der Smartthings-Hub der Firma Samsung bringt verschiedene proprietäre Protokolle unter einen Hut, derzeit aber nur in den USA.

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 derzeit auch noch kein europäisches Modell in Sicht. Sollte er eines Tages doch auftauchen, wird bestimmt an dieser Stelle darüber zu lesen sein.

Der Autor

Michael Schilli arbeitet 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 mailto:mschilli@perlmeister.com beantwortet er gerne Fragen.