Alexa Custom Skill für EDOMI (LBS 19000646 und 19000647)

[Nanosonde]

Womit haste das denn getestet? Eigentlich sollte das doch normales Python sein. Ggf. unterstützt nur die requests library kein IPv6.
Die socket library unterstützt es aber ganz sicher. Vielleicht solltest du es damit nochmal testen.

Hi!
Der Fehler "Address family for hostname not supported" kommt vom Aufruf von getaddrinfo().
Das bedeutet, dass er den DNS-Namen zu einer IPv6-Adresse aufgelöst hat, die aber vom System nicht unterstützt wird.
Ich habe auch im Amazon Forum gelesen, dass IPv6 bei den Lambdas tatsächlich nicht geht.

[Nanosonde]

Andere Frage:
Gibt es eigentlich einen Grund, warum Du in der Anleitung das Skript alexa.php auf Edomi laufen lässt?
Könnte das nicht auch auf dem Raspberry Pi laufen. Wenn ich es richtig verstehe, dann kommuniziert alexa.php mit dem LBS doch eh über Sockets, richtig?

[jonofe]

Technisch würde das funktionieren. Wenn allerdings jemand deinen RPi kompromitiert, dann kann er mit dem PHP Skript Befehle an deinen Alexa Receiver senden. Außerdem müsstest du diese Socket Connection in der Firewall zwischen DMZ und internem Netz öffnen. Ich halte einen geöffneten Port auf einen Apache SSL Socket für sicherer als den Socket zwischen einen Alexa Skill Skript und einem EDOMI LBS.

Wenn du keine Firewall zwischen dem RPi Reverse Proxy und dem EDOMI Server hast (also keine DMZ), dann macht es in der Tat kaum einen Unterschied, ob es auf dem EDOMI Server oder dem RPI läuft.

Gibt es denn einen Grund warum du das Skript auf dem RPi laufen lassen möchtest?

[tyke]

Hallo André,

genau, ich teste mit dem Befehl "Starte Edomi".
Im Fehlerlog steht leider nichts aufschlussreiches:

{EDOMI,CUSTOMLOG_Alexa_Receiver_LBS_19000646.htm,1 7.03.2017,08:17:45,428750,19294}
Zeitstempel	ms	PID	LogLevel	Meldung
2017-03-17 08:17:45	428570	19294	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:17:45	481868	19294	debug	LBS19000646 [v0.3.1]: LBS ended
2017-03-17 08:39:09	211844	20896	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:39:09	273173	20896	debug	LBS19000646 [v0.3.1]: LBS ended
2017-03-17 08:40:51	929683	1494	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:40:51	972522	1494	debug	LBS19000646 [v0.3.1]: LBS ended

[jonofe]

Im Fehlerlog steht leider nichts aufschlussreiches:

{EDOMI,CUSTOMLOG_Alexa_Receiver_LBS_19000646.htm,1 7.03.2017,08:17:45,428750,19294}
Zeitstempel	ms	PID	LogLevel	Meldung
2017-03-17 08:17:45	428570	19294	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:17:45	481868	19294	debug	LBS19000646 [v0.3.1]: LBS ended
2017-03-17 08:39:09	211844	20896	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:39:09	273173	20896	debug	LBS19000646 [v0.3.1]: LBS ended
2017-03-17 08:40:51	929683	1494	debug	LBS19000646 [v0.3.1]: LBS started
2017-03-17 08:40:51	972522	1494	debug	LBS19000646 [v0.3.1]: LBS ended

Das ist nicht das Logfile von dem ich oben sprach ...

[tyke]

sorry, stimmt...
ich habs gefunden:

Invalid Application id: amzn1.ask.skill.af90.....

Ich hatte ein Leerzeichen nach dem Anführungszeichen.

$applicationIdValidation = ' amzn1.ask....

Blöder Fehler! Vielen lieben Dank nochmals für die Hilfe und den tollen LBS!!!

[Nanosonde]

Wenn du keine Firewall zwischen dem RPi Reverse Proxy und dem EDOMI Server hast (also keine DMZ), dann macht es in der Tat kaum einen Unterschied, ob es auf dem EDOMI Server oder dem RPI läuft.

Gibt es denn einen Grund warum du das Skript auf dem RPi laufen lassen möchtest?

War eher eine theoretische Frage, ob technisch etwas dagegen spricht.

Wie kann ich denn dem nginx beibringen, dass er den Reverse Proxy nur für das eine File "alexa.php" macht und ansonsten nichts aus der Edomi-Installation nach außen zur Verfügung stellt?

[jonofe]

Dazu würde ich das alexa.php in ein eigenes Verzeichnis verschieben, welches unterhalb von /usr/local/edomi/www/ liegt und dann das proxy_pass Statement in der nginx Config anpassen.

mkdir  /usr/local/edomi/www/alexa/
cp /usr/local/edomi/www/admin/lbs/alexa.php /usr/local/edomi/www/alexa/

und dann:

nano /etc/nginx/sites-enabled/default

und dort den proxy_pass Befehl ändern:

proxy_pass https://<EDOMI-IP>/alexa/;

Ist aber ungetestet, da ich derzeit einen apache Reverse Proxy einsetze.

[benji]

Hi,

ich bekomme derzeit die Fehlermeldung von Alexa: Bei er Kommunikation mit dem angeforderten Still ist ein Problem aufgetreten.

Habe dazu im Internet nichts gefunden. Hatte schon einmal jemand dieses Problem??

Gruß Benjamin

[jonofe]

Was sagt das Log?

[Nanosonde]

Dazu würde ich das alexa.php in ein eigenes Verzeichnis verschieben, welches unterhalb von /usr/local/edomi/www/ liegt und dann das proxy_pass Statement in der nginx Config anpassen.

[...]

Ist aber ungetestet, da ich derzeit einen apache Reverse Proxy einsetze.

Das habe ich getestet.
Leider mit einem sehr merkwürdigen Ergebnis: ich komme trotzdem immer noch auf den kompletten WWW-Pfad von Edomi.
Selbst wenn ich bei nginx die Location auf "/alexa/" ändere, funktioniert "/edomi/" immer noch.
Nginx habe ich nach dem Editieren der Config-Datei natürlich neu gestartet.
Der neue Ort von alexa.php ist entsprechend der neuen Config erreichbar, aber leider eben auch der alte komplette Pfad.
Im Nginx-Log sehe ich auch, dass er die Anfrage für den alten Pfad mit 200 (OK) beantwortet, obwohl das gar nicht mehr in der Config steht.

Hat jemand eine Idee?

server {
        listen [::]:443 ssl default_server;
        ssl_certificate /etc/letsencrypt/live/myhost.dyndns.de/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/myhost.dyndns.de/privkey.pem;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name myhost.dyndns.de;
        location /alexa/ {
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_pass https://192.168.10.99/alexa/;
                proxy_redirect off;
                proxy_buffering off;
                proxy_connect_timeout 5; # more than http_server
                proxy_read_timeout 350; # 60 default, 300s is GNUnet's idle timeout
                proxy_http_version 1.1;
                proxy_next_upstream error timeout invalid_header http_500
                http_503 http_502 http_504;
        }
        if ($scheme != "https") {
            return 301 https://$host$request_uri;
        }
}

UPDATE:
So sieht es im Nginx acess.log mit obiger Config aus:

54.240.197.73 - - [27/Mar/2017:11:30:19 +0200] "POST /edomi/admin/lbs/alexa.php HTTP/1.1" 200 465 "-" "Apache-HttpClient/4.5.x (Java/1.8.0_112)"

Man beachte: die Location ist "/alexa/" und die Alexa-Skill-Config bei Amazon ist immer noch der alte Pfad mit "/edomi".
Die Anfrage an Nginx wird mit 200 beantwortet.

[benji]

Hi,

wie lange dauert bei euch im Schnitt die "Certification" von dem Alexa Skill?? Anfangs ging dies bei mir immer so in 25min, jetzt hatte ich seit langem mal etwas geändert. Jetzt steht es seit Samstag auf Status "Certification".
Habe eben nochmal kurz bearbeitet und gespeichert, Status bleibt allerdings immer noch gleich.

gruß benji

[jonofe]

certification? mich würde wundern wenn Amazon den Skill zertifizieren würde. denn die Voraussetzungen für eine Zertifizierung sind gar nicht gegeben. Ist ja auch nur ein skill den du selbst nutzt.

Vermutlich wird der Skill dann auch veröffentlicht und andere können dann bei dir die Lampen ein und ausschalten.

[benji]

Ja verstehe ich. Ich hab das skill ja nicht veröffentlicht.

hab lediglich zwei Räume ergänzt und dann auf save.

Verstehe ich auch gerade nicht.

[jonofe]

Ja verstehe ich. Ich hab das skill ja nicht veröffentlicht.

hab lediglich zwei Räume ergänzt und dann auf save.

Verstehe ich auch gerade nicht.

Bei Save wird aber keine Certification gestartet.
Und wie gesagt, Certification sollte auch nicht gemacht werden.
Das eigentliche Speichern sollte nicht mehr als eine Minute dauern.