Alexa Routine mit einer Frage - Antwort - Tätigkeit

[Glotzkowski]

Okay, kleiner Fehler große Wirkung!

https://github.com/keatontaylor/alex...ki/CustomSkill
Please note that: Private/internal URLs will not work and make sure there are no trailing `/` after your URL.

Ich hatte diesen Slash am Ende der URL, da ich nen Pfad in der URL habe.
Danke an madmaxx für den Tip mit er alternativen Anleitung.

Ich teste und berichte weiter.

[jonofe]

Ich würde hier nur ne Kleinigkeit in der Anleitung ändern, da in Schritt 5 nach /tmp kopiert wird und im Ordner /tmp/alexa-actions kein .tar.gz vorhanden ist
cd /tmp/



tar -xvf alexa-actions-for-edomi.tar.gz -C alexa-actions

Ja, guter Punkt. Habe ich angepasst.

Irgendwo hab ich aber noch nen Fehler, da beim Setzen von E55 des neuen LBS mit "561|Soll ich das Licht ausmachen?"
auf dem nginx-Reverseproxy folgendes auftaucht aber der Echo Dot sagt, dass bei der Antwort des angeforderten Skill ein Problem aufgetreten ist.
Code:

54.240.197.106 - - [19/Nov/2022:09:08:37 +0000] "POST /edomi/auth/token.php HTTP/1.1" 200 111 "-" "Apache-HttpClient/UNAVAILABLE (Java/1.8.0_312)"
Ich suche noch nach der Ursache, hast Du hier einen heißen Tip?

Das Account Linking hat funktioniert? Du müsstest in der oauth2 DB in mysql Einträge in der clients, access_token und refresh_token finden.

Der Eintrag im access_log sieht erst mal gut aus, da HTTP Code 200.

Das Cloud Watch Log könnte draufhindeuten, dass beim anlegen der Datei prompts im Code Bereich des Skills was schiefgelaufen ist.

prompts.png

Wie geht das Log von Cloudwatch denn weiter (der Traceback)?

Um Probleme mit dem LBS auszuschließen, kannst du auch zum Testen den Sprachbefehl geben "Alexa, öffne Custom Actions".
Voraussetzung ist, dass es im alexa-actions Verzeichnis eine Datei input.json gibt, welche aber vermutlich durch das Triggern des LBS schon da sein dürfte. Ansonsten kannst du diesen Inhalt nehmen:

{"state":"{\"event\":\"licht_flur\",\"text\":\"Soll ich das Licht im Flur ausschalten?\"}"}

561|Soll ich das Licht ausmachen?

Die ID beim Triggern von E55 muss übrigens nicht die iKO ID sein, sondern ist einfach nur ein eindeutiger String, der später auch in der Antwort erscheint. Hier könntest du z.B. auch "Licht-Küche|Soll ich das Licht ausmachen?" verwenden.

[jonofe]

So sieht übrigens das Cloudwatch Log eines erfolgreichen Durchlaufs aus, der über den LBS getriggert wurde:

cloudwatch.png

[Glotzkowski]

Der Fehler war ausschließlich durch den Slash in der "HOME_ASSISTANT_URL" der Datei lambda_function.py bedingt.
Account Linking hat alles funktioniert, jetzt kommt der Fehler auch nicht mehr, vielen Dank für Deine Informationen und die ganze Mühe!

Die ID beim Triggern von E55 muss übrigens nicht die iKO ID sein, sondern ist einfach nur ein eindeutiger String, der später auch in der Antwort erscheint. Hier könntest du z.B. auch "Licht-Küche|Soll ich das Licht ausmachen?" verwenden.

Das habe ich gerade auch schon gelernt und dachte, dass dann automatisch ausgeschaltet wird.
Aber so ist es natürlich viel flexibler.

Ich erstelle jetzt ne Logik, welche die "Response" auswertet.

[jonofe]

Der Fehler war ausschließlich durch den Slash in der "HOME_ASSISTANT_URL" der Datei lambda_function.py bedingt.

Eigentlich hätte der ja automatisch entfernt werden sollen durch Zeile 35 in der Lambda function:

HOME_ASSISTANT_URL = HOME_ASSISTANT_URL.rstrip('/')

[Glotzkowski]

Dann habe ich nur die Erklärung, dass ich den Code nicht vollständig deployed habe.
Evtl. war die prompts.py noch nicht vorhanden, als ich dies das erste mal gemacht habe.
Bei der Einrichtung gestern Nachmittag wurde ich unterbrochen und hab später weiter gemacht.

[jonofe]

Glotzkowski madmaxx

Kurze Nachfrage: Läuft es jetzt bei euch beiden? Sind noch weitere Anpassungen an der Doku nötig/sinnvoll?

[Glotzkowski]

Ja, danke es läuft.
Gestern habe ich eine Logik für das Garagentor definiert.
Vielleicht wäre sinnvoll hier die ein oder andere Logik zu posten.

Unbenannt.png
Bisher wurde eine Telegram Nachricht versendet, wenn das Garagentor noch offen steht und die (Anwesenheits-) Alarmanlage aktiv ist.
Jetzt wird zusätzlich Alexa getriggert und schließt das Garagentor bei Bedarf.

Auswertung der Response erfolgt aktuell ganz einfach mit zwei UND-Vergleichern:
Unbenannt2.png
1808 ist die Event-Id (muss "Garagentor_schließen" enthalten)
1809 ist die Event-Response (muss "ResponseYes" enthalten)
Im Ausgang wird das Garagentor per KNX geschlossen.


Was ähnliches werde ich noch für das Licht in der Garage umsetzen, sofern ich nicht noch BWM in der Garage installiere, welche die Steuerung des Lichtes übernehmen...

[ThorstenGehrig]

Ich hab auch türchen 4 auf - hat sauber geklappt.
Die änderung in Zeile 44 müsste nicht notwendig sein - der code sieht auch vorher genauso aus, oder?
Krieg ich die 3.0 zum download ? :-)

Nachtrag: kleine qualitätsicherung - hier fehlt eine > am ende:

mysql -u root -e "insert into oauth2.oauth_clients (client_id, client_secret, redirect_uri) values ('<CLIENT-ID>','<CLIENT-SECRET>','<ALEXA_REDIRECT_URL')"

[jonofe]

In Zeile 44 ist das ".php" der Unterschied.
ich schick dir die links morgen früh zu.

[jonofe]

In der Doku oben fehlte übrigens noch ein wichtiger Punkt:

mysql -u root -e "insert into oauth2.oauth_scopes (scope) values ('smart_home');"

Ohne diesen Eintrag geht die OAuth2 Authentifizierung (Aktivierung des Skills in der Alexa-App) mit einem HTTP Error 302 (/var/log/https/access_log) schief.

Glotzkowski: Hattest du kein Problem ohne diesen Eintrag?

Vermutlich reicht es auch diesen scope in der oauth_client Tabelle einzutragen, d.h. das mysql-INSERT Statement für die oauth_clients Tabelle anzupassen:

mysql -u root -e "insert into oauth2.oauth_clients (client_id, client_secret, redirect_uri, scope) values ('<CLIENT-ID>','<CLIENT-SECRET>','<ALEXA_REDIRECT_URL','smart_home')"

[Glotzkowski]

Glotzkowski: Hattest du kein Problem ohne diesen Eintrag?

Nein, kein Problem.
Bei der Aktivierung des Skills erhielt ich eine Anmeldeseite von EDOMI und konnte mich einwandfrei mit dem EDOMI-Admin anmelden.

Die Tabelle oauth2.oauth_scopes ist leer.

Die Tabelle oauth2.oauth_access_tokens enthält allerdings bereits 39 Einträge, muss die irgendwann mal geleert werden bzw. wie lange sind diese Token gültig?

[jonofe]

Die Tabelle oauth2.oauth_scopes ist leer.

Nein, kein Problem.

Das ist seltsam. Und in oauth_clients ist auch auch kein Scope gesetzt, oder?

Bei der Aktivierung des Skills erhielt ich eine Anmeldeseite von EDOMI und konnte mich einwandfrei mit dem EDOMI-Admin anmelden.

Genau das kam bei mir gar nicht. Weder jetzt bei der erneuten Installation auf einer anderen EDOMI Instanz, noch beim initialen Setup auf meinem Entwicklungssystem.

Hattest du denn den Scope im Alexa Developer Portal (Account Linking Seite) gesetzt? Wenn er dort leer ist, dann wäre es zumindest nachvollziehbar.

scope.png

[Glotzkowski]

Hattest du denn den Scope im Alexa Developer Portal (Account Linking Seite) gesetzt? Wenn er dort leer ist, dann wäre es zumindest nachvollziehbar.

Das hatte ich in der Tat nicht gemacht und nun korrigiert.
In der oauth_clients habe ich den einen vorhandenen Datensatz angepasst.
Die Funktion ist anschließend noch gegeben.
Bei einer erneuten Aktivierung des Skills (DB vorher bereiningt), erhalte ich trotzdem die Anmeldemaske und dann die Frage, ob der Skill aktiviert werden soll.

[jonofe]

Bei einer erneuten Aktivierung des Skills (DB vorher bereiningt), erhalte ich trotzdem die Anmeldemaske und dann die Frage, ob der Skill aktiviert werden soll.

Ja, so soll es sein. Die Anmeldemaske ist der normale Prozess einer OAuth2 Authentifizierung. So wie es z.B. auch mit einem anderen Skill oder z.B. bei der HUE Anbindung an IFTTT passiert. Zuerst Anfrage auf Zugriff, dann Authentisierung, dann Autorisierung mit Zuweisung von Access- und Refreshtoken. Man kann natürlich auch drauf verzichten und nur die Autorisierung (Klick auf den YES Button) machen, dann könnte jeder, der deine OAuth2 URL kennt ein Access/Refresh Token generieren. Deinen Skill kann natürlich keiner triggern, da ja dafür der Zugriff auf den Amazon Account notwendig ist. Das Ergebnis eines Triggerns (Skill triggert PHP Skript, welches die EDOMI remote API aufruft) wird immer mit Access Token verifiziert. Aus diesem Grund macht ein Login (Authentisierung) natürlich Sinn.
Man könnte noch überlegen, ob man dafür einen separaten User aus der OAuth2 DB verwendet statt den EDOMI User. Wäre natürlich ein weiterer notwendiger Schritt in der Konfiguration. Zusätzlich werde ich aber noch den Zugriff des Skills auf die input.json über das Access Token absichern. Ist derzeit noch nicht der Fall.

Eine Bereinigung der DB vor erneuter Aktivierung ist grundsätzlich nicht notwendig.

Die Tabelle oauth2.oauth_access_tokens enthält allerdings bereits 39 Einträge, muss die irgendwann mal geleert werden bzw. wie lange sind diese Token gültig?

Die Access Tokens sollten normalerweise eine Stunde gelten, habe allerdings gerade gesehen, dass sie aufgrund meiner Tests noch auf 30 Sekunden stehen.
Daher bitte einfach die Zeile 19 in server.php von 30 auf 3600 anpassen.