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

[asto]

Wow. Ich hatte inzwischen auch ein wenig probiert, aber deine Ausführung ist deutlich flexibler! Vielen Dank fürs teilen!

[junibart]

Hi, ich werde auch mit testen... besten Dank für die Entwicklungsarbeit!

Gunnar

[jonofe]

Dann werde ich für den Reverse Proxy bei meine Plan bleiben mit nginx.

Ich habe das mal zum Anlass genommen und das HowTo um nginx zu erweitern. So kann jetzt jeder das nehmen, was ihm besser "gefällt".

Wenn du also jetzt Kapitel 3,4,5,7 umsetzt, dann hast du einen nginx Reverse Proxy auf den EDOMI Server.

Update des HowTo's ist im ersten Post zu finden.

[saegefisch]

Hey Michael,

du sprichst mir mit allem aus dem Herzen... danke für Deine fundierte und umfangreiche Einschätzung!

Dann werde ich für den Reverse Proxy bei meine Plan bleiben mit nginx. Mit Deinen Infos wird das sicher schon einfacher. Wenn ich so weit bin, meld' ich mich vielleicht noch mal wegen der SSL-Zertifikate, damit nur dedizierte Geräte überhaupt durch den RevProxy kommen können. Schlanker WebServer wäre nginx oder Apache (ist bei mir im Wesentlichen "nur" ein paar leichte Wikis mit PHP) - da bin ich noch unentschlossen, nextcloud würde ich deren image nehmen (was wohl Apache sein wird). Da enden meine Anforderung. Mehr Krams will ich gar nicht haben. Wer soll das denn warten? Brauche die Zeit ja für edomi und schöne Visus - und noch für knapp 30.000 Dias meiner Eltern zum Scannen - vor x'mas wird das wohl nicht mehr fertig... erst noch die jährliche 12-Mann-Altherren-LAN-Party zwischen den Jahren bei mir im Keller...dann nginx...

Danke und viele Grüße,
Carsten

[wintermute]

Hi Carsten,

so Fragen wie "welche Software nimmt man am ehesten dafuer" sind ja nun wirklich nicht leicht pauschal zu beantworten, da kommt dann oft "ich kenn nur das", "dazu hab ich ne Anleitung im Internet gefunden" oder "hab ich schon immer so gemacht" - wird leicht zu einer Glaubensfrage

Ich komm aus dem Umfeld des Appliance-Baus und da ist klein und performant eigentlich immer das Totschlagargument - und da ist das so, dass ein (quasi) reiner Proxy wie nginx immer besser rauskommt als ein full-blown Webserver wie der Apache dessen Talente da eigentlich ueberhaupt nicht zur Geltung kommen und das, was man braucht eigentlich nur ueber ein Zusatzmodul realisiert wird.

mod_proxy ist tatsaechlich deutlich aelter als nginx, aber beide Programme glaenzen durch bisher ausserordentlich wenig Code-bezogene Sicherheitsprobleme.
nginx ist verdammt schnell, Apache(HTTPD) aber auch, die Flaschenhaelse liegen vermutlich bei beiden nicht in der eigentlichen Engine.

Auf einem embedded-System wuerde ich persoenlich keinen Apache verwenden, es sei denn es ist notwendig und erfordert Funktionalitaeten die kleine (und ueberschaubarere) Webserver nicht mitbringen. Einen nginx nun aber erst recht nicht, oder anders: ich sehe im nginx einen Proxy, keinen Webserver.
Wuerde ich einen Reverse-Proxy (oder gar eine Application-Level Firewall) auf einem Embedded-System aufsetzen muessen, wuerde ich DEFO nginx benutzen - es sei denn, es ist bereits ein Apache vorhanden. Waere das aber kein Embedded-System und Platz ist nicht das Problem, wuerde ich trotzdem einen nginx aufsetzen. Oder anders: ich sehe im nginx einen Proxy, keinen Webserver.

Ja, man kann vieles mit einem Multitool machen aber ich persoenlich bevorzuge es, spezialisierte Dinge fuer Spezialanwendungen einzusetzen; auch wenn der Apache das genauso gut koennen mag - auf jeden Fall zumindest die hier anfallenden Szenarien.

Ich finde nginx vielseitiger und einfacher zu konfigurieren, was nun aber auch wieder mit Erfahrungswerten zu tun hat. Nginx nutze ich privat sowie beruflich als Proxy (privat um mehrere HTTPS-Server hinter einer IP aufzustellen), Apache nutze ich privat sowie beruflich als Webserver. Ich bin da also relativ opportunistisch was die beiden Pakete angeht, aber ich hab das bisher immer so gemacht
Wenn schon eine Loesung von beiden da ist oder sich eine einfacher installieren liesse, wuerde ich fuer diese Szenarien dann einfach darauf zurueck greifen.

Nginx muss - oder ich wuerde es jedenfalls - auf CentOS selbstgebaut werden, das schreckt vielleicht schon viele ab. Dafuer ist IMHO die Config beim nginx einleuchtender und flexibler. Und um Deine Frage diesbzgl zu beantworten, eine HTTPS auf intern-HTTP Konfiguration im nginx sieht exemplarisch so aus (nicht alles davon ist notwendig, aber so ist es dann schon relativ rund):

server {
        listen 443 ssl;
        ssl on;
        ssl_certificate         /etc/nginx/certs/domain.pem;
        ssl_certificate_key     /etc/nginx/certs/domain.key;
        server_name domain.de www.domain.de edomi.domain.de;

        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
        ssl_prefer_server_ciphers on;
        ssl_dhparam /etc/nginx/dhparams.pem;
        ssl_protocols  TLSv1 TLSv1.1 TLSv1.2; 

    proxy_redirect off;
    proxy_set_header    Host        $host;
    proxy_set_header    X-Real-IP    $remote_addr;
    proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;

    proxy_cache_bypass 1;
    proxy_max_temp_file_size 0;

    proxy_connect_timeout 90;
    proxy_send_timeout 90;
    proxy_read_timeout 90;

    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
    proxy_temp_file_write_size 64k;

    location / {
        proxy_pass http://192.168.x.y;
    }

}

server {
    listen 80;
    server_name domain.de www.domain.de edomi.domain.de;
        proxy_redirect off;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_cache_bypass 1;
        proxy_max_temp_file_size 0;

        proxy_connect_timeout 90;
        proxy_send_timeout 90;
        proxy_read_timeout 90;

        proxy_buffer_size 4k;
        proxy_buffers 4 32k;
        proxy_busy_buffers_size 64k;
        proxy_temp_file_write_size 64k;

        location / {
                proxy_pass http://192.168.x.y;
        }

}

Ich selber mag diese Sprachdinger uebrigens nicht, ich seh das eher so

amazonecho1.jpg

[saegefisch]

Hi André,
coole Lösung - auch wenn ich mich noch gegen einen Mikrofon-Spion in meinem Haus wehre. Meine Frau auch noch, meine Kinder finden's must-have...

Bin aber über bei Reverse Proxy hellhörig geworden, da das bei mir noch ansteht, ich aber damit keine Erfahrung habe. Allerdings hatte ich mir vorgenommen den (meines Wissens für solche Anforderungen konzeptionell) viel leichtgewichtigeren nginx dafür nehmen zu wollen - das sollte sich auch im Stromverbrauch, CPU-Last des Servers,... positiv auswirken. Du hast Dich allerdings für den "alten Hasen" oder "sicheren Hafen" Apache entschieden. Wär' das nicht auch aus Deiner Sicht noch ein Quäntchen cooler mit lightwight nginx statt Apache? Oder habe ich da falsches Halbwissen zu den beiden Lösungen? Auch wenn es etwas OT ist: Deine Einschätzung (und die anderer thematisch Sehenden) dazu fänd' ich spannend.

Du ahnst auch die versteckte Suggestivinformation - wenn Du das ähnlich sehen würdest, dann stiege die Chance für mich für eine Anleitung eines Sehenden - gerade bei einem Reverse Proxy sind Fehler ja eher ... nun ja... unglücklich...

Viele Grüße,
Carsten

[jonofe]

Ich werde die Tage mal Deinen Weg in EDOMI umsetzten, bin mal gespannt wie Dein
Weg läuft....

Hi Marcus,
Super, da bin ich dann auch gespannt. Wenn man alles nachträglich dokumentiert und noch mal durchspielt, dann vergisst man schnell mal was.
Danke schon im Voraus für dein Feedback.
Gruß, André

[tunneltruppe]

...booohhhh Andrè, da hast Du Dir aber Arbeit gemacht!!! DANKE DIR!!
Ich hatte Werner im HS- Baustein "schwach" dazu unterstützt und weiß wass da an
Arbeit drin steckt. Meine Alex/ DOT zickt noch mit der Sprache rum.
Ich werde die Tage mal Deinen Weg in EDOMI umsetzten, bin mal gespannt wie Dein
Weg läuft....
Gruß Marcus

[jonofe]

Tach auch,

Wie bereits angekündigt, habe ich mich mal an einem Alexa Custom Skill für EDOMI versucht, um damit sprachbasierte Steuerungsbefehle über Amazon Echo Devices an EDOMI zu senden. Da es doch ein wenig aufwendig ist und ich es gerne auch noch mal reproduzieren können möchte habe ich es mal im Detail dokumentiert. (HowTO im Anhang zu diesem Post)

Diejenigen, die vom Umfang und Komplexität der Dokumentation nicht abgeschreckt werden, können dies gerne mal nachbauen und ihre Erfahrungen berichten. Das HowTo ist sicher nicht fehlerfrei, so dass ich mich über Feedback zur Verbesserung freue.

Grundsätzlich beruht der Ansatz auf einem RPi als Reverse Proxy, um den EDOMI-Server nicht direkt aus dem Internet zugänglich machen zu müssen. Die Doku startet ganz am Anfang mit der Installation des RPI und setzt sich wie folgt zusammen:

• RaspberryPI Setup
• Portforwarding einrichten
• DynDNS einrichten
• Alternative 1: Apache2 SSL + ReverseProxy
• Alternative 2:nginx SSL + ReverseProxy
• Edomi Server konfigurieren (SSL)
• Alexa LBS und Custom Skill Skript installieren und konfigurieren
• Alexa Custom Skill anlegen und konfigurieren

Voraussetzung sind:

• Alexa Echo oder Echo Dot
• Amazon Account
• EDOMI-Server
• RaspberryPI
• DSL Router mit Portforwarding und DynDNS

Zur Lösung gehört ein Custom Skill Skript (alexa.php) sowie zwei neue LBS (Alexa Receiver und Alexa Command Validator)
Alle notwendigen Dateien sind im Edomi Download Portal zu finden. Zusätzlich enthält das HowTo einige Links, z.B. um Raspbian zu downloaden, welches die Basis für den RPI bildet. Im Alexa Receiver LBS ist noch ein weiteres ZIP File enthalten, welches dann das Skill Skript (alexa.php) enthält, sowie zwei PNG Icons, um dem Skill auch das passende Aussehen in der Alexa App zu geben.

Das gesamte HowTo findet ihr weiter unten als PDF angehängt zu diesem Thread.
Die Links im PDF sollten anklickbar sein und auch die Befehle sollten kopierbar sein.

Gerne unterstütze ich bei einem ersten Proof of Concept, um so auch das HowTo schrittweise zu verbessern. Ich weiß, es sieht kompliziert aus, aber ich hoffe, wenn man sich 1:1 an das HowTo hält, das man recht weit kommen sollte.

Wer also Lust hat es mal auszuprobieren kann sich gerne hier melden.

Wichtig:
Wie bereits in einem anderen Thread erwähnt, benötigt ein Custom Skill immer einen Invocation Name, so dass sowas wie

Alexa, schalte das Licht im Wohnzimmer ein.

leider nicht funktioniert. Dies sieht dann beim Custom Skill wie folgt aus:

Alexa, starte EDOMI und schalte das Licht im Wohnzimmer ein.

Dafür hat der Custom Skill den Vorteil, dass er 100% flexibel ist. So können z.B. auch Farben von HUE Leuchten geändert werden mit

Alexa, starte EDOMI und ändere die Farbe der HUE Leuchten im Wohnzimmer auf blau.

Dies alles nur als Randnotiz, bevor sich jemand die Mühe macht den Custom Skill aufzusetzen und dann vom Ergebnis enttäuscht ist.

Viel Spaß damit ...

André