alexa-fhem: amazon alexa smart home skill für fhem

[MadMax-FHEM]

Ich habs inzwischen selbst gelöst.

Wäre noch nett zu schreiben wie...

Gruß, Joachim

[Scheuffelhut]

Guten Abend,

erstmals möchte ich mich bei allen bedanken die die Grundlagen für den Custom Skill mit FHEM gelegt haben. Ich lese hier schon eine Zeitlang mit und habe inzwischen auch einige Geräte zum laufen gebracht.

Mein aktuelles Problem ist ein Rolladen über KNX der zwar über FHEM einwandfrei funktioniert, aber über Alexa Probleme macht.
Hier mal das List des Rolladens:

Code Auswählen Erweitern

Internals:
   DEF        6/0/201:DPT5.001:dimmen 3/0/201:DPT1:schalten 5/0/201:DPT5.001:wert 4/0/201:DPT1:stop
   DEVNAME    OG_Robert_Rolladen_Ost
   IODev      KNX
   KNX_MSGCNT 7
   KNX_RAWMSG C0111bw050c9ff
   KNX_TIME   2017-06-05 21:30:41
   LASTInputDev KNX
   MSGCNT     7
   NAME       OG_Robert_Rolladen_Ost
   NR         264
   NTFY_ORDER 50-OG_Robert_Rolladen_Ost
   STATE      zu
   TYPE       KNX
   Gaddr:
     1          6/0/201
     2          3/0/201
     3          5/0/201
     4          4/0/201
   Gcode:
     1          060c9
     2          030c9
     3          050c9
     4          040c9
   Model:
     1          dpt5.001
     2          dpt1
     3          dpt5.001
     4          dpt1
   Readings:
     2017-06-05 18:41:31   dimmen-get      1 %
     2017-06-05 18:41:31   dimmen-set      1 %
     2017-06-05 21:30:41   last-sender     1/1/27
     2017-06-05 21:30:12   schalten-get    on
     2017-06-05 18:42:38   schalten-set    off
     2017-06-05 21:30:41   state           zu
     2017-06-05 18:42:07   stop-get        on
     2017-06-05 18:42:07   stop-set        on
     2017-06-05 21:30:41   wert-get        100 %
   Readingsname:
     1          dimmen
     2          schalten
     3          wert
     4          stop
Attributes:
   IODev      KNX
   alexaName  robert rolladen ost
   alexaRoom  robert,obergeschoss
   event-on-change-reading .*
   eventMap   /on g4:stop/on g2:zu/off g2:auf/value:slider,0,1,100 g3
   genericDeviceType blind
   group      Rolladen
   homebridgeMapping clear TargetPosition=state::value,cmd=value
   room       KNX,alexa
   slider     0,1,100
   stateCmd   {if(ReadingsVal($name,"wert-get","") eq "0 %"){sprintf("%s","auf");}elsif(ReadingsVal($name,"wert-get","") eq "100 %"){sprintf("%s","zu");}else{sprintf("%s",ReadingsVal($name,"wert-get",""));}}
   webCmd     auf::zu::stop::value

im Alexa.log erscheint der Rolladen wie folgt:

Code Auswählen Erweitern

[2017-06-05 18:41:33] [FHEM] homebridgeMapping: clear TargetPosition=value,cmd=+
[2017-06-05 18:41:33] [FHEM] OG_Robert_Rolladen_Ost is blind
[2017-06-05 18:41:33] [FHEM] OG_Robert_Rolladen_Ost has
[2017-06-05 18:41:33] [FHEM]   TargetPosition [value]
[2017-06-05 18:41:33] [FHEM] { reading: 'value',
  cmd: ' ',
  device: 'OG_Robert_Rolladen_Ost',
  informId: 'OG_Robert_Rolladen_Ost-value',
  characteristic_type: 'TargetPosition',
  log:
   { [Function: bound ]
     debug: [Function],
     info: [Function],
     warn: [Function],
     error: [Function],
     log: [Function],
     prefix: 'FHEM' } }

Im alexamapping ist es so definiert:

Code Auswählen Erweitern


TargetPosition=verb=mach,articles=den,values=auf:1;zu:100
TargetPosition=verb=stelle,valuePrefix=auf,values=AMAZON.NUMBER,valueSuffix=prozent


Damit kann ich zwar den Rolladen öffnen, schließen und auf Zwischenwerte setzen, aber wenn ich anstatt auf:1 auf:0 verwende wird die Position 0% nicht angefahren. Das ist auch bei einem Set-Befehl in der Eingabezeile so.

Außerdem habe ich das homebridgemapping immer noch nicht verstanden. Wäre es hier nicht auch möglich

Code Auswählen Erweitern

TargetPosition=verb=mach,articles=den,values=auf:auf;zu:zu
zu definieren und das öffnen und schließen mit dem homebridgemapping zu lösen?
In dem Fall kommt bei mir
"set OG_Robert_Rolladen_Ost value zu"
an das
"set OG_Robert_Rolladen_Ost zu"
heißen sollte. So funktioniert es auch bei der direkten Eingabe.

Kann mir da jemand mit dem passenden homebridgemapping helfen? Habe schon im Forum gesucht aber leider nichts passendes gefunden.

Gruß Robert

[oeiber]

Hallo!

Ich habe folgende Konstilation: Alexa Fhem läuft hinter einem Apache als Reverse Proxy, da sich AWS Lambda mit Zertifikaten authentifiziert.
Ist möglich, Alexa Fhem nur an das Loopback-Interface (127.0.0.1) zu binden (ähnlich wie der Parameter global bei fhemweb)?
Danke für eure Hilfe!

LG

Olli

[amenomade]

Ist möglich, Alexa Fhem nur an das Loopback-Interface (127.0.0.1) zu binden (ähnlich wie der Parameter global bei fhemweb)?

Wofür? Wenn Du hinter einem Proxy läufst, ist sowieso der Port 3000 von  Alexa Fhem von Aussen nicht direkt erreichbar?

[oeiber]

Das ist richtig.
Dennoch hätte ich gerne dass ser Dienst nur auf localhost lauscht.

[amenomade]

Ich verstehe den Zweck immer noch nicht aber Du kannst immer den Port 3000 im Firewall des Rechners für inbound calls sperren.

[mcmxb]

Ich hätte da auch mal eine kurze Frage...

Ich bin dabei den Custom Skill einzurichten. Leider habe ich ein kleines Problem mit den CustomSlotTypes unter FEHM im Alexa-Device.
Beim Aufruf von get alexa customSlotTypes wird mir nur eine leere Liste ausgegeben.
Sprich customSlotTypes scheint leer zu sein.

Hat hier einer eine fixe Idee wie ich das Problem lösen könnte?

PS: der Alexa-Smarthome-Skill ist eingerichtet und läuft auch bereits einwandfrei.

Mit freundlichen Grüßen
der Henrik

[justme1968]

@oeiber: bau mal in lib/server.js die zeile

Code Auswählen Erweitern

this.server.listen(this._config.alexa.port, function(){ auf

Code Auswählen Erweitern

this.server.listen(this._config.alexa.port, "127.0.0.1", function(){um und schau ob es das macht was du möchtest.

[oeiber]

@oeiber: bau mal in lib/server.js die zeile

Code Auswählen Erweitern

this.server.listen(this._config.alexa.port, function(){ auf

Code Auswählen Erweitern

this.server.listen(this._config.alexa.port, "127.0.0.1", function(){um und schau ob es das macht was du möchtest.

Danke!
Funktioniert genau so wie es soll

Muss ich halt dann bei jedem update nachpatchen

LG

Olli

[justme1968]

zumindest so lange bis ich das einbaue. ich bin mir aber noch nicht sicher ob ich das möchte. es wäre eine zusätzliche mögliche fehlerquelle die dann später mehr aufwand macht.

[amenomade]

@justme1968: das in der .listen Funktion in server.js hatte ich schon gefunden und auf Basis dieser Seite https://stackoverflow.com/questions/10068714/how-to-get-node-js-express-to-listen-only-on-localhost
hätte ich die gleiche Änderung vorgeschlagen.

Hab ich aber nicht, da ich die gleiche Vermutung wegen Fehlerquelle wie Du gehabt habe. Das ist meines Achtens ein Bedarf, das nur für 0,0001% der Benutzer sinnvoll wäre... wenn überhaupt (den Zweck habe ich immer noch nicht verstanden - geteiltes internes Netzwerk, wo man die Mitglieder nicht vertraut? Frau ist auch Entwicklerin, und man will nicht, dass Sie das gleiche alexa-fhem mit Ihrem eigenen Fhem Server nutzt?... wirklich unklar).

[amenomade]

@mcmxb: Hast Du die gewünschte Geräte in deiner alexaRoom eingestellt, und alexaName / alexaRoom / genericDeviceType usw attributes gestellt?

Code Auswählen Erweitern

attr Alexa.Party alexaName party
attr Alexa.Party alexaRoom alexaroom
attr Alexa.Party genericDeviceType switch
attr Alexa.Party room AlexaRoom # wie in config.json


[oeiber]

zumindest so lange bis ich das einbaue. ich bin mir aber noch nicht sicher ob ich das möchte. es wäre eine zusätzliche mögliche fehlerquelle die dann später mehr aufwand macht.

Sicherlich lässt sich über die Sinnhaftigkeit streiten. Ich vertrete aber nach wie vor meine Meinung: Wenn der Dienst auf der gleichen Maschine hinter einem Proxy läuft, ist es unnötig, dass dieser auf anderen IPs horcht. Rudi hat dies ja offensichtlich auf für FHEMWEB integriert.

Vielleicht wäre es ein Kompromiss, einen optionalen Parameter wie "localhostOnly":true einzubauen.
Wenn ich das nicht für sinnvoll erachtet, dann ist es auch nicht schlimm.
Ich möchte die Diskussion auch nicht mehr ausweiten, da an dieser Stelle sicherlich über wichtigere Dinge diskutiert werden sollte.


Übrigens: alexa-fhem ist wirklich eine geniale Entwicklung!!!!

[amenomade]

Eigentlich hab ich in der Nacht ein bisschen überlegt. Das wäre doch nicht schlecht, die Möglichkeit anzubieten, dass alexa-fhem nur auf bestimmten Hosts lauscht. Die von oeiber vorgeschlagene Lösung mit einem Attribute ist nicht schlecht. Muss aber m.A. ein optionales Attribute bleiben, und muss nicht nur auf 127.0.0.1 beschränken können, sondern auf irgendwelche Adresse (da idealerweise der Proxy nicht auf dem gleichen Rechner wie alexa-fhem wäre).

In der TODO Datei in github steht sogar:

- proxy?

Was ist die Idee dahinter?

[justme1968]

im nächsten update gibt es eine bind-ip config option.  (fhemweb nimmt zumindest potentiell jede verbindung an. d.h. es kann sinnvoll sein diese auf ein bestimmtes netz zu beschränken. alexa-fhem nimmt im gegensatz dazu sowieso nur verbindungen an die ein gültiges event enthalten, die einen gültigen oauth token haben und die von einem konfigurierten skill kommen. weiterhin ist es nicht möglich über alexa-fhem von aussen beliebige fhem kommandos zu senden.)

verbindungen nur von einer bestimmten ip anzunehmen ist noch mal etwas anderes. das schaue ich mir mal an, im aws context ist das aber nur beschränkt sinnvoll da die ip dort nicht fest ist. da wäre etwas mit zertifikaten besser.

hinter der proxy id steckt das man die verbindung auch von innen nach aussen aufbauen könnte. dann gibt es kein problem mehr mit dem port forwarding und auch nicht mit dslite. es ist aber ein zusätzlicher externen dienst nötig. der vermutlich auch keine wirklich feste ip hat.

im übrigen bin ich der meinung das für die meisten anwender das ganze nicht sicherer wird wenn man mehr und mehr komponenten in die kette einbaut. das erhöht zum einen die ausfall gefahr und zum anderen auch die potentielle angriffs fläche. so lange man amazon vertraut (und das muss man für den smart home skill) und deren oauth token (und das tut man wenn man einen amazon account mit hinterlegten bank daten hat) und verbindungen nur mit gültigem oatuh token angenommen werden ist auch die konfiguration ohne proxy nicht unsicher. ein falsch konfigurierter von aussen erreichbarer apache oder sonstiger reverse proxy ist ein größeres risiko.