Umfrage: Amazon Echo

[henfri]

Hallo,

beim Durchlesen der Readme bin ich natürlich auch über den Reverse-Proxy gestoßen. Dabei gefällt mir nicht, dass dies ein externes Programm übernehmen muss. Lässt sich das nicht vermeiden? Ich denke, das wird für Viele eine Hürde.

Was ich hinsichtlich der Sicherheit nicht verstehe:
Alexa und Sh.py sind im Heimnetz. Lediglich die Spracherkennung läuft extern. Warum kann Alexa nicht einen Hash o.ä. des Kommandos, welches an die Cloud geht an Sh.py senden. Da dies aus dem lokalen Netz kommt, kann dem getraut werden. Nur wenn jetzt ein Kommando von Amazon kommt, welches diesen Hash auch enthält, wird das Kommando ausgeführt.

Gruß,
Hendrik

[hotzen]

Also ich halte wenig davon den Weg cherrypy mit Gewalt rauszunehmen.
-das ist der de facto Webserver unter python
-die dependency haben mehrere plugins
-Hand crafted http foo ist nie besser als das gepflegte framework

ich Weiss überhaupt nicht woher diese Abneigung stammt

[patrickgoll]

Und genau dafür ist der OAuth Token da. Dieser Mechanismus ist von Amazon so gewollt und implementiert. Deine App wird also mit einem OAuth Provider verknüpft und einmalig legitimiert. Danach kannst du den OAuth Token als "Hash" nehmen um zu verifizieren ob deine Anfrage wirklich von der richtigen Stelle kommt. Dieser Mechanismus ist nur im jetzigen Entwicklungsstand des Alexa Plugins nicht implementiert. Ansonsten sollte das kein Problem sein, was du da beschreibst.

[hotzen]

Das ist nicht implementiert weil das plugin nicht als oauth Server funktioniert und auch überhaupt nicht notwendig ist. Wir machen ja keinen zentralen cloud Service für das knx user forum, sondern jeder konfiguriert sich das als eigenen Alexa skill. Damit ist die Authentifizierung per oauth reine pro forma, die einfach von Amazon erzwungen wird für das Standard setup: zentraler cloud service vom device Hersteller für alle device Kunden. Und nicht: je smarthome ein custom skill und custom "cloud" endpoint.

[psilo]

hotzen mir ist in dem setting nur nicht klar, warum du einen voll aufgeblasenen webserver brauchst. und wo ausser im backend (wo ein webserver irgendwo ja sinn macht) ist das noch dependency?
für den reverse proxy fände ich eine anleitung via apache sinnvoller, da den wegen der smartvisu sowieso die meisten am laufen haben.

[hotzen]

und wenn noch mehr leute keinen reverse Proxy installieren wollen, wozu ich dringend rate, was sehr einfach ist und die Nutzung des Smarthomes echt schön&sicher macht - dann müssen wir ssl direkt im plugin Service unterstützen und spätestens dann ist cherrypy Pflicht weil selbst auf nem Socket aufsetzen ist harakiri.
aldo weiterhin, ich sehe überhaupt gar keinen Grund cherrypy loszuwerden. Die sporadische? Kompatibilität zu backend-plugin ist für manche ein Problem, für mich nicht, aber bestimmt kein Grund deshalb DIE python dependency über Bord zu werfen. Die Leute mit dem Problem sollten vielmehr mal analysieren warum das kracht, damit man das sauber fixen kann

[psilo]

hotzen das ist schön wenn sie für dich kein problem ist, beim akzeptieren von PRs denke ich normal aber nicht nur an mich
ehrlich gesagt klingt der tonfall auch eher danach, dass du null lust darauf hast, das ding zu maintainen wenn es bei usern probleme gibt, so lange es bei dir geht.

gibt mir einen CURL gegen dein Plugin und ich analysiere.. Aktuell kracht es nicht, ich habe aber auch keine Items usw.. nur Plugin "raw" eingebunden. mglw kracht es erst mit items oder wenn requests reinkommen

einen kanal (und wenns auch nur per reverse proxy mit basic auth ist) auf zu machen, ist für mich auch immernoch der grosse knackpunkt.. dann versuche ich lieber weiter die google voice api auf meinem raspi anzubinden, auch wenn es weniger fancy ist als so einen lautsprecher in der kueche stehen zu haben. aber mal sehen, vielleicht überzeugt ihr mich ja doch noch.

[hotzen]

- klar maintaine ich das so wie ich zeit dafür finde
- das plugin bietet einen json http service, das ist per definition ein webserver - ich kann nirgends erkennen, dass cherrypy als fett, bloatet, aufgeblasen oder sonstwas gilt
- ich benutze nicht das backend plugin und werde deshalb auch nicht tief und aufwändig analysieren wo die incompat liegt
- ich werfe nicht cherrypy besseren wissens über bord, nur weil es probleme mit einem anderen plugin gibt, das ebenfalls diese dependency nutzt
- sofern wir SSL nachrüsten sollten für die reverse-proxy-verächter, ist cherrypy sowieso pflicht
- apache statt nginx ist eine gute idee, es steht jedem frei das im open-source gedanken in einer apache.md o.ä. zu dokumentieren und beizusteuern

ich werde mich natürlich bemühen den pull request sauber durchzubekommen aber ich werde hier auf keinen fall jeden feature-wunsch an dieses plugin erfüllen.
mir ist es auch völlig schleierhaft woher diese anspruchshaltung kommt.

[psilo]

hotzen du musst garnichts analysieren, sag mir einfach wie ein standard request inkl http header + url aussieht

PS: eine gewisse anspruchshaltung (requirements-files, version nach schema, etc). kommt daher, dass wir sonst in 1-2 jahren kunterbuntes chaos haben.. wir sollten die kernthemen schon stringent durchziehen. immerhin ists ja ein smartplugin und das logging ist auch ok. daher sorry wenn das feedback etwas arg meckernd rüberkommt.
ich sehe das backend ähnlich wie das cli plugin als relativ kernnahen bestandteil. daher ist es mir wichtig. ich habe zudem sicher mehrere wochen zeit in das ding versenkt und werde sicherlich noch einige versenken.

als Msinn angefangen hat mein enigma2 zu testen, gings mir erst genauso.. aber nur so ist das ding massentauglich geworden. nur für meinen use case hätte ich mir sicher 3 tage entwicklung sparen können

[hotzen]

POST / HTTP/1.1
HOST: alexa.FOO
content-type: application/json
authorization: Basic FOO==
content-length: 295

{
    "header": {
        "messageId": "6d6d6e14-8aee-473e-8c24-0d31ff9c17a2",
        "name": "DiscoverAppliancesRequest",
        "namespace": "Alexa.ConnectedHome.Discovery",
        "payloadVersion": "2"
    },
    "payload": {
        "accessToken": "OAuthTokenFoo"
    }
}

[patrickgoll]

psilo Vielleicht kann ich dir mit dem Request helfen. Ich habe sowohl das Plugin, als auch einen Echo Dot am laufen. Das heißt mein Service ist voll integriert. Außerdem habe ich das mit dem backend Plugin als erster bemerkt. Ich nutze es nämlich (würde es, wenn es mit alexa kompatibel wäre).

Hast du den ganzen Thread schon gelesen? Ich habe ein paar mal beschrieben, welchen JSON Discovery man zum Beispiel gegen den Service feuert. Das kann man auch sehr gut aus der aws Konsole von Amazon machen.

[psilo]

patrickgoll ich habe den ganzen amazon kram derzeit nicht am laufen und will das auch nicht. es muss euch doch möglich sein, mir zu sagen, wie ich die webschnittstelle lokal aufrufen kann? hast du mal getestet wann das backend bei dir kracht? erst wenn du items hast? erst wenn amazon antwortet? schwer euch zu helfen wenn ich es nicht reproduziert kriege.

[hotzen]

Server: nginx
Date: Sat, 03 Dec 2016 15:19:47 GMT
Content-Type: application/json
Content-Length: 942
Connection: keep-alive

{
  "payload": {
    "discoveredAppliances": [
      {
        "applianceId": "diningroom-lamp",
        "isReachable": true,
        "actions": [
          "turnOff",
          "turnOn"
        ],
        "version": "0.7.0",
        "additionalApplianceDetails": {
          "item2": "root.item_only_on",
          "item1": "root.item_only_off"
        },
        "friendlyName": "Diningroom Lamp",
        "friendlyDescription": "Diningroom Lamp",
        "manufacturerName": "smarthomeNG.alexa",
        "modelName": "smarthomeNG.alexa-device"
      },
      {
        "applianceId": "livingroom_lamps",
        "isReachable": true,
        "actions": [
          "turnOff",
          "turnOn"
        ],
        "version": "0.7.0",
        "additionalApplianceDetails": {
          "item2": "root.livingroom_lamps.main",
          "item1": "root.livingroom_lamps.couch"
        },
        "friendlyName": "Livingroom",
        "friendlyDescription": "Livingroom",
        "manufacturerName": "smarthomeNG.alexa",
        "modelName": "smarthomeNG.alexa-device"
      }
    ]
  },
  "header": {
    "payloadVersion": "2",
    "messageId": "93df4f8d0fb94d3bb1e5313879add892",
    "name": "DiscoverAppliancesResponse",
    "namespace": "Alexa.ConnectedHome.Discovery"
  }
}

[patrickgoll]

Okay kann ich verstehen. Nein so intensiv habe ich den Fehler noch nicht debugged, kann ich aber gleich mal machen. Ich hatte das Gefühl, dass das bei mir schon krachte, als ich einfach beide Plugins in der plugin.conf aktiviert hatte und smarthome durchgestartet habe. Aber ich werde das reproduzieren.

[psilo]

hmm das setzt jetzt schon mal items voraus.. also muss ich doch anfangen das ding einzurichten. beide plugins gehen hier wie gesagt fehlerfrei, alexa startet laut log auch... ich dusche schnell, danach lege ich mal items an