Heimautomatisierung mit Alexa und Raspberry Pi — Teil 1
Sprachsteuerung im Eigenheim sicher und schnell
Übersicht
Sprachsteuerung ist heutzutage nicht nur bequem, sondern auch preiswert. Geräte von Amazon und Google als Hauptanbieter bieten die Möglichkeit an, per Sprachbefehl Geräte zu steuern. Wir beschäftigen uns in dieser Serie von Artikeln damit, Alexa mit einem Raspberry Pi (oder einem anderen Unix-basierten Computer) zu koppeln, ohne hierfür ein Loch in unseren Firewall zu bohren und uns damit möglichen Angriffen auszusetzen.
Einleitung
Abgesehen davon, dass es interessant ist, sich mit Technologien wie der hinter der Sprachsteuerung durch Alexa auseinanderzusetzen, hat die Koppelung von Alexa mit einem Raspberry im heimischen Netz handfeste Vorteile. Zum einen erhalten wir hierdurch eine sehr hohe Flexibilität der Sprachsteuerung, zum anderen ist die Reaktionsgeschwindigkeit durch die Anbindung eines Raspberry im lokalen Netz spürbar besser.
Flexibilität
Wenn wir den Skill eines Herstellers verwenden, um Geräte in den eigenen vier Wänden zu steuern, dann sind wir in den Steuermöglichkeiten der Geräte vollständig darauf angewiesen, was der Hersteller in seinem Skill implementiert hat. Dies kann durchaus genügen, aber in vielen Fällen wird nicht die gesamte Funktionalität unserer Geräte über die Sprachschnittstelle ansteuerbar gemacht. Weiterhin gibt es genügend Geräte, die eine HTTP- oder ähnliche Schnittstelle haben, für die es aber keinen Skill gibt. Oder wir wollen komplexe Szenarien durch unsere Sprachsteuerung auslösen, die sich nicht ohne weiteres über Hersteller-Skills implementieren lassen. Oder wir wollen nicht von dem Hersteller und der Verfügbarkeit seiner Cloud abhängig sein (sei es temporär, weil der Hersteller Ausfälle oder DoS-Angriffe hat, oder dauerhaft, weil er insolvent gegangen ist).
All dies lässt sich mit einem Raspberry im eigenen Netzwerk implementieren. Natürlich ist der damit verbundene Aufwand höher, als wenn wir einfach nur den Hersteller-Skill installieren. Dagegen steht aber nicht nur der höhere Spaß bei der Implementierung, sondern auch das viel weitergehende Verständnis dafür, was eigentlich bei der Sprachsteuerung unter der Haube passiert. Und zu guter Letzt sind wir mit einer eigenen Lösung deutlich besser gerüstet, Alexa durch eine eigene, lokale Lösung zu ersetzen, sobald diese verfügbar ist (mit den Argumenten Verfügbarkeit und Geschwindigkeit der Sprachsteuerung sowie der Sicherheit, dass das was wir in unseren vier Wänden machen, in unseren vier Wänden bleibt).
Reaktionsgeschwindigkeit
Das klassische Vorgehen bei der Verbindung eigener Geräte mit der Sprachsteuerung von Alexa ist die Installation eines Skills durch den Hersteller der Geräte. Die mit solchen Skills verbundene Kommunikation zwischen allen Beteiligten ist allerdings aufwändig, sowohl in der Anzahl der Schritte als auch in der damit verbundenen Zeit.
Wir haben also in einem solchen typischen Szenario 6 entfernte Kommunikationsschritte, wobei der Hersteller von Alexa, Amazon, sehr viel in die Infrastruktur investiert, um die Schritte 1 und 6 so effizient wie möglich zu machen (wir ignorieren hierbei die eventuelle lokale Kommunikation, falls die Lampe nicht direkt, sondern über ein Gateway angesprochen wird, wie zum Beispiel bei Philips Hue oder Ikea Tradfri). Dies demonstriert die geringe Reaktionszeit bei der Frage an Alexa, “Wieviel Uhr ist es?”, die im Normalfall unter einer Sekunde liegt.
Die weiteren Kommunikationsschritte zum Hersteller der Geräte sind hingegen schwer abzuschätzen, es lässt sich aber praktisch beobachten, dass diese zusätzliche 2–3 Sekunden an Wartezeit verursachen.
Die Alternative hierzu ist ein eigener Skill, der mit einem Raspberry kommuniziert, der im eigenen Heim steht, die Anfragen direkt interpretiert, Handlungen auslöst und Ergebnisse zurückliefert. Um kein Loch in den eigenen Firewall bohren zu müssen, nutzen wir den AWS-MQTT-Broker. Unser Skill publiziert die Alexa-Anfragen in MQTT, und unser Raspberry, der sich vorher mit dem MQTT-Broker verbunden hat, liest die Anfragen und reagiert auf sie.
Die Entkopplung über MQTT hat zwei Vorteile: Zum einen müssen wir unseren Firewall nicht öffnen, sondern der Raspberry verbindet sich proaktiv mit dem MQTT-Broker. Dies bedeutet auch, dass bei Verbindungsabbrüchen (z.B. durch Neuaufbau der DSL-Verbindung) der erneute Verbindungsaufbau transparent passiert. Zum anderen wird unser Skill durch nachgelagerte Verbindungsprobleme nicht beeinflusst, sondern sendet die Anfragen einfach weiterhin an den Broker.
Die Verzögerung durch die zusätzliche Indirektion ist hierbei vernachlässigbar. Die Alexa-Infrastruktur, die Lambda-Funktion für den eigenen Skill und der MQTT-Broker laufen in der gleichen Region und damit quasi lokal. Und auch die Verbindung von MQTT-Broker zu Raspberry bedeutet keine relevanten Verzögerungen im Vergleich zu einer direkten Verbindung (diese könnte sogar langsamer sein, wenn sie jedes Mal neu aufgebaut wird).
In dieser Variante haben wir nur 4 Kommunikationsschritte, die überdies alle auf dem von Amazon optimierten Kommunikationspfad liegen und damit mit nur geringer Verzögerung arbeiten.
Der große Unterschied der beiden Szenarien liegt damit in der Geschwindigkeit der Ausführung. Während wir eine ähnliche Anzahl an Kommunikationsschritten haben, sind diese bei der zweiten Lösung in deutlich größerem Maß lokal, und wir sind vor allem nicht von einer Hersteller-Cloud abhängig, mit der wir entfernt kommunizieren müssen und bei der unklar ist, unter welcher Last sie ist. Das Resultat in der Praxis sind zum Beispiel bei Ikea Tradfri 2–3 Sekunden bei der Schaltung über die Hersteller-Cloud, während wir mit unserem eigenen Raspberry im Bereich von 400–500ms liegen. Und dieser Unterschied ist nicht nur messbar, sondern eminent spürbar.
Realisierung
Wir unterteilen die Realisierung in folgende, vergleichsweise einfache Schritte:
- Teil 2: NodeRed auf Raspbian verbindet sich zu dem AWS-MQTT-Broker, sendet und empfängt Daten.
- Teil 3: Eine AWS-Lambda-Funktion sendet und empfängt Daten über MQTT.
- Teil 4: Unser Alexa-Skill und die Verbindung zum Benutzer-Account (Account-Linking)
- Teil 5: Programmierung der Lambda-Funktion für Heimautomatisierung
Jeder dieser Schritte wird in einem eigenen Folgeartikel behandelt.
Annahmen
Wir gehen in den einzelnen Artikeln von folgenden Annahmen aus:
- Alexa: Entweder die Hardware in Form eines Echo-Gerätes oder aber die App, die auf Smartphones läuft.
- Account bei Amazon: Dieser wird benötigt, um Alexa zu betreiben.
- Account bei AWS: Über den normalen Amazon-Account hinaus brauchen wir auch einen Zugang zu AWS, um unseren Skill und unsere Lambda-Funktion zu schreiben und um den MQTT-Broker einzurichten.
- Raspbbery mit Raspbian und NodeRed: Prinzipiell kann natürlich jeder Computer als Endpunkt für den MQTT-Broker verwendet werden, aber die Kombination eines Raspberry mit NodeRed unter Raspbian ist sehr gut geeignet, um Heimautomatisierungsaufgaben schnell und wenig aufwändig umzusetzen. Damit ist diese Kombination eine ideale Basis für unser Aufgabe.
Schlusswort
Natürlich stellt die Verwendung eines Cloud-Dienstes für die Interpretation der eigenen Sprache eine potenzielle Gefahrenquelle dar. Zum einen geraten damit unsere Interaktionen mit unserer Hausautomatisierung in die Hände eines Anbieters, der durchaus bei einem Angriff den Zugriff auf diese sensiblen Informationen erlauben könnte, zum anderen entsteht ein Angriffsvektor, der es unter Umständen erlaubt unsere Geräte gegen unseren Willen zu beeinflussen. Allerdings ist die Hürde ziemlich hoch, um die AWS-Infrastruktur zu knacken und Einfluss zu nehmen, ohne dass wir dies bemerken.
In einigen Jahren wird es Systeme geben, die Sprachinteraktion auf einem Einplatinencomputer ermöglichen werden. Und dann können wir ohne Sorge unsere Heiminfrastruktur aktualisieren und den Cloud-Dienst durch einen lokalen Dienst ersetzen. Zu dem Zeitpunkt haben wir aber bereits einige Jahre Erfahrung mit der Technologie gesammelt, abgesehen von dem Spaß beim Experimentieren.
Und solange wir uns der Möglichkeit bewusst sind, dass unsere Geräte angreifbar sind, können wir die Programmierung so gestalten, dass die Angriffsfläche so gering wie möglich ist.
Eine letzte Anmerkung: Die Anforderung, ein lokales Gerät mit Alexa zu verbinden, ohne dabei den Firewall zu kompromittieren, spukte schon länger in meinem Kopf herum, aber erst die Idee meines Kollegen Sebastian Dellwig, hierfür den MQTT-Broker von AWS IoT zu verwenden, ließ diese Anforderung vergleichsweise einfach in die Wirklichkeit umsetzen.
Vielen Dank fürs Lesen und ich freue mich auf Feedback. Die weiteren Artikel dieser Serie, genau wie andere interessante Artikel, erscheinen im Blog der Digital Frontiers und werden auch auf unserem Twitter-Account angekündigt.
