Amazon-Echo Logikbaustein

[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]

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

[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

[wernerL]

Hallo Jürgen,

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

Gruß 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]

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]

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

[ChrisP]

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

[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?

[JuergenK]

Danke. Werd ich morgen mal testen und berichten!

[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

[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

[JuergenK]

Hallo Leute, hat jemand eine Idee? Ich hatte alles eingerichtet, alles hat funktioniert. Seit ein paar Tagen kann der HS das SSL-Zertifikat nicht mehr laden (ich habe nichts an der Konfig verändert:
2017-04-01 11:43:01 | SYS Amazon Echo Service V0.3 vom 16.01.2017 04:17 - (Python Version: (2, 6, 6, 'final', 0) Default Encoding:ascii) 2017-04-01 11:43:01 | SYS Initiate 20 seconds delay for HS to be fully up and running ... 2017-04-01 11:43:42 | SYS Initialize Amazon Echo Service. 2017-04-01 11:43:42 | WARN GET SSL-Certificate from URL='http://xxx.xxx.xxx.xxx:xxxx/opt/amazonEchoSSL.cert' failed. Will using http instead of https. 2017-04-01 11:43:42 | SYS Starting Amazon Echo Service. Was hab ich bisher gemacht:
Cert neu geladen
Cert neu erstellt
Baustein gelöscht / nochmal konfiguriert

Über http funktioniert alles

Irgend wer einen tip? ( muss ich irgendwas reseten?

Anmerkung: Wahrscheinlich gleiche Problem wie bei DB79 - Dirk - mit dem Hiweis orginal V0.3. Was war da das Problem?

Danke!
Juergen

[freak83]

Hammer, es geht vielen Dank wie glücklich man sein kann wenn ein Licht angeht :-)

[wernerL]

Guten Morgen Jürgen,

nein, du hast das völlig richtig verstanden - dieser Test muss ohne Alexa funktionieren.
Bei deinem zweiten Control-Request hast du einen kleinen Tippfehler beim Parameter Message-Id.
Es muss wie beim Discovery-Request messageId (case sensitive) heißen und nicht messsageID.

Viele Grüße
Werner