Alexa Skill für FHEMWEB im Internet

[Wolfspirit]

Hallo,

Ich bin mir nicht sicher ob das Forum hier nur für fertige Implementierungen ist, aber ich versuchs mal hier:

Mich würde mal interessieren wie viele ihr FHEMWEB über das Internet erreichbar haben und einen Skill bevorzugen würden der ausschließlich als lambda läuft und daher keine lokale Installation benötigt.

Nachdem meine Anfrage ob man vielleicht bei der Entwicklung über Pull Requests bei "alexa-fhem" mithelfen kann (Seite 90) wohl unter gegangen ist hab ich mich mal ran gesetzt.

Ich habe mir jetzt gestern mal testweise selbst einen Skill gebaut der ganz ohne lokalen Server auskommt und direkt aus der AWS Lambda Funktion FHEMWEB anspricht was bei mir hinter einem Reverse Proxy mit https liegt. Momentan hab ich das hauptsächlich für Schaltaktionen an/aus, färben und sättigen von HUE Devices in alle möglichen Farben ("Alexa, sage fhem Go in Wohnzimmer auf hellrot zu stellen"). Außerdem die Ansage von Räumen ("Alexa, frage fhem welche räume es gibt") sowie ("Alexa, frage fhem nach dem Status von Go im Wohnzimmer").

Zum Vergleich:

alexa-fhem:
Echo -> AVS -> AWS Lambda -> alexa-fhem -> FHEM (ggf. gecached von alexa-fhem) -> alexa-fhem -> AWS Lambda -> AVS -> Echo

Meine Lösung:
Echo -> AVS -> AWS Lambda -> FHEM -> AWS Lambda -> AVS -> Echo

Es wird hier auch keine dauerhafte Verbindung ("longpoll") zu FHEM aufgebaut sondern die nötigen Dinge direkt bei FHEM angefragt.
Momentan noch mit zwei Requests aber ich überlege das über eine/mehrere perl Funktion auf FHEM seite auf einen Request zu beschränken.

Es arbeitet mit den alexaName und alexaRoom attributen zusammen und das setzen von intents im Alexa device hab ich zwar noch nicht drin, wäre aber auch kein Problem.

Momentan nur als Custom Skill, aber den Smart Home Skill möchte ich ebenfalls implementieren so das beides genutzt werden kann.

Es geht auch nicht darum eine "Konkurrenz" für alexa-fhem zu sein sondern eine alternative

Mich würde jetzt erstmal interessieren ob daran überhaupt Interesse besteht,
da ich überhaupt keine Ahnung habe ob und wie viele FHEM (natürlich Passwort geschützt) im Internet hängen haben.

EDIT: Nur zum Verständnis: Die Einrichtung einer Lambda AWS Umgebung ist trotzdem nötig! Ein Custom Skill kann nur als AWS Lambda Funktion laufen oder einen HTTPS Server ansprechen der sowohl ein gültiges Zertifikat hat als auch auf Port 443 läuft, was für mich persönlich zu restriktiv ist.

[justme1968]

natürlich darf man alexa-fhem mitarbeiten.

wenn ich endlich dazu gekommen bin alexa-fhem und homebridge-fhem wieder zusammen zu mergen auch gerne per github.

ich sehe keinen vorteil den kompletten code in aws lambda laufen zu lassen. ganz im gegenteil. abgesehen davon das man fhem selber von außen zugreifbar machen muss fällt vor allem das cachen und auch das vorbereiten von raum oder sonstigen listen weg bzw. wird deutlich aufwändiger da der aws code nicht ständig läuft. das behindert auch das auswerten von homebridgeMapping um z.b. nach device typ mehrte devices auf ein mal zu schalten.

es wäre auch schade wenn der aufwand in zwei skills gesteckt wird statt besser einem einzigen weiter auszubauen.

das aktualisieren des lambda code ist auch deutlich aufwändiger. ein einfaches npm install ist nicht möglich, ipv6 ist aktuell nicht möglich, ...

alles in allem fände ich es sinnvoller die energie in den bestehenden skill zu stecken.

gruss
  andre

[Wolfspirit]

Hi,

Danke für deine Antwort hier

ich sehe keinen vorteil den kompletten code in aws lambda laufen zu lassen. ganz im gegenteil. abgesehen davon das man fhem selber von außen zugreifbar machen muss

Der Poll zeigt (auch wenn noch nicht viele abgestimmt haben), dass sogar mehr Leute als ich erwartet habe FHEMWEB im Internet haben. Wenn ich FHEMWEB sowieso im Internet habe macht es wenig sinn noch einen Port zu öffnen nur um Hintenrum wieder auf FHEMWEB zuzugreifen.

fällt vor allem das cachen und auch das vorbereiten von raum oder sonstigen listen weg bzw. wird deutlich aufwändiger da der aws code nicht ständig läuft. das behindert auch das auswerten von homebridgeMapping um z.b. nach device typ mehrte devices auf ein mal zu schalten.

Das ist richtig, die Lambda funktion läuft pro request, aber 90% der anfragen müssen dann eben doch einen Request an FHEM stellen (set,...) was die Antwortzeit durch die extra Route nur verlängert. Ich brauch kein Caching um ein Device zu setzen und zum auslesen reicht es doch wenn mir ein jsonlist2 mit filter direkt von FHEMWEB aktuelle Daten liefert und ein JSON.parse macht hier maximal Millisekunden aus. Das einzige Problem welches ich hatte waren, dass die Filter nicht case insensitive sind und ich daher das erkannte mappen musste (zumindest hab ich keine möglichkeit für case insensitive filter gefunden). Im Moment mache ich daher sogar 2 Requests (einen um die Raum und Deviceliste zu generieren um die Eingabe zu mappen und einen um den Befehl abzusetzen) und gefühlt ist die Reaktionszeit schneller als vorher über alexa-fhem.
Auf jedenfall nicht langsamer!
Meine Idee war eine Custom Perl funktion zu machen welche erkannten raum und erkanntes Device + Befehl übergeben werden und dann FHEM damit anspricht:
FhemAlexaRequest("licht","gang","set {device} on")

Das mapping würde hier dann FHEM selbst übernehmen mit aktuellen Daten und ich würde nur einen Request an FHEM brauchen ohne vorher irgendwelche Listen abfragen zu müssen. Ich selbst nutze homebridgeMapping nicht, aber diese art von Auswertungen würde vermutlich auf FHEM Perl Seite auch möglich sein, wenn nicht sogar besser als über ein caching in einem extra Service!

Oder man schickt gleich das Event direkt an FHEM und FHEM kümmert sich darum die Slots auszuwerten.
Vielleicht gleich das Alexa Device wo es hingehört?
Somit hätte man das ganze sogar in FHEM integriert und das alexa device wäre nicht nur ein Platzhalter.

es wäre auch schade wenn der aufwand in zwei skills gesteckt wird statt besser einem einzigen weiter auszubauen.
alles in allem fände ich es sinnvoller die energie in den bestehenden skill zu stecken.

Das sehe ich genauso, die Frage ist nur ob es hier nicht zwei verschiedene Interessen gibt.

das aktualisieren des lambda code ist auch deutlich aufwändiger. ein einfaches npm install ist nicht möglich, ipv6 ist aktuell nicht möglich, ...

Kein User editiert den Lambda code manuell. Die Eingabe der URL und Username, Passwort habe ich bereits (momentan als base64) in den Environment Variablen von Lambda konfigurierbar gemacht wo es hin gehört. Das heißt für den User wäre das lediglich das anlegen des Skills, eintragen der Environment Variable FHEM_URL und bei lambda das Hochladen einer zip Datei.

Alexa-fhem funktionierte bei mir im Moment so gut wie gar nicht.
Alexa meinte manchmal "Ich habe Ich kann Device undefined nicht einschalten eingeschaltet" oder ähnliches.
Keine Ahnung wie das passiert.

[marvin78]

Der Poll zeigt (auch wenn noch nicht viele abgestimmt haben), dass sogar mehr Leute als ich erwartet habe FHEMWEB im Internet haben. Wenn ich FHEMWEB sowieso im Internet habe macht es wenig sinn noch einen Port zu öffnen nur um Hintenrum wieder auf FHEMWEB zuzugreifen.

Nein. Das zeigt er nur dann, wenn du erwartet hast, dass niemand FHEMWEB über das Internet nutzt. Die Frage ist ohnehin unpräzise gestellt.

[justme1968]

Wenn ich FHEMWEB sowieso im Internet habe macht es wenig sinn noch einen Port zu öffnen nur um Hintenrum wieder auf FHEMWEB zuzugreifen.

mal unabhängig davon das ich es für eine dumme idee halte fhem selber direkt erreichbar zu haben wird das durch die tatsache das ich die zugangsdaten auch noch hinterlege nicht besser.

der eine port für alexa-fhem lässt sich meiner meinung nach besser absichern und es lässt sich auch nicht fhem komplett steuern.

aber das ist geschmacksache. im prinzip kann man den kompletten alexa-fhem code statt lokal auch bei aws laufen lassen.

also eigentlich keinen vorteil für einen zweiten skill.

Auf jedenfall nicht langsamer!

das bezweifle ich vor allem für dinge wie 'mach den rolladen im schlafzimmer hoch' oder 'macht das licht an im wohnzimmer an'. hier ist wird ja kein device namen angegeben sondern ein device typ. im besten fall muss man alle devices des raumes abfragen. und dann noch weiter filtern. das ist potentiell sehr langsam.
es sollte also besser heissen 'es ist nicht schneller, aber vielleicht deutlich langsamer. -> d.h. kein vorteil.

das alexa device ist nicht nur platzhalter.

das auslagern in einen zweiten prozess der alles cached ist meiner meinung nach ein vorteil. es verhindert potentiell das blockieren von fhem und erlaubt recht einfach den zugriff auf mehr als eine fhem instanz. ob man alexa-fhem in node oder perl implementiert nimmt sich nichts.

für alle die alexa und homekit verwenden hat es ausserdem den vorteil das sie (bald) nur einen dienst laufen lassen müssen.

Kein User editiert den Lambda code manuell.

es geht mir nicht um das manuelle editieren sondern um das einspielen von updates. ein npm update das demnächst möglich ist ist einfacher als den code neu zu aws lambda hoch zu laden.

Alexa-fhem funktionierte bei mir im Moment so gut wie gar nicht.

da wüsste ich gerne was genau wann schief geht.

[Wolfspirit]

mal unabhängig davon das ich es für eine dumme idee halte fhem selber direkt erreichbar zu haben wird das durch die tatsache das ich die zugangsdaten auch noch hinterlege nicht besser.

Richtig. Ich selbst hab FHEM auch über einen NGINX mit Passwort direkt erreichbar. Alles ohne Passwort bekommt FHEM daher garnicht zu sehen. Daher ist im Moment meine Überlegung einen Webserver ähnlich FHEMWEB speziell für diese art von Anfragen als FHEM Plugin zu erstellen. Eine erste Implementierung hab ich hier auch schon.

das bezweifle ich vor allem für dinge wie 'mach den rolladen im schlafzimmer hoch' oder 'macht das licht an im wohnzimmer an'. hier ist wird ja kein device namen angegeben sondern ein device typ. im besten fall muss man alle devices des raumes abfragen. und dann noch weiter filtern. das ist potentiell sehr langsam.

es sollte also besser heissen 'es ist nicht schneller, aber vielleicht deutlich langsamer. -> d.h. kein vorteil.

Das kommt darauf an. Selbst set beherrscht ja die Möglichkeit über Filter mehrere Devices anzusprechen. Vorallem ein eigenes FHEM Plugin wird das Ergebnis schneller haben als ein externes Script. Wenn ich also dem Plugin ein JSON mit den Alexa Slots und dem Intent zusende bekomme ich die Antwort definitiv schneller da überhaupt kein weiterer Request ausgeführt werden muss. Weder fürs auslesen noch fürs setzen. Authentifizierung dann über extra Token.

das alexa device ist nicht nur platzhalter.

Für die Verarbeitung selbst ist es das. Außer das es Attribute liefert und einen readingswert für das fhemIntent macht es nichts. Es könnte aber noch viel mehr.

das auslagern in einen zweiten prozess der alles cached ist meiner meinung nach ein vorteil. es verhindert potentiell das blockieren von fhem und erlaubt recht einfach den zugriff auf mehr als eine fhem instanz. ob man alexa-fhem in node oder perl implementiert nimmt sich nichts.

Das "blocken" von FHEM sehe ich bei einzelnen Alexa anfragen überhaupt nicht als Problem.
Ständig eine Verbindung zum FHEMWEB aufzumachen sehe ich eher problematisch wenn das in diesem Fall gar nicht nötig ist.

für alle die alexa und homekit verwenden hat es ausserdem den vorteil das sie (bald) nur einen dienst laufen lassen müssen.

Wo ist da der Vorteil gegenüber meiner Lösung? Sie müssten hier auch nur einen Dienst laufen lassen. Oder wenn sie Homekit nicht verwenden gar keinen. Vielleicht sollte man mal darüber nachdenken die beiden Dienste getrennt zu sehen, da nicht jeder der Alexa nutzt auch gleich Homekit nutzt.

es geht mir nicht um das manuelle editieren sondern um das einspielen von updates. ein npm update das demnächst möglich ist ist einfacher als den code neu zu aws lambda hoch zu laden.

Ein "update" bei FHEM ist noch einfacher. Der Lambda code wäre ebenfalls nur als "Relay" zu sehen. Bei meiner ersten Idee eben direkt über Custom Perl functions die z.B. die Alexa slots und das jeweilige intent annehmen, jetzt direkt als extra FHEM Plugin mit eigenem Webserver.

Gruß,
Adrian

[justme1968]

das alexa device macht auch jetzt schon mehr.

die filter im set nützen dir nichts wenn du device typen ansprechen willst. z.b. alle rollläden in einem zimmer. und diese dann auch noch von unterschiedlichen herstellern sind und über unterschiedliche module laufen und unterschiedliche set kommandos mit unterschiedlichen parametern erwarten.

man kann damit z.b. feststellen ob ein kommando über alexa gekommen ist oder nicht. noch nicht elegant, aber das kommt noch. das alexa device wird auch einfluss auf die antworten haben.


alexa und siri nicht zu trennen halte ich für sinnvoll. zum einen weil beides die sprachsteuerung betrifft und weil tatsächlich einige anwender beides im einsatz haben. d.h. es ist von vorteil wenn sich beides gleich verhält und auch gleich konfiguriert wird.

auch liefert der homekit teil genau die dinge die alexa aktuell komplett fehlen. wie konzepte zu geräte typen, wertebereichen, die abstraktion vom eigentlichen device hin zu service klassen und eigenschaften. das kann man natürlich alles noch mal selber bauen. aber dann läuft man genau in das problem das auch das verhalten (minimal) unterschiedlich sein wird. ebenso die konfiguration.

es ist eher sinnvoll die sprachsteuerung von fhem so weit wie möglich zu vereinheitlichen statt für jede komponente etwas eigenes zu bauen. oder sogar mehre varianten zu haben.

ich sehe absolut keinen vorteil darin mehr code bei aws laufen zu lassen.

aber ganz unabhängig davon wo der code läuft finde ich es schade wenn der aufwand in eine parallele entwicklung gesteckt wird statt eine einzige codebasis zu erweitern und zu verbessern. erst recht weil ich denke das mit der bereits vorhanden prinzipiell lösung alles möglich ist.

aber wenn du spass daran hast etwas eigenes zu bauen: nur zu. darum geht es ja eigentlich

gruss
  andre