© Dmitry Kalinovsky, 123RF

Ein Stromausfall lässt die Intelligenz eines Smart Home schlagartig absacken. Eine Notstromversorgung und ein Skript auf der Smartthings-Plattform verhindern Schlimmeres und informieren den Hausherrn. Der polyglotte Perlmeister macht in dieser Ausgabe einen Ausflug in die Skriptsprache Groovy.

In Deutschland eher selten, aber in den USA selbst in Großstädten eine Normalität: Der Strom ist von einer zur anderen Sekunde weg. Sei es, dass die Stadt San Francisco Oberleitungen immer noch als wilden Kabelverhau zwischen Häusern spannt (Abbildung 1) oder dass die elektrische Infrastruktur der Umspannwerke veraltet und bröselig ist, jedenfalls muss ein Smart Home hier stets mit dem Schlimmsten rechnen und Strategien für den Fall bereithalten, dass der Saft mal ein paar Stunden ausbleibt. Auch wer in Ländern mit einer stabileren Stromversorgung lebt, wird die heute vorgestellte Ausfallsicherheit zu schätzen wissen, wenn ein gewitzter Einbrecher vorsichtshalber vor dem Einstieg die Sicherung rausfliegen lässt, aber einen gehörigen Schreck bekommt, falls trotzdem die Sirene losgeht!

Abbildung 1: San Francisco: Die dort anzutreffende Stromversorgung mittels Kabelverhau führt zu Ausfällen.

Notstrom

Dabei sollten sowohl Herzstücke der Automatisierung wie der Controller ohne Netzstrom weiterlaufen als auch dessen Verbindung ins Internet funktionieren – einschließlich des Signalwegs dorthin, auf dem Router, Kabel- oder DSL-Modems liegen, die ohne Strom auch nichts tun. Beschränkt sich der Hausherr darauf, nur lebenswichtige Komponenten bei einem Stromausfall am Laufen zu halten, summiert sich der Verbrauch auf nur wenige Watt, selbst eine billige batteriegepufferte Notstromversorgung für weniger als 50 Euro kann diese Minimal-Infrastruktur eine Weile am Leben halten.

Qual der Hardwarewahl

Diese Uninterruptible Power Supplies (UPS, deutsch USV) genannten Geräte geben ihre Kenndaten meist in Volt-Ampere (VA) an, was leider nicht für die Beantwortung der elementarsten Frage reicht, wie lange sie einen Verbraucher mit bekanntem Stromverbrauch am Laufen halten. Hierzu muss der User die Eckdaten der eingebauten Batterien kennen und in eine in [2] erklärte Formel einsetzen, aus der die Minuten bis zur Erschöpfung herauskommen.

Zunächst erwarb ich ein Billig-UPS für 30 US-Dollar, das allerdings mit sinnlosem, nicht abstellbarem Gepiepse im stromlosen Betrieb nervte, sodass ich schließlich 120 Dollar für ein solide gearbeitetes UPS von Tripp-Lite (Abbildung 2) auf den Ladentisch legte, das nicht nur digital anzeigt, für wie viele Minuten Betrieb der Saft noch reicht, sondern sogar eine Quiet-Taste hat, die dafür sorgt, dass der Apparat auch während eines Stromausfalls ohne Piepsen seinen Dienst tut. Wunder der Technik!

Abbildung 2: Der Smartthings-Hub (oben) und die Notstromversorgung für die Internetverbindung.

Schlaues Heim trotz Ausfall

Wie in [3] erwähnt, war das von mir eingesetzte Home-Automation-Kit der Firma Smartthings mit Controller und einem Set von vier verschiedenen Sensoren und Aktoren bis vor Kurzem nur in den USA erhältlich. Seit September 2015 ist der Smartthings-Hub [4] aber auch in einer angepassten UK-Version für den europäischen Markt zu haben und bei Amazon zum Preis von 240 Euro zu bestellen. Passende Sensoren und Aktoren, die das Z-Wave- oder Zigbee-Protokoll beherrschen, gibt es zum Preis von etwa 40 Euro auch auf diesem Weg.

Die meisten Komponenten dieser Smart-Home-Lösung arbeiten batteriebetrieben, sogar der Controller ist batteriegestützt und schaltet bei fehlender Netzspannung übergangslos um, sodass es damit keiner weiteren Vorkehrungen bedarf. Auch meine Arlo-Überwachungskameras [5] laufen drahtlos mit Batterie, also kümmert sich das UPS nur um die Arlo-Basestation sowie um Router und ISP-Modem. Praktisch alles läuft mit dieser einfachen Lösung bis zu drei Stunden lang weiter, wenn der Strom ausfällt. Längere Auszeiten als eine Stunde sind gottlob selten, auch hier bei uns im wilden Westen.

Konstrukt

Doch wie stellt ein Sensor überhaupt fest, dass der Strom ausgefallen und das Notstromaggregat angesprungen ist? Es wäre naheliegend, den Controller selbst zu fragen, und in der Tat zeigt sein Webinterface (Abbildung 3) an, ob er per Notbatterie läuft oder ob Netzspannung anliegt. Allerdings bietet Smartthings diese Information leider nicht über das Developer-API [6] an.

Abbildung 3: Der Hub zeigt an, ob er auf Netzspannung oder wegen eines Ausfalls auf Batterie läuft.

Also kam mir zunächst eine an den Meister umständlicher technischer Lösungen, Rube Goldberg, erinnernde Konstruktion in den Sinn: Wie wäre es mit einer lichtdichten Verputzdose vom Baumarkt, in die ein Netzkabel hineinführt, und einem LED-Nachtlicht mit nur 0,3 Watt sowie einem batteriebetriebenen Lichtsensor, der kontrolliert, ob das Licht und damit der Netzstrom an ist (Abbildung 4)? Als Sensor bot sich ein Gerät namens Zooz (Abbildung 5) an, das als Bewegungsmelder fungiert, aber auch nebenbei Raumtemperatur und Lichteinfall in Lux misst.

Abbildung 4: Ein LED-Nachtlicht brennt, so lange Strom da ist, und signalisiert damit dem Sensor, dass die Versorgung funktioniert.

Abbildung 5: Der batteriebetriebene Licht-Bewegungs-Temperatur-Sensor von Zooz spricht Z-Wave mit dem Controller.

Der Smartthings-Hub integriert so ziemlich jedes Gerät, das das drahtlose Z-Wave oder Zigbee-Protokoll spricht, und so war auch das Einbinden des Sensors in den Z-Wave-Verbund des Hub über die Mobiltelefon-App kein Thema (Abbildung 6).

Abbildung 6: Neue Z-Wave-Komponenten findet der Hub im Inclusion-Modus oft automatisch.

Schlaue Apps

Die Smartthings-App fürs Mobiltelefon (I-OS und Android) liest dann die Sensordaten in regelmäßigen Abständen ein oder einfach per Subscription immer dann, wenn vordefinierte Ereignisse eintreten. Den aktuellen Zustand aller Geräte zeigt die Dashboard genannte Übersicht an (Abbildung 7). Schalter lassen sich so per App umlegen – und die App visualisiert den Endzustand.

Abbildung 7: Die Smartthings-App zeigt den Zustand aller Geräte an und steuert sie einzeln an.

Was darüber hinausgeht, kann der User selbst programmieren. In so genannten Smartapps können registrierte Entwickler Groovy-Code zusammenklopfen, der Sensoren abfragt, Aktionen mit Z-Wave-Aktoren einleitet oder externe Webrequests abfeuert. Smartthings gibt sich schmallippig, wenn der User wissen will, wo die Smartapps tatsächlich laufen: auf dem Hub oder in der Cloud? Je nach Last behält es sich die Firma vor, die notwendigen Rechenschritte hier oder da auszuführen.

Ein Simulator in der IDE hilft dabei, letzte Kinderkrankheiten auszumerzen, und drückt der User »Publish | For me« (Abbildung 8), installiert die Telefon-App den auf dem Desktop im Browser editierten Code. Zauberei!

Abbildung 8: User können ihre eigenen Applikationen für den Smartthings-Hub in einer IDE in Groovy schreiben und mittels »Publish« installieren.

Der Groovy-Code in Listing 1 definiert im Abschnitt »preferences« die Sensoren, die der User auswählen muss, nachdem er die neu installierte Smartapp unter dem Punkt »Marketplace | My Apps« ausgewählt und gestartet hat. Vorgegeben ist lediglich »capability.motionSensor«, und die Smartapp befragt hierzu den Hub nach allen Geräten mit dieser Eigenschaft und präsentiert dem User eine Auswahlliste.

01 definition(
02   name: "PowerPoll",
03   namespace: "mschilli",
04   author: "Mike Schilli",
05   description: "Power outage sensor",
06   category: "Convenience")
07
08 preferences {
09   section("Device") {
10     input "sensor",
11       "capability.motionSensor",
12       required: true
13   }
14 }
15
16 def installed() {
17   initialize()
18 }
19
20 def updated() {
21   initialize()
22 }
23
24 def initialize() {
25   unschedule()
26   schedule("42 * * * * ?", handler)
27 }
28
29 def handler() {
30   log.debug "Light Check: " +
31     sensor.currentIlluminance
32 }

Wählt dieser den neu hinzugekommenen »Z-Wave Plus Motion/Temp Sensor« aus, startet die Smartapp und der verblüffte Entwickler kann die Log-Ausgaben der irgendwo in der Cloud laufenden App in einem beliebigen Browserfenster verfolgen (Abbildung 9).

Abbildung 9: Den Lichtsensor liest der Hub nur alle vier Minuten aus, während Ereignisse am Kontaktsensor sofort erscheinen.

Fixe Events

Der Code selbst ist Event-gesteuert, die Funktionen »installed()« und »updated()« sind notwendige Einsprungspunkte, die der Hub nach der Neuinstallation oder dem Auffrischen der Smartapp anspringt. Beide kanalisiert Listing 1 in der Funktion »initialize()« ab Zeile 24, die einen Cron-Eintrag anlegt, der in der 42. Sekunde jeder Minute die ab Zeile 29 definierte Funktion »handler()« anspringt. Vor dem Anlegen des neuen Cron-Eintrags löscht »unschedule« vorsichtshalber alle bislang angelegten, damit es zu keiner Explosion von neuen Einträgen kommt.

Die Methode »currentIlluminance« des Sensor-Objekts in Zeile 31 liest den Lichtwert des Sensors aus, dessen Namen Zeile 10 vorher eingeholt hat. Dass ein String in Zeile 10 mir nichts, dir nichts ein Objekt in Zeile 31 erzeugt, nennt man, das sei am Rande bemerkt, in Fachkreisen “Spooky Action at a Distance”. Erfahrene Programmierer scheuen den Effekt wie der Teufel das Weihwasser, aber das Smartthings-Developer-API ist leider voll von derartigen Narreteien.

Wie die Log-Ausgabe in Abbildung 9 zeigt, stellte sich leider heraus, dass der Hub den Zooz-Sensor nur alle paar Minuten ausliest. Außerdem unterstützt das Zooz-Gerät den sonst angebotenen Subscription-Modus anscheinend nicht, bei dem der Hub bei jeder Wertänderung an einem Sensor sofort einen Callback anspringt.

Fällt der Strom aus, dauert es also unter Umständen fünf Minuten, bis der Code den Ausfall bemerkt und Aktionen wie die Benachrichtigung des Users über SMS einleiten kann. Nicht das Ende der Welt, aber es geht schon noch besser.

Noch ein Sensor

Auf Amazon fand ich noch einen Z-Wave-Sensor vom Hersteller Seven-7-Express (Abbildung 10), der Stromausfälle sehr effizient meldet. Er ist als Türkontakt implementiert und meldet »closed«, falls der Strom angeschaltet ist, und »open« falls nicht. Über einen Ladegerät-Adapter hängt er an der Steckdose, während im Sensor selbst eine Batterie steckt, die es ihm erlaubt, per Z-Wave Signale an den Hub zu schicken, falls kein Strom mehr in der Steckdose ist.

Abbildung 10: Der batteriegestützte Power-Outage-Sensor von Seven-7-Express zeigt wie ein Türkontakt an, ob Strom da ist oder nicht.

Das Gerät funktionierte auf Anhieb, und das Groovy-Skript in Listing 2 implementiert die Logik zur Steuerung. Im Abschnitt »preference« sucht der Hub nach Sensoren mit der Eigenschaft »capability.contactSensor« und bietet dem User unter anderem den neu installierten Power-Sensor an, wenn dieser die App aktiviert. Zeile 26 meldet eine Subscription auf den Event »contact« an, den der Hub jedes Mal auslöst, wenn der Sensor von »open« auf »closed« und umgekehrt springt. So bekommt das Skript Stromausfälle mit nur ein, zwei Sekunden Verzögerung mit und loggt sie in den Zeilen 31 und 33.

01 definition(
02   name: "PowerSensor",
03   namespace: "mschilli",
04   author: "Mike Schilli",
05   description: "Subscribe and detect",
06   category: "Convenience")
07
08 preferences {
09   section("Device") {
10     input "power",
11       "capability.contactSensor",
12       required: true
13   }
14 }
15
16 def installed() {
17   initialize()
18 }
19
20 def updated() {
21   initialize()
22 }
23
24 def initialize() {
25   unsubscribe()
26   subscribe(power, "contact", evthandler)
27 }
28
29 def evthandler(evt) {
30   if(power.currentContact == "closed") {
31     log.debug "Power back!"
32   } else {
33     log.debug "Power outage!"
34   }
35 }

Hallo User!

Stellt die Smartapp fest, dass der Strom weg ist, kann sie mit dem in [7] schon einmal vorgestellten Prowl-Web-API den User auf seinem Handy wachrütteln. Listing 3 pflanzt den von Prowl verlangten API-Key ein, den registrierte Nutzer nach dem Kauf der App für 3 US-Dollar auf der Webseite https://www.prowlapp.com abholen.

01 def prowl(message) {
02   def params = [
03     uri: "https://api.prowlapp.com",
04     path: "/publicapi/add",
05     query: [
06       event: message,
07       application: "Smartthings",
08       url: "",
09       description: "Power Outage Notification",
10       apikey: "xxxxxxxxxxxxxxxxxxxxxxx"
11     ]
12   ]
13
14   try {
15     httpGet(params) { resp ->
16       log.debug "Prowl message sent";
17     }
18   } catch(e) {
19     log.error "Can't send Prowl message: $e"
20   }
21 }

Die Funktion »prowl()« nimmt eine Nachricht entgegen (»Power out!« beziehungsweise »Power back!«), setzt das Event-Feld damit und fügt noch den Namen der sendenden App und eine kleine Erklärung dazu, damit der Empfänger weiß, woher die Nachricht kommt. Im Try-Block setzt dann »httpGet« den Request ab, und sowohl im Gut- als auch im Fehlerfall loggt »log.debug« eine entsprechende Nachricht für später folgende Fehleranalysen. Ein einfacher und effizient zu nutzender Service, der sowohl auf I-OS als auch auf Android funktioniert (Abbildung 11).

Abbildung 11: Durch diese Textnachricht erfährt der User, dass zu Hause der Strom ausgefallen ist.

Webzugriff

Wer auch den etwas versteckten Oauth-Abschnitt beim Einrichten der Smartapp aktiviert, erhält nach einem Oauth-Token-Dance (zum Beispiel über das CPAN-Modul Oauth::Cmdline, Abbildung 12) einen Access-Token, der den Zugriff auf die laufende Smartapp aus dem offenen Internet erlaubt. Der Smartapp-Code in Listing 4 definiert im Abschnitt »mappings« die Einstiegspunkte des Web-API und die ihnen zugewiesenen Aktionen. Die ab Zeile 9 definierte Funktion »checkPower()« liest dann auf Zuruf den aktuellen Zustand des Sensors aus und gibt das Ergebnis als Map zurück, die das Web-API im Json-Format an den Webclient zurückgibt.

01 mappings {
02   path("/power") {
03     action: [
04       GET: "checkPower"
05     ]
06   }
07 }
08
09 def checkPower() {
10   return [power:
11     power.currentContact == "closed" ?
12       "ok" : "not ok"]
13 }

Abbildung 12: Der User erlaubt den Webzugriff auf ausgewählte Z-Wave-Geräte.

Abbildung 13 zeigt die Abfrage mit einem »curl«-Client von der Kommandozeile. Zuerst erfragt dieser unter Angabe des API-Token die Lage des »endpoints«, also die komplette URL, unter der ein registrierter User seine Smartapps findet. Mit dieser URL kann der Client auf die im Code definierten Einstiegspunkte zugreifen (im Beispiel: »/power«) und erhält Json-formatierte Ausgaben zurück, etwa die, dass das »power«-Feld den Wert »ok« oder »not ok« führt.

Abbildung 13: Curl auf der Kommandozeile greift über das Web-API auf den Stromausfall-Fühler zu.

Schlimmer Zustand

Die Programmierung des Smartthings-API ist allerdings nur für Bastler mit Eselsgeduld zu empfehlen. Samsungs Smartthings-Abteilung scheint das Stiefkind der Organisation zu sein. Nicht nur ist die Dokumentation völlig unzureichend und widersprüchlich, auch der Sourcecode des Hub-Kerns ist nicht zugänglich, sogar die Groovy-eigenen Self-Inspection-Mechanismen wurden ausgehebelt, damit der User ja die wahren Namen der falsch dokumentierten Attribute nicht finden kann.

Im vorliegenden Fall wäre es zum Beispiel nicht zu kompliziert, den Hub zu fragen, ob der Strom noch aus der Leitung oder den Reservebatterien kommt, statt Rube-Goldberg-Lösungen wie die eben beschriebene zu produzieren. Läge der Hub-Code offen, könnten engagierte Hobbyisten sogar etwaige Lücken im API füllen.

Die App stürzt ständig ab, die Webseite zur Entwicklung von Smartapps ist hingeschustert und weist gravierende funktionale Mängel auf, etwa den, dass der »Update”-Knopf« zum Ändern der Metadaten nicht funktioniert. Wer denkt, der Developerzugriff erfolge über »graph.api.smartthings.com«, wird über das Forum belehrt, dass es in den USA »graph-na02-useast1« statt »graph« heißen muss und im UK »graph-eu01-euwest1«, sonst findet das API die Geräte des Users nicht, der sich darüber die Haare rauft. Das standardmäßig übliche Sharding über den Usernamen funktioniert nicht.

Dem steht eine engagierte Community gegenüber, die selbst aus den lieblos hingeworfenen Brocken noch laufende Applikationen stampft. Die einzig richtige Strategie für Samsung dürfte die Offenlegung des gesamten Projekts einschließlich der verwendeten Kommunikationsprotokolle sein und es der Community zu überlassen, es in eine wartbare Plattform mit Zukunft zu verwandeln. Potenzial wäre da.