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

[jonofe]

Ich würde auf der Fritzbox unter Internet->Freigaben->Fritz!Box-Dienste den Zugriff von außen via HTTPS abschalten. Danach sollte Port 443 für die Weiterleitung
verfügbar sein.

Screenshot from 2017-10-06 17-12-16.png

SSH? Auf dem RPI? Sollte eigentlich aktiv sein. Wenn nicht, dann über das Programm raspi-config aktivieren.

5-Interfacing Options => P2 SSH

Früher war es unter Advanced Options => SSH zu finden. Hängt also von deiner Raspbian Version ab.

[fehling]

Danke Andre,

beide Probleme beseitigt.

Allerdings hänge ich am nächsten Punkt beim SSL Zertifikat für den nginx:


"Had a problem while installing Python packages.

pip prints the following errors:..."


Die gesamten pip prints habe ich in einen Anhang gepackt.

Bisher gab es hier nur einen andere Post, der an derselben Stelle Probleme hatte. Da war es zu wenig Speicher. Meine Fehlermeldung sieht aber anders aus.


Jemand, v.a. Andre, ne Idee?

Gruß,
Felix

[jonofe]

Könnte ein bug im letsencrypt sein. Welche Version verwendest du?

Kannst mal folgendes machen:

Modify /etc/pip.conf and add the below line item

extra-index-url=[URL="https://www.piwheels.hostedpi.com/simple/zope.components"]https://www.piwheels.hostedpi.com/si...ope.components[/URL]

Vielleicht hilft das.

Grundsätzlich solltest du bei Raspbian "stretch" so vorgehen:

https://certbot.eff.org/#debianstretch-nginx

[fehling]

Danke abermals.

Das Vorgehen nach der Certbot-Anleitung und Webroot-Plugin hat dann funktioniert.

Bin soweit gut durchgekommen, B-Rating, aber der Aufruf des Testskripts (https://<MeineDDNS.net-Domäne>/edomi/phpinfo.php) geht nicht und bringt "404 Not Found" :-(

Gruß,
Felix

[jonofe]

haste die phpinfo.php auch erzeugt und auch im richtigen Verzeichnis?
Von welchem Server kommt die 404 Meldung? vom Edomi oder vom Reverse Proxy?

[fehling]

Die Meldung kam vom Reverse Proxy.

War ein dämlicher Fehler von mir. Hatte in der SSL Konfiguration die IP des RPi und nicht vom Edomi-Rechner drin.
War wohl zu spät gestern ;-)

Jetzt läufts

Danke nochmal & schönen Sonntag.

[webasti321]

Hallo zusammen,

ich habe auch nach langer Pause (Bauzeit) mich jetzt nochmals an Alexa gewagt.
Den Custom-Skill habe ich schon am Laufen und funktioniert gut.

Wollte jetzt den SH-Skill noch nachtragen, bis jetzt aber ohne Erfolg.
Habe alles nach Anleitung erstellt und schon bestimmt zehn mal nach Fehlern durchsucht.
Bei der Lambda-config bin ich mir absolut nicht sicher ob das alles passt, da die gesamte Oberfläche anders gestaltet wurde (als in der Anleitung) und ich auch kein .ZIP file im anhang des Receiver LBS finde. Habe den Code direct rein Kopiert. Beim Test der lambda bekomme ich immer den Fehler:
"Unable to import module 'edomi-aws-lambda-skill-adapter". Allerdings ohne sauberes Test-Event da ich da schon wieder komplett aussteige.


Unbenannt1.PNGUnbenannt4.PNGUnbenannt5.PNG
Unbenannt2.PNG
Unbenannt3.PNG




im Edomi Log nur den Eintrag "No OAUTH Access Token received"

phpinfo.php ist ereichbar.

Wer kann mir Helfen?

eriche Du hattest auch selben Fehler, aber nie gesagt was bei dir falsch war. Vielleicht hast du einen Hinweis für mich.

gruß Basti

[eriche]

da ich den Fehler nicht fand, legte ich das Skill komplett neu an und ließ es erneut von Amazon zertifizieren.
Dannach klappte es.
Ich schätze einmal, dass wir uns irgendwo vertippt haben?

[shortyle]

Nun habe ich mich den ganzen Tag eingelesen, war mir auch ganz sicher das ich es hinbekomme, und schon auf Abends aufs Ausprobieren gefreut aber ich komm nicht wirklich weiter mit Raspbian Stretch scheint es wirklich etwas anders beim Zertifikat zu sein.

Zuerst zur Hardware: RPi2 mit Raspbian Stretch lite 2017-09-07
Die Installation lief problemlos durch.
NO-IP als DDNS Dienst

Allerdings hänge ich am nächsten Punkt beim SSL Zertifikat für den nginx:


"Had a problem while installing Python packages.

pip prints the following errors:..."

Ich scheitere ebenfalls an dieser Stelle...
allerdings komm ich auch mit dieser Vorgehensweise (https://certbot.eff.org/#debianstretch-nginx) nicht weiter.

Nun zu den Problemen

mit dem Befehl

sudo certbot certonly --webroot -w /etc/letsencrypt/live/<DYNDNS_NAME> -d <DYNDNS_NAME>

arbeitet er etwas aber es erscheint folgende Fehlermeldung

Waiting for verification...

Cleaning up challenges

Failed authorization procedure. <DYNDNS_NAME> (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://<DYNDNS_NAME>/.well-known/acme-challenge/BUCHSTABENUNDZAHLENKOMBINATION: Error getting validation data




[B]IMPORTANT NOTES:[/B]

 - The following errors were reported by the server:

   Domain: <DYNDNS_NAME>
   Type:   connection
   Detail: Fetching
   http://<DYNDNS_NAME>/.well-known/acme-challenge/BUCHSTABENUNDZAHLENKOMBINATION:

   Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

[fehling]

Hallo zusammen,

vorerst benutze ich nur den ersten Teil von Andre's Alexa Custom Skill Anleitung, um mit dem ReserveProxy (nginx) von außen auf Edomi zugreifen zu können. So kann man schon mal von unterwegs an Visus basteln.

Zugriff auf die Edomi-Administration über die DNS-Domäne funktioniert schon mal wunderbar. Aber die Visus laden nicht!
Im Visualisierungsreiter der Edomi-Konsole taucht im Sekundentakt die "eingewählte" Visu auf - fliegt aber wieder raus.

Hat jemand ne Idee woran's liegt?

Gruß,
Felix

[jonofe]

Da gibts einen separaten Thread zu. Es liegt an der Nutzung von Websockets seit Edomi 1.52. Damit dies von extern funktioniert sind einige Änderungen in der Reverse Proxy Konfiguration notwendig.

Siehe HIER

[webasti321]

da ich den Fehler nicht fand, legte ich das Skill komplett neu an und ließ es erneut von Amazon zertifizieren.
Dannach klappte es.
Ich schätze einmal, dass wir uns irgendwo vertippt haben?

Habe auch schon alles neu aufgesetzt aber komme immer wieder zur selben Situation. Habe mittlerweile den LBS von Panzaeron und hatte keine Probleme mit Skill, Lambda und co. Möchte trotzdem Andrés LBSen treu bleiben

Ich denke irgend etwas passt nicht mit der Lambda Funktion.

jonofe gibt es das zip File für die Lambda-Funktion nicht mehr? Wie ist dann der richtige weg den Code einzufügen?

Gruß Basti

[jonofe]

Sorry Basti, ist bei mir untergegangen. Vermutlich habe ich beim letzten Update das zip vergessen. Und vermutlich ist das auch die Ursachen, denn im ZIP sollte auch die JSON und requests Klasse enthalten sein, die ja vom Lambda Skript verwendet wird. Ich schau mir das noch mal an.

[Pendragon]

Puh, und ich dachte ich wäre zu doof. Hänge gerade an dem selben Fehler.

Btw: André: Großartige Arbeit!!!

[shortyle]

Ich bin immer noch am verzweifeln und scheitere beim erstellen des Zertifikat.

habe den Raspberry nochmal komplett neu aufgesetzt.

Eine static IP (diesmal eine andere) habe ich lt. Anleitung für Debian Stretch eingerichtet.
Port Fwd für den Pi und Port 443 in der Fritzbox ist eingerichtet

nginx Installation sowie das Erreichen über die IP und kurzzeitig über Port 80 per ddns klappt.


Wenn ich nun, wie unter https://certbot.eff.org/#debianstretch-nginx vorgegeben, folgendes eingebe (leicht abgeändert aus dem HowTo von Andre um die SSL Config dann 1:1 übernehmen zu können)

$ sudo [SIZE=14px][FONT=arial]certbot [/FONT][/SIZE]certonly --webroot -w /etc/letsencrypt/live/beispiel.ddns.net -d beispiel.ddns.net

folgt die Fehlermeldung, dass es dieses Verzeichnis nicht geben würde.

also mit

[FONT=arial][SIZE=14px][FONT=Times New Roman][COLOR=#000000]mkdir [/COLOR][/FONT][/SIZE][/FONT]/etc/letsencrypt/live/beispiel.ddns.net

Verzeichnis erstellt.

Dann der certbot Befehl wieder ausgeführt

$ sudo [SIZE=14px][FONT=arial]certbot [/FONT][/SIZE]certonly --webroot -w /etc/letsencrypt/live/beispiel.ddns.net -d beispiel.ddns.net

dann verlangt er wie erwartet meine E-Mail Adresse sowie die Bestätigung der Terms of Services.

nach kurzem "Waiting for verification" scheitert dann das Ganze folgender Ausgabe (meine Daten habe ich hier unkenntlich gemacht)

[FONT=arial][SIZE=14px][FONT=Times New Roman][COLOR=#000000]Failed authorization procedure. beispiel.ddns.net[/COLOR] [COLOR=#000000](http-01): urn:acme:error:connection :: The server could not connect to the client to verify the [/COLOR][/FONT][/SIZE][/FONT] :: Fetching
http://beispiel.ddns.net/.well-know/acme-challenge/1111111aaaaa22222222bbbbbb3333333cccccc44444444: Error getting Validation data

Ich habe wirklich keine Idee mehr was ich verkehrt mache? Die Verbindung per http://IP und http://ddns klappt ja

Kann mich mal jmd an die Hand nehmen und helfen

Wäre es "sinnvoll" eine Raspian Jessi Installation vorzunehmen, dann nach HOW TO alles einrichten und dann den Pi auf Raspian Strech zu aktualisieren?

Viele Grüße
David