Alexa Smarthome Skill (Payload Version 3)

[gspsteve]

Da Alexa keine Geräte findet und

Zumindest selbes verhalten als bei mir (OAuth Fehler)

Gibt es bei dir ein

sr/local/edomi/www/data/log/edomi-smarthome-skill.log???

[jonofe]

Code:

tail -f usr/local/edomi/www/data/log/edomi-smarthome-skill-PLv3.log
das Log leer bleibt, stimmt wohl irgendwas noch nicht.

Da fehlt ein / vor dem "usr"

[gregorS]

Da fehlt ein / vor dem "usr"

hab den code gestern aus eintrag #103 kopiert.
Da stehts ohne dem / drin.

[jonofe]

Dann ist es dort falsch.
In der PDF Anleitung stehts richtig drin. (Seite 33)

[gregorS]

Zumindest selbes verhalten als bei mir (OAuth Fehler)

Gibt es bei dir ein

sr/local/edomi/www/data/log/edomi-smarthome-skill.log???

Hallo,
bei mir gibt es die Datei, ist aber leer.
in der PLv3.log ist der Oauth Fehler bei mir nicht.

LG

[jonofe]

Nur die PLv3.log ist relevant. Steht denn da was drin, wenn du nach Geräten suchen lässt?

[gregorS]

mit dem tail -f.... befehl bleibt bei mir die Konsole leer hab nochmal die komplette Anleitung verglichen, finde aber keinen Fehler.
Alexa findet aber nichts

Edit: hab den tail -f... aus der Anleitung. Dort fehlt aber noch das PLv3. Mit dem richtigen Log File bekomme ich auch Einträge während Alexa sucht. Allerdings findet sie nix

Edit 2: Es ist vollbracht Bei mir lags daran dass ich beim Einrichten in EDOMI mehr nach Bildern gearbeitet hab anstatt nach Text
Musste nur die Ausgangsbox direkt an die LBS hängen und nicht nach der Klemme. Jetzt funktionierts

Danke nochmal an die Hilfestellungen

[shortyle]

Hier leider der Nächste mit einem Problem ganz zu Beginn der Einrichtung

Rpi 3+, Raspian Lite (aus dem Link im aanleitungs PDF), DDNS mit goip.de -> eingetragen in einer Synology 216+, Apache Testsite von extern, bei Port 80 Öffnung, ist erreichbar. Vor der Synology und dem Rpi sitzt eine Unifi USG (falls das Detail wichtig ist). Soweit so gut..

...wenn ich nun das Certificat erstellen will kommt folgende Fehlermeldung

root@ReverseProxy:/opt/letsencrypt# ./letsencrypt-auto --rsa-key-size 4096 -d [COLOR=#FF0000]ddnsvon[/COLOR].goip.de --redirect -m [COLOR=#FF0000]meineemail[/COLOR]@adresse.de
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for [COLOR=#FF0000]ddnsvon[/COLOR].goip.de
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. [COLOR=#FF0000]ddnsvon[/COLOR].goip.de (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://[COLOR=#FF0000]ddnsvon[/COLOR].goip.de/.well-known/acme-challenge/0I5_[COLOR=#FF0000]9ibhbrAf2tKO7nTXj9zxxxxxxxxxxxxxxxxxxxx[/COLOR]: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: [COLOR=#FF0000]ddnsvon[/COLOR].goip.de
   Type:   connection
   Detail: Fetching
   http://[COLOR=#FF0000]ddnsvon[/COLOR].goip.de/.well-known/acme-challenge/0I5_[COLOR=#FF0000]9ibhbrAf2tKO7nTXj9zxxxxxxxxxxxxxxxxxxxx[/COLOR]:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA 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.

Die rot markierten Stellen habe ich nur verfremdet, diese sind mit meinen korrekten Daten gefüllt.

Eine extra Firewall ist nicht installiert/aktiviert.

Bin da wirklich ratlos?! Zumal ich es mit einer Fritzbox statt dem USG (Fritzbox Zitat aktuell noch vor dem USG) schon einmal am Laufen hatte.

Einen anderen ddns Dienst habe ich auch schon ausprobiert, mit dem selben Ergebnis.

Gruss David

[jonofe]

http://ddnsvon.goip.de/.well-known/acme-challenge/0I5_9ibhbrAf2tKO7nTXj9zxxxxxxxxxxxxxxxxxxxx

Kannst du diese URL denn von außen aufrufen?

[shortyle]

Leider nein.
wenn ich den Port 80 kurzzeitig öffne dann kommt folgende Fehlerseite im Browser.

395D5EEF-8194-4DB6-879C-2514F2072DEC.jpeg

Wenn ich nur meine ddns Adresse eingebe, lande ich wie geplant auf der Apache Seite.

Mit meinem laienhaften Wissen würde ich ja vermuten, dass die Anfrage nicht aus dem Netz rausgeht. Aber Ping auf Google geht

[jonofe]

hast du denn alles als root gemacht auf dem RPi?

[shortyle]

Also ich bin strikt nach Anleitung gegangen. Und so viel kam da mit sudo (außer der ersten beiden Punkte ab Kapitel 2.4) nicht.
Mit PHP7.0 kann es nichts zu tun haben, oder? Oder der Tatsache das vor dem USG noch die Fritzbox ist (doppeltes NAT)?

[jonofe]

Auf dem RPI musst du eigentlich alles als root machen.
Insbesondere das Letsencrypt. Am besten zuerst ein "su -".
Danach bist du für alle Befehle als root angemeldet.

PHP7? Du meinst auf dem RPI?
Wieso ist es eigentlich doppeltes NAT?
Intern kannst du doch einfach routen und brauchst kein NAT. NAT ist nur am äußeren DSL Router notwendig.

[shortyle]

hmmm wie gesagt habe ich eigentlich alles wie in der Anleitung gemacht und auch die Sudo Befehle vorne dran gesetzt. Ich denke ich starte einfach nochmal neu...

Lt. Anleitung wird ja PHP5 installiert. Allerdings ging das nicht und ich habe/musste PHP7.0 installieren.

mit doppelten NAT meinte ich, dass es ja ein bekanntest "Problem" bei USG und diavorgeschalteter Fritzbox ist, da die Fritzbox sich nicht als reines Modem konfiguriert lässt...aber vermutlich hat es damit nichts zu tun.

Edit:
Ist es notwendig, während der Certificatserstellung den Port 80 zu öffnen? Denn damit hat es komischerweise geklappt? Jetzt bin ich total verwirrt.

[jonofe]

Habe mir das nochmal angeschaut. Das Validierungsverfahren über HTTPS (TLS_SNI-01) ist wohl im Januar 2018 von letsencrypt deaktiviert worden, da es nicht mehr sicher ist. In bestimmten Situationen kann man sich Zertifikate für Domains erstellen, die einem nicht gehören. Daher funktioniert die Validierung nur noch über HTTP (Port 80) oder per DNS. Für die DNS Validierung benötigt man allerdings Zugriff auf den DNS Server der Domain. Dies ist natürlich nicht möglich, da es ja eine DDNS Domain ist, die wir hier verwenden. Daher bleibt nur HTTP über Port 80. Daher werde ich die Doku entsprechend anpassen. Ggf. wird dies auch Auswirkungen auf das Renewal der Zertifikate haben. Das muss ich mir aber noch mal genauer anschauen.