Ankündigung

Einklappen

Nicht vergessen: Das KNX-UF-Symposium by eib-tech in München am 3. November 2017!

Mehr anzeigen
Weniger anzeigen

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

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    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é
    Angehängte Dateien
    Zuletzt geändert von jonofe; 12.02.2017, 21:12.

    #2
    ...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

    Kommentar


      #3
      Zitat von tunneltruppe Beitrag anzeigen
      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é

      Kommentar


        #4
        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

        Kommentar


          #5
          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):

          Code:
          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

          Kommentar


            #6
            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
            Zuletzt geändert von saegefisch; 20.12.2016, 02:36.

            Kommentar


              #7
              Zitat von saegefisch Beitrag anzeigen

              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.

              Kommentar


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

                Gunnar

                Kommentar


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

                  Kommentar


                    #10
                    Zitat von jonofe Beitrag anzeigen

                    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.
                    Danke André! Mit Michaels und Deinem Input wird's sogar für mich und mein "interessiertes Laientum" vermutlich möglich sein, den nginx als RevProxy sicher zum fliegen zu bringen. Aber ganz sicher nicht auf dem edomi-Server selber; er kommt auf die andere (ubuntu-)Kiste. Aber wie gesagt - in der Reihe steht es gerade nicht ganz vorne auf der Prio-Liste: x'max/Familie, Steuer, LAN-Party, Dias, nginx, visu,.... Geb dann aber auf jeden Fall Rückmeldung. Ihr seid beide wirklich Gold wert und bewundere Euer Können und tiefe Kenntnis. Jetzt aber Schluss mit meiner Lob-huddelei... ...zumindest für 2016

                    Ich finde, dafür dürft Ihr Euch beide zum Fest noch was schönes gönnen. Einfach mal selbst beschenken! Da schauen die Partner immer so...ähm...lustig , wenn das fetteste Geschenk von einem selber kommt...
                    Zuletzt geändert von saegefisch; 20.12.2016, 21:31.

                    Kommentar


                      #11
                      Kurze Rückmeldung: Schalten und Dimmen läuft schonmal perfekt!

                      Vielleicht kannst du in der Doku zum LBS19000647 - Alexa Command Validator noch kurz schreiben, dass man mit |-getrennt mehrere Begriffe/Optionen in den Feldern E3, E4, E5 und E6 zur Validierung eintragen kann, damit der Befehl ausgeführt wird. Dieses Feature macht die Konfiguration zur Steuerung deutlich einfacher und sollte auch zu diesem frühen Stadium schon beschrieben werden.

                      Ansonsten nochmal - vielen Dank! Ich bin begeistert!

                      Kommentar


                        #12
                        Zitat von asto Beitrag anzeigen
                        Kurze Rückmeldung: Schalten und Dimmen läuft schonmal perfekt!

                        Vielleicht kannst du in der Doku zum LBS19000647 - Alexa Command Validator noch kurz schreiben, dass man mit |-getrennt mehrere Begriffe/Optionen in den Feldern E3, E4, E5 und E6 zur Validierung eintragen kann, damit der Befehl ausgeführt wird. Dieses Feature macht die Konfiguration zur Steuerung deutlich einfacher und sollte auch zu diesem frühen Stadium schon beschrieben werden.

                        Ansonsten nochmal - vielen Dank! Ich bin begeistert!
                        Ich hatte eigentlich erwartet, das niemand so schnell so weit kommt, nicht, weil ich es keinem zutraue, sondern weil ich Fehler/Lücken in meiner Doku vermutet hatte.

                        Hast du es komplett mit Reverse Proxy umgesetzt? Ohne irgendwelche Lücken in der Doku?
                        Aber cool, dass es auf Anhieb funktioniert hat. Wenn du weiteres Feedback hast, dann her damit.

                        Ich werde kurzfristig die beiden LBS dokumentieren. Wollte es einfach schon mal vorab veröffentlichen, um euch die Chance zu geben schon mal damit zu starten. Dunhast es aber richtig erkannt, die Eingänge können mit den erwarteten Werten belegt werden. Mehrere Möglichkeiten werden mit | getrennt. Wenn der Value am Eingang frei bleibt, dann wird der Wert, der ankommt auf den Ausgang gegeben.
                        Prozente werden in 10er Schritten unterstützt, d.h. 10, 20, 30,...,100. Am Value Ausgang kommt i.d.R. direkt ein Wert an, den man in Edomi weiter verwenden kann, d.h. kein 'ein', 'aus', 'an' sondern 0 und 1 bzw. kein "vierzig" sondern 40. Das macht auch das Skill Skript. Und es sendet per tcp socket an den Receiver LBS, so dass, das Skillskript auch ohne viel Aufwand für andere Logik Engines wie smarthome.py oder HS verwendet werden kann. Es muss lediglich ein Listener vorhanden sein, der die Nachrichten empfängt und dann zur Auswertung bereitstellt.

                        Soweit für heute ... morgen mehr zur LBS Doku ....
                        Zuletzt geändert von jonofe; 21.12.2016, 06:08.

                        Kommentar


                          #13
                          Ich hab ehrlich gesagt erst ab Kap. 9 richtig angefangen zu lesen. ReverseProxy und CustomSkill hatte ich durch meinen eigenen Proof of Concept schon fertig und musste echt nicht viel umstellen.
                          Über die 10er Schritte beim Dimmen war ich auch kurz gestolpert, das Raster war aber für mich ok.

                          Kommentar


                            #14
                            Zitat von asto Beitrag anzeigen
                            Ich hab ehrlich gesagt erst ab Kap. 9 richtig angefangen zu lesen. ReverseProxy und CustomSkill hatte ich durch meinen eigenen Proof of Concept schon fertig und musste echt nicht viel umstellen.
                            Über die 10er Schritte beim Dimmen war ich auch kurz gestolpert, das Raster war aber für mich ok.
                            Okay. Klingt gut.
                            Das mit den Prozenten hatte ich zunächst mit einem vordefinierten Datentyp gemacht (AMAZON.Number), aber da ist die Erkennung im Moment sehr schlecht. Zu viele Zahlen, die sich ähnlich anhören. Es gab immer wieder Verwechslungen, insbesondere, 17 und 70 und 15 und 50, etc. Daher bin ich zu 10er schritten mit eigenem Custom Type. Da kann man auch noch problemlos die 5er Zwischenschritte ergänzen.

                            Was echt schade ist, dass man in der Amazon Dev Console noch keine Skill Konfiguration als Ganzes, z.B. JSON File hochladen kann. das würde die Konfiguration extrem vereinfachen und die Doku um 50% reduzieren.

                            Kommentar


                              #15
                              Moin jonofe , top Arbeit, allerdings habe ich bis jetzt die eine Anmeldung für den Echo dot. Bin aber froh das du das schon am laufen hast.
                              Wahnsinn was hier passiert und was du für Arbeit da lässt, aber dir geht es wahrscheinlich wie vielen, es ist Hobby^^

                              Eine Frage zum Invocation Name...Ist der Fix gesetzt oder kann ich den ersetzen durch einen eigenen Namen?

                              Gruß

                              Kommentar

                              Lädt...
                              X