Heimautomatisierung mit Alexa und Raspberry Pi — Teil 4
Alexa Skill und Account Linking
Einleitung
Nachdem wir in den vorherigen Teilen (Teil1, Teil 2 und Teil 3) der Reihe die Kommunikation einer Lambda-Funktion über MQTT bis zu unserem Raspberry betrachtet haben, kommen wir jetzt zum eigentlichen Alexa Skill. In diesem Teil unserer Reihe beschäftigen wir uns damit, einen Alexa Skill zu erzeugen und das für Smart Home Skills notwendige Account Linking durchzuführen.
Voraussetzungen
Die Voraussetzungen sind die gleichen wie in den vorhergehenden Teilen. Wir benötigen einen AWS-Account für die Erstellung des benötigten Sicherheitsprofils (für das Account Linking) und des Skills selbst. Optional sollten wir bereits die MQTT-Instanz und unseren Raspberry konfiguriert haben, so dass spätere Aufrufe auch tatsächlich beobachtet werden können.
Auch wenn dies ein Wiederholung ist: Für die spätere Interaktion mit Alexa ist (zumindest zum Zeitpunkt des Schreibens) wichtig, in der AWS-Region “EU-West-1 (Ireland)” zu arbeiten. Dies ist die AWS-Region, in der auch die Alexa-Skills für Deutschland laufen. Da jede Region eine eigene zugeordnete MQTT-Instanz für unseren Account hat, würde Alexa zwar die Befehle an die MQTT-Instanz in Irland weiterleiten, unser Raspberry würde aber bei einer anderen MQTT-Instanz (z.B. Frankfurt) lauschen.
Die Basis
Amazon geht bei Skills für Heimautomatisierung von einem Szenario aus, in dem ein Gerätehersteller Benutzern einen Skill zur Verfügung stellt, um die Geräte des Herstellers zu steuern.
Hierzu benötigt der Hersteller benutzerspezifische Informationen, um den Benutzer und darüber die zu steuernden Geräte eindeutig identifizieren zu können. Deshalb müssen wir, wenn wir den Skill eines Herstellers wie zum Beispiel Ikea oder Philips nutzen, im Skill eine Verbindung zu unserem Account in der Hersteller-Cloud schaffen. Wann immer wir hinterher ein Gerät steuern, wird von Alexa automatisch ein Zugriffs-Token zur Verfügung gestellt, das in der zum Skill gehörenden Lambda-Funktion abgefragt und im Aufruf an die Hersteller-Cloud mitgeschickt werden kann. Dies erlaubt es dem Hersteller, das Gerät, das er steuern soll, zu identifizieren und die gewünschten Aktionen auszulösen.
In dem Skill, den wir hier erstellen, wissen wir, dass nur wir selbst den Aufruf ausgelöst haben können, und müssen in unserer Lambda-Funktion deshalb weder das Token abfragen noch es an unseren Raspberry weiterschicken.
Wir müssen aber trotzdem die Voraussetzungen für Account-Linking einrichten, da Amazon dies für SmartHome-Skills als zwingend notwendig definiert hat. Weiterhin müssen wir, wenn wir später unseren Skill zu Alexa hinzufügen, das eigentliche Account-Linking durchführen, obwohl wir dies nie nutzen werden.
Um es nochmal deutlich zu sagen: Wir werden das Account-Linking nie benutzen, müssen es aber trotzdem einmal einrichten, um die Vorbedingungen zu erfüllen.
Account Linking konfigurieren
Für das Account-Linking benötigen wir ein eigenes Sicherheitsprofil (Security Profile). Im Prinzip könnten wir jedes System verwenden, das OAuth2 anbietet (und im Fall einer Hersteller-Cloud würden wir natürlich unser eigenes System wählen); Mögliche Provider wären zum Beispiel Google, Auth0 oder Github (eine Liste findet sich unter diesem URL). Der Einfachheit halber verwenden wir “Login with Amazon”.
Wir gehen zu developer.amazon.com und loggen uns ein. Falls wir nicht gleich auf der Developer Console landen, wechseln wir dort hin (developer.amazon.com/home.html). Der einfachste Weg zu einem neuen Sicherheitsprofil führt über den Link “Login with Amazon”, der im obersten Menü stehen sollte. Dort werden wir aufgefordert, ein neues Sicherheitsprofil zu erzeugen, falls wir noch keines haben. Alternativ wechseln wir über “Apps & Services” zum Untermenü “Security Profiles”. Interessant hierbei: Im ersten Fall wird zusätzlich ein Link zu einer “Privacy Policy” abgefragt, die später beim eigentlichen Account Linking durch den Benutzer angezeigt wird. Für uns hat der Unterschied keine Bedeutung.
Nach der Speicherung werden uns Werte für die “Client ID” und das “Client Secret” angezeigt. Diese benötigen wir später, können sie uns aber jederzeit über das Security-Profile-Management anzeigen lassen, so dass wir sie jetzt nicht notieren müssen.
Erzeugung unseres Skills
Der nächste Schritt ist jetzt die Erzeugung des eigentlichen Alexa-Skills. Auch dies können wir in der Developer Console durchführen. Falls wir auf der Übersichtsseite sind (developer.amazon.com/), erreichen wir die Erzeugung neuer Skills über den Link Alexa, falls wir in der Developer Console selbst sind (developer.amazon.com/home.html), folgen wir dem Submenü “Alexa Skills Kit” im Menü “Alexa”.
Hier klicken wir auf “Create Skill”, um zur Skill-Erzeugung zu wechseln. Wir nennen unseren Skill “homeautomation” (da wir unseren Skill nicht veröffentlichen, müssen wir keine Rücksicht auf die Amazon-Vorgaben für Skillnamen nehmen) und wählen als Modell “Smart Home” aus (dies ist wichtig, da wir die Funktionalität des Modells benötigen). Ein Klick auf den Button “Create skill” erzeugt den Skill.
Jetzt können wir die einzelnen Teile des Skills konfigurieren. Die Seite, auf die wir nach dem Klick geleitet werden, erlaubt die Auswahl der Version der versendeten Nachrichten (1. Payload version); hier ist die Version 3 vorausgewählt. Im nächsten Bereich auf dieser Seite können wir den Namen unserer Lambda-Funktion zur Verarbeitung der Alexa-Aufrufe angeben (dies werden wir im nächsten Blog-Beitrag im Detail betrachten).
Bevor wir jetzt zur Verbindung mit dem Sicherheitsprofil kommen: Es gibt noch eine weitere Seite “Permissions”, die es uns erlaubt, weitergehende Rechte von Benutzern anzufragen und asynchrone Aufrufe zu machen. Da wir beides nicht benötigen, brauchen wir hier nichts ändern und können zur Konfiguration des Sicherheitsprofils wechseln.
Verbindung von Skill und Sicherheitsprofil
Verknüpfung des Skills mit dem Sicherheitsprofil
Die Verknüpfung des Skill mit dem Sicherheitsprofil konfigurieren wir auf der Seite “Account Linking”, die wir entweder über den Button “Setup Account Linking” auf der ersten Seite oder über die Seitenauswahl auf der linken Seite erreichen.
In der folgenden Tabelle finden sich die Werte, die wir in den verschiedenen Feldern eintragen müssen:
Die “Authorization URI” ist die URL der Authentifizierungsseite. Da wir “Login with Amazon” als Authentifizierungsdienst verwenden, nutzen wir die zugehörige Login-Seite.
Die “Access Token URI” wird verwendet für den Umgang mit Tokens. Hier wird sowohl die eigentliche Autorisierung als auch die Aktualisierung von abgelaufenen Tokens behandelt.
“Client ID” ist die in unserem Sicherheitsprofil angegebene Client ID, “Client Secret” ist entsprechend das unserem Sicherheitsprofil zugehörige Geheimnis. Diese wurden uns bei der Erstellung bereits gezeigt, wir können sie uns jetzt aber wieder anzeigen lassen, indem wir zu “Login with Amazon” navigieren und dort in der Liste der Sicherheitsprofile bei unserem ausgewählten auf “Show Client ID and Client Secret” klicken (siehe Bild 3).
Der “Scope” definiert, wie viel Information übertragen wird. “Login with Amazon” bietet uns hier drei verschiedene Varianten an:
Wir wählen der Einfachheit halber den “Scope” profile und klicken auf den Button “Save” (oben rechts auf der Seite).
In der Konfiguration des Skills sehen diese Eintragungen aus wie folgt:
Verknüpfung des Sicherheitsprofils mit dem Skill
Jetzt bleibt noch die Aufgabe, dem Sicherheitsprofil die URLs bekannt zu machen, unter denen Anfragen von unserem Skill kommen können.
Unten auf der Seite “Account Linking” der Skill-Konfiguration finden wir eine Liste von Redirect-URLs. Diese stellen für die verschiedenen Regionen der Welt die beim Sicherheitsprofil einzutragenden Return-URLs dar. Die Liste sieht ungefähr aus wie folgt (die drei Punkte sind ersetzt durch die ID des Skills):
Hierbei repräsentiert jeder dieser URLs eine andere Region. Die URLs, die auf https://pitangui.amazon.com verweisen, sind für die Region “North America” zuständig, die auf https://alexa.amazon.co.jp verweisen, werden im fernen Osten genutzt und https://layla.amazon.com wird für Europa und Indien verwendet.
Wohlgemerkt geht es hierbei um die URLs, die für Benutzer aus diesen verschiedenen Regionen für die erfolgreiche Authentifizierung verwendet werden. Für uns sollte also eigentlich der URL reichen, der mit https://layla.amazon.com beginnt. Sicherheitshalber tragen wir aber alle URLs bei unserer Sicherheitsrichtlinie ein.
Wir wechseln zu unserer Sicherheitsrichtlinie (über das Menü “Login with Amazon” und das Submenü “Security Profile”, siehe Bild 3). Wenn wir mit der Maus über das Zahnrad fahren, geht ein Menü auf, in dem wir “Web Settings” auswählen (falls Sie einen anderen Menü-Eintrag erwischen, wechseln Sie in der sich öffnenden Maske einfach auf den Reiter “Web Setting”).
Wir klicken auf den “Edit”-Button tragen unter “Allowed Return URLS” alle Redirect-URLs unseres Skills ein. Das Ergebnis sollte dann ungefähr wie in Bild 7 aussehen.
Aktivieren und Testen des Skills
Im letzten Schritt können wir jetzt in unserer Alexa-App den neuen Skill aktivieren. Hierzu wechseln wir in der App zu den Skills und wählen unter “Entwickler-Skills” unseren Skill “homeautomation” aus. Wir müssen die Kontoverknüpfung durchführen (sprich uns mit unserem normalen Amazon-Login einloggen), und hierbei wird auch angezeigt, dass unser Skill wie im “Scope” konfiguriert auf das Profil zugreifen möchte.
Zum Schluss können wir testen, dass diese Aktivierung erfolgreich war, indem wir auf den Link “Test Your Skill” oben rechts in der Konfiguration des Skills klicken. Wenn wir alles richtig gemacht haben, geht eine Seite auf, in der wir den Skill durch Eingabe oder Sprachsteuerung testen können. Ein erster Versuch ist die Eingabe “suche Geräte”. Alexa sollte antworten, dass sie keine neuen Smarthome-Geräte finden konnte.
Zusammenfassung
Wir haben jetzt alle Voraussetzungen, um die Verbindung zwischen Alexa und unserem Raspberry herzustellen. Hierfür fehlt nur noch die Lambda-Funktion, die sowohl die Discovery-Requests von Alexa (für die Geräteanmeldung) als auch die eigentlichen Aufrufe zur Steuerung unserer Geräte korrekt bearbeitet. Dieser widmen wir uns im nächsten Artikel dieser Serie.
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. Vielen Dank vor allem auch Sebastian Dellwig, dessen Feedback auch diesen Text wieder deutlich besser gemacht hat.
