[ghome-fhem] HowTo: Google Home/Assistant Integration

[JF Mennedy]

Hi,
du musst ja im Reverse Proxy nicht auf FHEM verweisen, sondern auf GHome. In der Config von GHome gibst du ja den User für FHEM und den entsprechenden Port IN FHEM an. Das hat nix mit dem Reverse Proxy zu tun.
Unter welchem Port läuft denn dein GHome?
Imom sehe ich nur Anbindungen an FHEM bzw. entsprechende Zugriffe von außen auf deine FHEM-Installation per PW geschützt. Die Weiterleitung an GHome ist da ja noch gar nicht drin... oder?

Bis denn
SouzA

Ja richtig die Weiterleitung auf ghome habe ich wieder raus genommen weil das irgendwie meine komplette konfig gestört hat... ich hatte den Part wie du gestern beschrieben hast eingepflegt aber danach ging irgendwie gar nix mehr...

Gesendet von meinem SM-G935F mit Tapatalk

[SouzA]

Hi,
Jo kann ich verstehen... Dann wird ja auch prinzipiell erstmal alles, was über 443 rein kommt an den Port weiter geleitet.
Ich denke mal, weil das einer "nicht gewollten" config gleich kommt, weil da ja noch weitere Weiterleitungen vorhanden sind, geht erstmal gar nichts mehr.

Wenn du unbedingt die externe Anbindung von fhem brauchst, musst du wohl jede Location (/ghome /oauth /token.... Usw) einzeln als Location abbilden. So wie du es mit deiner FHEM-Installation gemacht hast. Für mich war das irgendwann zu aufwendig, auch aus dem Grund, weil Google irgendwann mal was geändert hatte und dann nichts mehr funktionierte. Deshalb habe ich die Anbindung an fhem per VPN und den Google-Kram per proxy.
Ich habe scon länger darüber mit kadettilac89 seniert. Das Thema ist nicht leicht.
Gib mir mal nen Moment.... Ich such mal nen Link zu der entsprechenden Unterhaltung.

Bis denn
SouzA

https://forum.fhem.de/index.php/topic,74371.msg844822.html#msg844822 und die nächsten Seiten... Davor ging es auch schon um proxy...

[SouzA]

Häh? Vielleicht habe ich mich unklar ausgedrückt:

In der Routine, um die Temperatur zu setzen, wird die Humidity abgefragt.
Und dann gibt es zwei Möglichkeiten:
a) Das Gerät unterstützt es, dann wird der Wert weggeworfen.
b) Das Gerät unterstützt es nicht, dann knallt eine Exception im Code, und die Temperatur wird nicht gesetzt.

Ich denke, da gibt es schon ein "Richtig" versus "Falsch".

Beim zweiten Mal lesen, fällt mir auch das ControlSet auf.
Ich denke, das hat wohl keinen Einfluss auf das humidity im Thermostat... 

Bis denn
SouzA

[kadettilac89]

Ich habe scon länger darüber mit kadettilac89 seniert. Das Thema ist nicht leicht.
Gib mir mal nen Moment.... Ich such mal nen Link zu der entsprechenden Unterhaltung.

Bis denn
SouzA

https://forum.fhem.de/index.php/topic,74371.msg844822.html#msg844822 und die nächsten Seiten... Davor ging es auch schon um proxy...

der Link ist veraltet.

https://forum.fhem.de/index.php/topic,74371.msg863997.html#msg863997

Mit der Änderung von pattex sollte das mit /ghome als einzige Location funktionieren. Muss aber in google actions entsprechend gepflegt sein.

[JF Mennedy]

Heureka Es Läuft... Vielmals vielmals lieben Dank an Deine Unterstützung SouZa... So auf dem Holzweg war ich anfangs gar nicht... Ich hatte in den Locations aber nur /ghome /oauth und /token angelegt... Ausserdem fehlte auf dem Raspberry auf dem das ghome-fehm Modul laufen soll bower... Jetzt geh ich mal ein bisschen meine Frau nerven, indem ich nur "OK Google..." sagend durchs Haus renne und mich freue (Sie ist eh schon genervt, weil ich 3 Abende nur am PC gehockt habe...)

DAAAAANKEEEEEE

Gruss Jan

[JF Mennedy]

Hier noch meine Konfiguration in Screenshots... Hoffe es hilft jemandem anderen weiter, wenn benötigt...

[SouzA]

der Link ist veraltet.

https://forum.fhem.de/index.php/topic,74371.msg863997.html#msg863997

Mit der Änderung von pattex sollte das mit /ghome als einzige Location funktionieren. Muss aber in google actions entsprechend gepflegt sein.

Wenn ich ganz ehrlich bin, habe ich noch nicht verstanden, wie das gehen soll...

Bis denn
SouzA

[kadettilac89]

ich habe mir die Codeänderung nicht angesehen, auch nicht getestet, aber ich verstehe es so ... ich spreche hier wieder nginx. Nur eine zusätzliche Location, nicht 3 oder so wie beim Workaround.

Code Auswählen Erweitern


location = /g_home {

       proxy_pass http://127.0.0.1:3005/;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_buffering off;
       proxy_ignore_client_abort off;
       break;
    }


in actions bei google musst du dann auch   https://<deine_domain>:<dein_port>/g_home    nutzen und auch bei **/g_home/token   **/g_home/oath ... location ist ein Name, ghome, g_home, ... muss nur gleich sein.

[gvzdus]

@SouzA und @Dominik:

Grmmpf. Einmal die Eselsmütze für mich bitte!
Meine ganzen Arbeiten habe ich auf dem GitHub-Checkout von yanniks statt Dominik gemacht. Vielleicht erklärt das, ich der Meinung war, man müsste erst mal etwas aufräumen, bevor man über einen Merge nachdenkt?

Mit der richtigen Variante, sprich, Dominiks Stand, klappt es bei mir auf Anhieb - auch mit den MAX-Thermostaten.

Wo bei meiner Code-Basis allenfalls Verbesserungen sein könnten:
- Ich glaube, ich habe den Fehler beim Anmelden über die Login-Seite gefunden: In authprovider.js würde ich vorschlagen:

Code Auswählen Erweitern


-        console.log('login successful ', req.body.username);
-        authCode = SmartHomeModel.generateAuthCode(req.body.username, client_id);
+        // GVZ: This is AFAIK broken! Shouldn't we take the user from the session??
+        console.log('login successful ', user.username);
+        authCode = SmartHomeModel.generateAuthCode(user.username, client_id);


- In server.js enthält das Fehlerhandling, insbesondere die "ERROR"-Direktiven noch Alexa-Legacy-Krams. Ich hatte z.B. getestet, die Fehlermeldung "valueOutOfRange" beim Thermostat sauber auszuliefern. Bringt aber aus Endkundensicht keine Verbesserung für den Kunden - ein entsprechendes Feedback gibt es zumindest in der GHome-App nicht.

[vbs]

Funktioniert das bei euch hinter einem ReverseProxy mit http BasicAuth? Ich hab das ghome-fhem hinter einen nginx-ReverseProxy gehängt und dafür ein http-Auth eingerichtet.

Ich hab dann an drei Stellen in der Google Action die URL entsprechend geändert:

Unter Build -> Action "https://<user>:<password>@<domain>"

Und unter Account Linking:

Code Auswählen Erweitern

https://<user>:<password>@<domain>/oauth
https://<user>:<password>@<domain>/token

Ich kann dann in der Google Home App die Action hinzufügen und dann erscheint die HTML-Anmeldeseite. Da muss ich mich dann zweimal anmelden, also einmal die HTTP-Auth und dann die normale User-Anmeldung. Wenn ich das gemacht habe, dann kommt kurz die Meldung "Wird mit <xxx> verknüpft", aber dann kommt "Die Einstellung konnte nicht aktualisiert werden. Prüfe deine Verbindung".

Ausgaben von ghome-fhem sehen für mich ok aus:

Code Auswählen Erweitern

GET /images/favicon.ico 304 1.354 ms - -
GET /images/manifest/icon-192x192.png 304 1.094 ms - -
GET /service-worker.js 200 2.209 ms - 678
/login  { redirect: '',
  client_id: '<myID>',
  redirect_uri: 'https%3A%2F%2Foauth-redirect.googleusercontent.com<...>',
  state: '<hash>',
  username: '<user>',
  password: '<pw>' }
getUser <user>
logging in  { password: '<pw>',
  authtoken: '<authtoken> }
login successful  <user>
authCode successful  <authCode>
POST /login 302 2.801 ms - 1552
GET /service-worker.js 200 1.648 ms - 678


Geht das generell nicht mit HTTP-Auth oder muss man noch mehr machen? Würde das ghome-fhem ungern direkt ins Netz hängen.

[kadettilac89]

Ghome hat oauth da ist kein http-auth vorgesehen. Hab eine eigene domaain dafür und reverse strenger abgesichert. Wenn du interessiwrt bist gebe ich dir später meine config und gedanken dazu

[habl]

Ghome hat oauth da ist kein http-auth vorgesehen. Hab eine eigene domaain dafür und reverse strenger abgesichert. Wenn du interessiwrt bist gebe ich dir später meine config und gedanken dazu

ich habe es auf einer eigenen Subdomain liegen, interessiere mich aber für das absichern. Also kannst Du gerne deine Gedanken dazu posten   

VG
  habl

[vbs]

Ist das sicher, dass sowas wie http-auth nicht gehen wird? Bei Alexa ist sowas möglich. Wo kommt denn da dann die Sicherheit her? Der ghome-fhem steht doch dann schutzlos frei im Internet und man ist darauf angewiesen, dass das Ding sicher ist und keine Security-Bugs enthält? Hab ich kein gutes Gefühl bei...
Evtl. verstehe ich dabei aber auch einfach etwas nicht. Wird ja hoffentlich seinen guten Grund haben, warum sowas nicht supportet ist seitens Google?
Eine Subdomain bringt aus meiner Sicht wenig bis keine zusätzliche Sicherheit.

[kadettilac89]

ich habe es auf einer eigenen Subdomain liegen, interessiere mich aber für das absichern. Also kannst Du gerne deine Gedanken dazu posten   

ich habe in nginx 3 server location über parameter "server_name" konfiguriert. Server_name wertet aus, über welche Url der Aufruf reinkommt.

1) server_name _  -> Default für alles ungleich der gewollten Domains, darunter fällt auch Aufruf über IP. Hier wird nur return 444 (close connection) ausgeführt. Das sperrt schon mal alle aus, die über IP an meinen Nginx wollen

2) server_name <fhem_domain> -> hier ist nur location /fhem (o. ä.) offen (und über client certificate gesichert). / (root) und alles andere wird mit return 444 - close connection - abgewiesen

3) server_name <ghome_domain> -> hier ist nur location / offen. Alles andere wird mit return 444 geblockt. Hier habe ich eine Domain aus Zahlen und Buchstaben (wildes Durcheinander). Unwahrscheinlich dass das jemand durch Zufall eingibt

Selbst <ghome_domain>/fhem wird geblockt, da die Kombi nicht konfiguriert ist.

Ich müsste nachsehen, Fail2Ban müsste auch blocken wenn jemand z. B. <ghome_domain>/logi mehrfach aufruft da hier ein "cannot get /logi" von nodejs zurückgeliefert wird.

Ist das sicher, dass sowas wie http-auth nicht gehen wird? Bei Alexa ist sowas möglich. Wo kommt denn da dann die Sicherheit her? Der ghome-fhem steht doch dann schutzlos frei im Internet und man ist darauf angewiesen, dass das Ding sicher ist und keine Security-Bugs enthält? Hab ich kein gutes Gefühl bei...
Evtl. verstehe ich dabei aber auch einfach etwas nicht. Wird ja hoffentlich seinen guten Grund haben, warum sowas nicht supportet ist seitens Google?
Eine Subdomain bringt aus meiner Sicht wenig bis keine zusätzliche Sicherheit.

Gebe ich dir Recht, würde auch gerne zusätzlich Client-Certificate einsetzen, oder alternativ User/PW.

Habe keine Möglichkeit gesehen, das in Google actions einzutragen.

[X-Byte]

Erstmal vielen Dank an Dominik, dass Du Dir hier so viel Mühe mit ghome-fhem gegeben hast und vor allem auch noch so gut dokumentiert hast, dass man ohne tausend nachfragen zum Ziel kommt.

Ein Problem habe ich allerdings: Bei mir wird der Standard https Port 443 bereits an einen anderen Server und Dienst im Heimnetz umgeleitet, den ich auch nicht ändern kann, da die Apps, die mit diesem kommunizieren fest auf 443 verdrahtet sind.

Ich habe im Verlauf der Installation von ghome-fhem im Google Action Projekt bei "Authorization URL" und "Token URL" entsprechend meinen abweichenden Port 444 integriert, ebenso in der Action bei "Add fulfillment URL".
Die in ".ghome/action.json" gesetzte "url", welche lediglich den Domainnamen enthielt, musste ich durch eine vollständige Verbindungsangabe ersetzen ( "https://mydomain.ddnss.de:444" ), sonst ist die gactions Ausführung immer auf die Nase gefallen.
Als das alles erfolgreich gemeistert war, bin ich dann aber beim Einrichten der Google Home App endgültig gescheitert, bei dem Punkt den "[test] Connector" hinzuzufügen. Bei Auswahl desselben sieht man kurz ein "assistant.google.com" in der URL, welches dann weiterleitet zu "https://mydomain.ddnss.de", eben leider mit fehlendem :444 und somit beim falschen Dienst ankommt und nicht das Loginfenster von ghome-fhem bringt.

Frage: Ist das ein Problem, das bei Google liegt oder im Umfeld von ghome-fhem zu lösen ist? Wird bei der Kommunikation mit Google evtl. irgendwo mal der Port unterschlagen?