Alexa4p3 für Dummies

[wvhn]

Kleines x. Sorry

[2malmama]

Hey Wolfram - auch hier kann ich aber grad angeben, was bei rauskommt:

systemctl status nginx.service
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-10-16 19:50:48 CEST; 22min ago
Docs: man:nginx(8)
Process: 497 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=1/FAILURE)

und hier noch weniger:

journalctl -Xe
journalctl: Ungültige Option -- X

[2malmama]

mmmh - also Andre, Du darfst Dich gerne totlachen - aber ich guck gerade ziemlich doof aus der Wäsche

ich vermute Du meinst die default-Dateie im Ordner sites-enabled und die https.conf in conf.d, oder?
aber ich finde in keiner der beiden Dateien einen "Symlink" oder "default" als Angabe.

Wenn es in der mydomain.myds.me-Datei im Ordner conf.d gehen sollte, dann habe ich meinen Server als default Server angegeben. Da kommt nur eine Stelle in Betracht:

listen 443 ssl default_server;
#server_name <mydomain>.<myds>.<me>;
<hier steht jetzt meine Angabe noch drunter>

[wvhn]

Wenn das Admin Interface läuft, müsste nginx auch laufen, oder? Das kannst Du ja sicherheitshalber nochmal abfragen mit

systemctl status nginx.service

wenn er nicht läuft kann man den Fehler mit

journalctl -Xe

anzeigen lassen. Ist das nicht erfolgreich, zeigen hoffentlich dass error log und das Access log von nginx mehr.

Gruß
Wolfram

P.S.: mal wieder zu spät. Sorry. Mach erstmal mit Andre weiter. Der steckt sicherlich tiefer drin in dem Thema.

[AndreK]

OK,

dann sollten wir mal sehen was in der /etc/nginx/conf.d/ steht und was in der /etc/nginx/sites-enabled steht.

Zwei Konfigurationen überschneiden sich hier - deshalb der Fehler.

Bitte mal prüfen ob in der /etc/nginx/sites-enabled eventuell noch "default" als symlink steht - Falls ja diesen löschen und den NGINX nochmal prüfen lassen
mit

sudo nginx -t

löschen des links mit

rm default

im Ordner /etc/nginx/sites-enabled

Gruss Andre

[2malmama]

ui - da brauch ich nicht viel zu anonymisieren....

sudo nginx -t
nginx: [emerg] the size 62914560 of shared memory zone "SSL" conflicts with already declared size 10485760 in /etc/nginx/conf.d/https.conf:43
nginx: configuration file /etc/nginx/nginx.conf test failed

Hab gleich mal in die https.conf gesehen in besagter Zeile ist folgendes zu finden:

ssl_session_cache builtin:1000 shared:SSL:60m;

[AndreK]

Hallo 2malmama ,

hier hat wohl der NGINX wieder ein Problem.
Was sagt Dir

sudo nginx -t

?

Zur Erklärung:
Mit dem Image von OnkelAndy wird der NGINX als Webserver verwendet, nicht der Apache
Wenn dieser nicht läuft ist die Visu auch intern nicht erreichbar (smartVISU) - also alles nicht dramatisch

Wenn die Config des NGINX passt wird die VISU automatisch wieder hell
Lass uns mal Teilhaben an der Ausgabe von "sudo nginx -t" - natürlich anonymisiert.

Gruss Andre

[2malmama]

Hallihallo - da bin ich wieder

vielen Dank Wolfram! Ich hatte schon Sorge, dass ich einfach zu viel quatsche....

Den Umstand mit dem Auskommentieren habe ich nicht weiter nachverfolgt, da die eigene Eingabe ja funktioniert hat und damit das Problem für mich vom Tisch war. Ich gucke aber gerne noch mal danach, wenn wir den Rest gelöst haben. Zwischendurch wage ich mich kaum an Nebenbaustellen.

Viel Spaß wenn die Kinder dann das erste Mal sagen: "Alexa mach das Licht im Wohnzimmer, den Fernseher und Mamas Computer aus"

Machen die aber nur ein einziges Mal, danach ändere ich für 24 Stunden das WLAN-Passwort.


Aber damit bin ich auch schon fast bei meinem Problem - bei der fehlenden Verbindung....


Ich geh mal Schritt für Schritt durch was ich gemacht habe (entsprechend der Anleitung wie der NGINX als ReverseProxy eingerichtet wird):

SSL zertifikat für DDNS erstellen mit sudo apt-get install certbot

Die /etc/nginx/snippets/letsencrypt.conf ist schon konfiguriert und derOrdner acme-challenge ist schon vorhanden, auch /etc/nginx/sites-available/default ist schon bearbeitet.

Weiter geht es mit sudo certbot certonly --rsa-key-size 4096 --webroot -w /var/www/letsencrypt -d <mydomain>.<myds>.<me>
Und wie beschrieben beginnt die Prozedur nach der Angabe der Mailadresse.

Nach dem Durchlauf kommt eine Erfolgsmeldung (sieht ganz anders aus als in der Anleitung). Trotz der Erfolgsmeldung gab es 2 identische Fehler, einer nach der Frage ob man seine E-Mailadresse der EFF zur Verfügung stellen möchte, der zweite bevor die Erfolgsmeldung kam:

fehler certbot.PNG
Da ich die Erfolgsmeldung, eine Speicherinformation und ein Ablaufdatum für den Key erhalten habe, habe ich der Sache nicht allzu viel Aufmerksamkeit gewidmet.

Die /etc/nginx/nginx.conf ist schon konfiguriert.

Dann klemmte es kurz daran, dass ich keine Berechtigung zum Befüllen der /etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf hatte....
(!!!) da war es wieder....: ich hatte das sudo vor dem nano vergessen..... danach gings dann.

In der Datei habe ich dann alle Eintragungen gemacht, nur ich bin mir nicht sicher, welche Angabe für den Port bei Network Plugin Weiterleitung angegeben werden muss. Hab jetzt erst mal 80 genommen. Welcher ist richtiger?

Beim Versuch zu NGINX zu reloaden war ich mir nicht sicher, welches Passwort da gewünscht wird, bin an der Eingabe gescheitert und hab daher einen reboot gemacht

Dann hab ich nach Anleitung noch die Passwort-Files für einen User angelegt - und den Test gewagt..... https://mydomain.myds.me

Und das wars... Verbindung abgelehnt!
Intern ist die SmartVisuOberfläche auch nicht mehr erreichbar; die AdminOberfläche schon.

Ich hab nochmal alle Dateien von oben eingesehen und keinen Fehler gefunden.
Ein LogIn beim DNS-Anbieter zeigt, dass - dort werden alle Ports wieder als geschlossen angezeigt werden

Beim Versuch sudo netstat -tulpn | grep nginx kommt nichts. Gar nichts. Auch nicht bei sudo netstat -tulpn | grep nginx.
(übrigens ist mir dabei aufgefallen, dass ich gestern beim Eingeben des Befehls das sudo vergessen hatte - daher die Fehlermeldungen! Ist halt bei mir alles nicht in Fleisch und Blut verankert.)

Was denn nu?

[wvhn]

Du solltest Schriftstellerin werden. Der Text liest sich gut

Nach dem Neustart von shNG muss man schon ein paar Minuten warten, bis alles wieder läuft. Gibt es einen Auszug aus dem shNG Log, der auf die Ursache für den Fehler nach Auskommentieren des knx-Plugins hinweist? yaml ist ziemlich empfindlich bei den Einrückungen - nur eine definierte Zahl an Leerzeichen ist zulässig und keine Tabs. Das ist auch für die weitere Konfiguration von shNG wichtig.

Viel Spaß wenn die Kinder dann das erste Mal sagen: "Alexa mach das Licht im Wohnzimmer, den Fernseher und Mamas Computer aus"

Gruß
Wolfram

[2malmama]

soooo - hallo Ihr alle zusammen!

Vielen Dank schon einmal für Eure Mithilfe!!!

Der aktuelle Stand hat ein wenig länger gedauert, aber sonst hätten mich die Kids gelüncht.... wie kann die Mama auch ständig vor der Kiste hocken... Der Hinweis darauf, dass man aber vielleicht sein Licht bald sprachlich steuern könnte, hat die Wogen wieder etwas geglättet....

Nachdem Start der Raspi mit dem frisch aufgezogenen Image habe ich zuallererst Samba wieder konfiguriert, sonst werde ich beim Bearbeiten der Dateien schnell totunglücklich...

Das Passwort mit

sudo smbpasswd -a <user>

gesetzt und mit

sudo reboot neu gestartet

Test über den Windows-Explorer - Samba funzt

Administratorobergläche funktioniert, SmartVisu ist auch aufrufbar

Vorsichtiger Vorabtest - weil es beim letzten Mal so wahnsinnig Schwierigkeiten gab - mit

sudo service nginx restart

, auch wenns eigentlich unsinnig ist.... Das ergab keine Fehler *puh* - sooo gut liefs noch nie!

Dann den Tipp von AndreK mit

sudo netstat -tulpn | grep nginx

probiert
Beide gewünschten Ports sind offen.
(hatte mich beim ersten Mal vertippt und statt | ein @ geschrieben - das war auch mal sehr aufschlussreich)
Kurzer Test über das Smartphone mit DNS über mobile Daten - Ich fasse es nicht!!! Da wird mir doch glatt der Nginx angezeigt.

Da es jetzt soooo gut lief - weiter im Text - bloß keine gefährliche Pause einlegen

Nun in der Plugin.yaml das knx-Plugin aktiviert (entkommentiert) - schwupp und da funktionierte die AdminOberfläche auf einmal nicht mehr. Die Verbindung wurde abgelehnt.

Mehrfache Neustarts brachten keine Veränderung, also wieder als Kommentar hinterlegt und die Infos unten per Hand angefügt. -> AdminOberfläche wieder erreichbar, knx in der AdminOberfläche hinterlegt und mit WebIF-Button hinterlegt. ServiceOberfläche erreichbar.

IPSchnittstelle in /etc/knxd.conf eingetragen:
KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -c -b ipt:IPSchnittstelle"
Dann beenden und neu starten

sudo systemctl stop knxd.socket
sudo systemctl stop knxd.service
sudo systemctl enable knxd.service
sudo systemctl enable knxd.socket
sudo systemctl start knxd.socket
sudo systemctl start knxd.service

Dann Funktionsprüfung

sudo systemctl status knxd.socket
sudo systemctl status knxd.service

Prüfung ob Verbindung zum KNX-BUS besteht:

knxtool groupsocketlisten ip:localhost

-> erfolgreich

test.yaml mit Testlampe erstellt ist schaltbar über AdminOberfläche (Kinder sind belustigt)
Die room_sleeping zum Testen im Testtemplate auf Visu angepasst und Lampe getestet -> Lampe geschaltet.

sooo - jetzt wage ich mich noch mal an die Alexa-Sache. Melde mich, sobald ich weiter bin oder verzweifel

Was soll die Aussage vom Dyndns-Anbieter, dass diese Ports geschlossen sind?
Ich kann mir höchstens vorstellen, dass er anzeigt, dass auf diesen Ports nix und niemand erreichbar ist.
Zumindest unter Port 80 sollte ja die SV erreichbar sein?!

Jetzt sieht's besser aus:
ports auf.PNG

Danke an Euch alle, dass Ihr das hier mit mir wuppt!!

[AndreK]

Hallo 2malmama ,

ich bin mir sicher, dass Du Deine Anforderungen komplett mit shNG und der SmartVisu abbilden kannst. Die Anbindung von Alexa ist wie bmx bereits erwähnte eher etwas aufwändiger.

Hier mal eine kurze Info wie die Kommunikation abläuft (bei der üblichen Konfiguration mit NGINX)

- der Router (Fritzbox) lauscht auf einem Port Deiner Wahl, kann 443 sein, muss aber nicht - nehmen wir für das folgende Setup Port 7443 ( Dieser Port wird auch in der Lambda-Funktion eingetragen)
- in der Lambda wird nur Deine DynDns-Adresse eingetragen https://deine.dyndns-Adresse.net (kein User, Password, keine php-Seite,...)
- der Router leitetet diesen Port auf den lauschenden Port am NGINX weiter. Auf welchem Port der NGINX beim Image von OnkelAndy lauscht kann ich im Moment nicht sagen
- um den Port des NGINX rauszufinden sollte

sudo netstat -tulpn | grep nginx

genügen - Wichtig als sudoer ausführen
- das funktioniert aber nur wenn der NGINX läuft
- wie Du in Post #11 geschrieben hast läuft Dein NGINX nicht. Was die Unzulänglichkeiten des NGINX betrifft kannst Du diese mittels

sudo nginx -t

genauer ermitteln.
- der NGINX, wenn er denn läuft, leitet nun die Anfrage an das Alexa-Plugin weiter - Standardmässig 9000. Die Anfrage für Alexa wird über den Pfad "/alexa" (siehe Lambda-Konfig) im NGINX ermittelt
- die Weiterleitungen sind in der "/etc/nginx/conf.d/<mydomain>.<myds>.<me>.conf" definiert.
- Es muss zunächst obige Datei entsprechend erstellt und konfiguriert werden, es muss ein Zertifikat via letsencrypt erstellt und eingebunden werden - siehe auch hier

Kommunikation :

AmazonCloud (7443) <=> (7443) Fritzbox (NGINX-PORT) <=> (NGINX-PORT) NGINX (9000) <=> (9000) shNG.Alexpa-Plugin

Ich hoffe das hilft Dir ein Stück weiter. Falls Du nähere Infos zu den Fehlern bei der NGINX-Konfiguration hast lass uns
teilhaben.

Viel Erfolg

Gruss Andre

[henfri]

Hallo,

Das Problem ist halt, dass Amazon mit dem Raspi keine Verbindung aufbauen kann.
Das würde ich als erstes Lösen. Vorher musst du bei Amazon nix machen.
Dazu musst du wenn ich mich recht entsinne nur den reverse-proxy einrichten.

Nun habe ich mich bei meinem DDNS-Anbieter eingeloggt - hier wird mir angezeigt, dass die Ports geschlossen wären. Auch eine LogIn-Abfrage kommt nicht. Mmh - wie krieg ich sie also nun auf?

Das Bild funktioniert ja jetzt. Ich verstehe es aber nicht. Was soll die Aussage vom Dyndns-Anbieter, dass diese Ports geschlossen sind?
Ich kann mir höchstens vorstellen, dass er anzeigt, dass auf diesen Ports nix und niemand erreichbar ist.
Zumindest unter Port 80 sollte ja die SV erreichbar sein?!

Auch wenn es für später nicht ratsam ist: Probier mal nach dem Aufsetzen, ob die SV vom Handy (ohne WLAN) erreichbar ist.

Gruß,
Hendrik

[psilo]

ich habe damals leider auch recht lange gebraucht, bis die alexa anbindung mal lief. aber wenn es läuft, lohnt sich die arbeit wirklich!

[2malmama]

ok

melde mich, sobald ich soweit bin

[henfri]

Ja, neu aufsetzen.
dann nur den nginx einrichten.
Dann erstmal dyndns und Router/portforwarding.