Amazon-Echo Logikbaustein

[wernerL]

Hallo Jürgen,

sorry dass ich mich jetzt erst melde, war die letzten Tage krankheitsbedingt ausser Gefecht.

Ehrlich gesagt, konnte ich das Problem vom Dirk bei mir nicht reproduzieren und weiss bis heute nicht, was bei ihm schiefgelaufen ist. Ich habe ihm damals eine neue Version des Logikbausteins mit einer geänderten Funktion zum Laden des Zertifikats geschickt, welche das Problem bei ihm gelöst hat.

Ich habe gerade ein kleines Bugfix-Release der V0.3 mit folgenden Änderungen auf Github hochgeladen:
Logikbaustein: alternative Methode zum Laden des SSL-Zertifikats
AWS Lambda Funktion für den Custom-Skill: Bugfix: Wird die Suche nach KNX-Objekten innerhalb einer Alexa-Session ausgelöst geht das Ergebnis nicht mehr verloren.

Kannst du mal testen, ob das Problem bei dir mit der neuen Version behoben ist?

Viele Grüße
Werner

[DB79]

Hallo Jürgen, hallo Werner,

seit dem geänderten Logikbaustein läuft alles bei mir bestens.
Steuere mittlerweile teile der Lichtsteuerung, Sonos und TV über Amazon Echo.
Vielen Dank nochmal.

Viele Grüße
Dirk

[JuergenK]

Danke. Werd ich morgen mal testen und berichten!

[SpeedyBlade]

Hallo Dirk,

in deinem Bild, das du gepostet hast, sieht es so aus, als ob das Zertifikat nicht vom Baustein gefunden wird: "WARN GET SSL-Certificate from URL='http://192.168.0.200/opt/amazonEchoSSL.cert' failed. Will using http instead of https."
Du schreibst aber auch, dass dir das Zertifikat über den Aufruf dieser URL angezeigt wird? Ist das so?

In DNS.1 gehört der DynDNS-Name deiner Fritzbox rein: Deine Fritzbox hat eine sogenannte öffentliche IP-Adresse (Internet-Adresse). Wenn du keine statische IP-Adresse hast (hat eigentlich kaum einer), wird deiner Fritzbox jedesmal, wenn diese die Internetverbindung aufbaut (z.B.: nach einer Zwangstrennung), eine andere IP-Adresse zugewiesen. Die Lambda-Funktion muss jedoch eine Verbindung zu deiner Fritzbox aufbauen. Mit einer "dauernd" wechselnden IP-Adresse würde dies nicht klappen.
Hier kommt der DynDNS-Name ins Spiel, den unter diesem Namen ist immer die aktuell gültige IP-Adresse abgelegt.
Es gibt mehrere Dienstleister die einen DynDNS-Service anbieten. Nachdem du eine Fritzbox hast, wäre es wohl das Naheliegendste MyFritz zu verwenden.

Viele Grüße
Werner

wie sieht es aus, wenn eine fixe IP-Adresse vorhanden ist, wo ist diese dann zu hinterlegen, weil DynDNS u. Portfreigabe wird dann icht benötigt, oder doch?

[ChrisP]

Eine statische IP ersetzt kein Portforwarding. Die statische IP trägst du einfach dort ein wo in der Anleitung die DynDNS angegeben ist.

[JuergenK]

Ich habe gerade ein kleines Bugfix-Release der V0.3 mit folgenden Änderungen auf Github hochgeladen:
Logikbaustein: alternative Methode zum Laden des SSL-Zertifikats
AWS Lambda Funktion für den Custom-Skill: Bugfix: Wird die Suche nach KNX-Objekten innerhalb einer Alexa-Session ausgelöst geht das Ergebnis nicht mehr verloren.

Kannst du mal testen, ob das Problem bei dir mit der neuen Version behoben ist?

Hi Werner, danke! Teilweise. Also das neue SSL-Zertifikat liest er wieder - also wird erfolgreich geladen!! Was jetzt nicht mehr funktioniert ist: ich komme über den Debug nicht mehr auf die "JSON-Configuration" (Seite nicht vorhanden). Ich habe im Prinzip nur den Baustein neu eingespielt (da geht natürlich die Config verloren) und die Lambda Funktion (zip.file) neu hochgeladen.

Juergen

[wernerL]

Hi Juergen,

ich habe die Github V0.3 des Bausteins bei mir gerade nochmal frisch "installiert", kann den von dir beschriebenen Fehler aber nicht reproduzieren.

Zur Fehlersuche:
Der Zugriff auf die JSON-Configuration erfolgt über https, d.h. hier wir das geladene SSL-Zertifikat verwendet. Ich vermute das Problem auch im "Umfeld" des Zertifikats.

Kannst du nochmal das SSL-Zertifikat verwenden, welches bereits schon mal funktioniert hat?
Du hast im Browser auch eine Ausnahme für dein SSL-Zertifikat hinzugefügt?
Welchen Browser hast du verwendet?
Wie lautet die URL, welche auf der Debug-Seite auf die JSON-Configuration verweist?

Werner

[JuergenK]

ok, danke Werner. Scheint ein Problem mit dem neuen Zertifikat zu sein / oder mit dem Browser. Das alte funktioniert.

Also Rückmeldung: ALLES FUNKTIONIERT WIEDER!!!! Danke Dir!
Juergen

[wernerL]

Hallo Jürgen,

schön zu hören, dass es bei dir wieder läuft.

Gruß Werner

[SpeedyBlade]

Eine statische IP ersetzt kein Portforwarding. Die statische IP trägst du einfach dort ein wo in der Anleitung die DynDNS angegeben ist.

also Amazon Accounts sind alle angelegt u. das Skill konnte am Smartphone auch aktiviert werden.
Mit der Portweiterleitung habe ich nun so meine Probleme.

Welche Adresse (HS oder Öffentliche) muss ich nun hier angeben. Hab in einem Post auch schon gelesen, dass man den Port 80 ebenso weiterleiten muss?

port.png

[SpeedyBlade]

könnt ihr mit der Fehlermeldung etwas anfangen?
2017.png
hier noch das Log
log.png

[wernerL]

Hi SpeedyBlade,

zur Portfreigabe:
Damit die Lambda-Funktion einen Request an den LBS schicken kann, konfigurierst du zuerst im AWS für die Lambda-Funktion, über die Environment-Variable DYNDNS die fixe öffentliche IP-Adresse deines Routers, sowie eine von dir gewählte noch nicht bereits belegte Portnummer z.B: 30000.
Damit landet der Request den die Lambda-Funktion sendet, zumindest schon mal bei deinem Internet-Router. Um den Request vom Internet-Router auf den LBS weiterzuleiten, nutzt du das Portforwarding. D.h. du trägst hier eine Regel ein, mit der ein auf deinem Internet Router eintreffender Request auf Port 30000, auf die lokale IP-Adresse deines Gira HS auf den Port weitergeleitet wird, den du im Eingang des LBS konfiguriert hast, also z.B. auch 30000.

Ich kenne deinen Router leider nicht aber anhand deines Screenshots würde ich folgende Einträge machen:
Servicename: kannst du (denke ich) selbst frei wählen also z.b.: "AmazonEcho_GiraHS"
Source Target: damit (vermute ich) kann man die IP-Adresse des Absenders angeben von dem der Request kommen muss, um weitergeleitet zu werden. Nachdem die IP-Adresse des Absenders irgendein Amazon-Server ist, würde ich dieses Feld entweder leer lassen falls möglich, oder einen Stern "*" versuchen.
Portbereich: 30000
Lokale IP: lokale IP-Adresse deines Gira HS
Lokaler Port: die im LBS eingetragene Portnummer. Also z.B.: auch 30000

zu deinem Test:
Schau doch mal bitte, welche Ausgaben im Log des Bausteins gemacht werden (über die Debug-Seite des Homeservers erreichbar) bzw. ob auf der Debug-Seite unter Exceptions Fehlermeldungen ausgegeben werden.

Viele Grüße
Werner

[SpeedyBlade]

Hallo Werner

ich habe eine fixe öffentliche IP-Adresse, welche ich auch lt. wiki 2.3 AWS La..... angelegt habe. Ein DynDNS sollte soweit wir bekannt nicht notwendig sein.
Portnummer xxx habe ich dort ebenfalls, sowie im LBS hinterlegt (Eingang E2 = xxx)

Ergebnis: ...schaut schon mal perfekt aus Execution result: succeeded

jetzt habe ich nur mehr (hoffe ich zumindest), das Problem ein SSL-Zert. zu erstellen. Da kann ich nun nicht ganz folgen, wo bzw. mit was ich dieses erstellen kann

ps.: müsste nun nicht, das Licht (GA=korrekt) ausgehen, wenn ich auf "Daten absenden" gehe?

echo.png

Danke u. Gruss
Harald

[wernerL]

Hi Speedyblade,

die Fehlermeldung besagt, dass die Lambda-Funktion zu lange gebraucht hat um einne Antwort zu liefern und auf den konfigurierten Timeout (default 3s) gelaufen ist.
Ich test bei mir morgen mal, ob die Verwendung einer IP statt mit DYNDNS Probleme macht und melde mich dann wieder.

Das Log sieht eigentlich vernünftig aus. Hast du über die JSON-Konfiguration bereits ein Gerät konfiguriert?

Gruß Werner

[SpeedyBlade]

HI Werner,

der Fehler ist nun weg, lag tatsächlich nur an der Portweiterleitung, d.h. fixe IP, sollte hier keine Probleme machen.

JSON-Konfig. habe ich noch nicht durch. Möchte zuerst noch SSL-Zert. erstellen, damit ich weiss, dass dies alles sauber läuft.
Vielleicht kannst hier noch ein wenig supporten

Achja, welcher Skill Type muss angelegt werden: "Smart Home Skill API" oder "Custom Interaction Model". Denn hier sind die Informationen zw. Wiki u. PDF-Anleitung unterschiedlich.

Gruss
Harald