Google Home ab 8 August in Deutschland

[SouzA]

Da Login, oauth, token .. separat sind, könnte es funktionieren wenn du zum einmaligen Registrieren den Port 443 oder welchen du nach außen offen hast, direkt auf dein Ghome forwardest und reverse Proxy (apache) deaktivierst.

Ich hab den Proxy zwar nicht deaktiviert, habe aber im Router direkt auf meinen ghome-Port verwiesen.
Funktioniert auch soweit, nachdem key und cert wieder in der config.json angegeben sind.
Allerdings fehlen auf der Login-Seite wieder diese verk****en bower und image-files.
Im reverse-proxy hab ich es vielleicht noch verstanden, warum das net angezeigt wird. Hier hört es jetzt mal wieder auf.
Warum müssen die was an den URLs ändern? Bzw. warum kann man jetzt nicht mehr /ghome in actions mitgeben?

Grüße vom frustrierten
SouzA

[kadettilac89]

ich vermute, du willst sagen, dass du auch kein User / Passwort Felder hast?

Um ohne Bower-Komponenten die Felder zu bekommen lösche diese Zeilen in ghome-fhem/frontend/login.html

Code Auswählen Erweitern


            <input type="hidden" name="username" />
            <input type="hidden" name="password" />


Und füge diese ein ( ... naja, nicht unbedingt nötig, nur Kommentar)

Code Auswählen Erweitern


            <!-- <input type="text" name="username">
            <input type="password" name="password" /> -->


[SouzA]

ich vermute, du willst sagen, dass du auch kein User / Passwort Felder hast?

Um ohne Bower-Komponenten die Felder zu bekommen lösche diese Zeilen in ghome-fhem/frontend/login.html

Code Auswählen Erweitern


            <input type="hidden" name="username" />
            <input type="hidden" name="password" />


Und füge diese ein ( ... naja, nicht unbedingt nötig, nur Kommentar)

Code Auswählen Erweitern


            <!-- <input type="text" name="username">
            <input type="password" name="password" /> -->


Funktioniert... die Webseite wird nun komplett in der App angezeigt. Allerdings funktioniert der "Login"-Button nicht mehr. Keine Reaktion bei Betätigung.
Schritt für Schritt und langsam ernährt sich... 

Denkfehler!! Man lösche den Browsercache! Dann funzt das auch mit den bower und images. OHNE das ändern in der html. Synchronisierung funktioniert. Geräte sind wieder da 

Was definitiv nicht mehr funktioniert: reverse proxy. Sobald man den wieder davor schaltet funktioniert nichts mehr. Mit der alten Konfig sowie mit deiner beiden locations /ghome und /ghome/

Bis denn
SouzA

[kadettilac89]

Was definitiv nicht mehr funktioniert: reverse proxy. Sobald man den wieder davor schaltet funktioniert nichts mehr. Mit der alten Konfig sowie mit deiner beiden locations /ghome und /ghome/

I am sick and tired .... Reverse Proxy über Location abzubilden. Ich nutze in Nginx nun einen eigenen Server-Block. Dazu habe ich mir bei spdns eine eingene Subdomain angelegt und Letsencrypt Certificates. Läuft jetzt bei mir, ist wahrscheinlich auch Zukunfssicher da es egal ist, wie die Urls aussehen. Domain in Google-Actions ist nun so ähnlich ... https://nvsxtvq6.spdns.de:2480 (nur um beim Beispiel unten zu bleiben).

Logik in nginx durch Parameter "server_name" wird der Block nur ausgeführt, wenn genau diese Url aufgerufen wurde. Wird die erste Url (die für FHEM) aufgerufen greift bei mir ein eigener Server-Block. Wird die externe IP aufgerufen findet nginx bei mir keinen Block und ein Fehler erscheint.

FHEM-Block ist per Client Certificate gesichert. Damit Ghome auch etwas abgesichert ist, habe ich eine nichtssagende Subdomain (willkürlich Zahlen und Buchstaben) genutzt. Nur wenn jemand genau diese Url hat könnte er überhaupt am node.js-Webserver rumhacken ... Alles andere wird ja verworfen.

Für Nginx die Konfiguration angehängt. Für Apache musst halt schaun ob es die Funktion auch in Apache gibt.

Code Auswählen Erweitern


server {

    listen 443;
    server_name nvsxtvq6.spdns.*;

    ssl_certificate /etc/letsencrypt/live/nvsxtvq6.spdns.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/nvsxtvq6.spdns.de/privkey.pem;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    error_page 497 @drop;
    location @drop { return 0; }

    location / {

       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;
    }

}


[SouzA]

Damit Ghome auch etwas abgesichert ist, habe ich eine nichtssagende Subdomain (willkürlich Zahlen und Buchstaben) genutzt. Nur wenn jemand genau diese Url hat könnte er überhaupt am node.js-Webserver rumhacken ... Alles andere wird ja verworfen.

Wenn du Zertifikate von letsencrypt nutzt steht die Adresse im Netz...
https://community.letsencrypt.org/t/does-lets-encrypt-have-a-public-ssl-directory/18985

Habe ich es richtig verstanden, dass der nginx alle Anfragen ausm Netz an Port 443 jetzt an dein Port 3005 weiterleitet?
Das kannste mit dem Router doch schon machen? Oder falsch verstanden?

Bis denn
SouzA

[kadettilac89]

Wenn du Zertifikate von letsencrypt nutzt steht die Adresse im Netz...
https://community.letsencrypt.org/t/does-lets-encrypt-have-a-public-ssl-directory/18985

Habe ich es richtig verstanden, dass der nginx alle Anfragen ausm Netz an Port 443 jetzt an dein Port 3005 weiterleitet?
Das kannste mit dem Router doch schon machen? Oder falsch verstanden?

Dass letsencrypt Informationen published und auch über Google Suche was zu finden ist, weiß ich, ich meinte mehr die Script Kiddies und Portscans.

Mein Router lauscht auf einen untypischen Port, ungleich 443. 443 will ich nicht öffnen.

Port public (z. B. 2840) -> Router Portforwarding 2840:443 -> Raspberry Nginx 443 -> Reverse Proxy -> 3005 Ghome

Der R-Proxy unterscheidet aber woher die Anfrage kommt. Nur Anfragen mit bestimmtem Muster werden weitergeleitet.

Wenn im Browser
1) fhem.spdns.de:2840/fhem* aufgerufen wird --> Anfragen gehen an 127.0.0.1:8083 (Fhem Web)
2) nvsxtvq6.spdns.de:2840/* aufgerufen wird --> Anfragen gehen an 127.0.0.1:3005 (Ghome-Bin)
3) öffentliche_IP:2840/ --> Verworfen da kein Server-Block

Interne IP-Aufrufe laufen nicht über den R-Proxy, müsste wenn gewünscht, dann über einen eigenen Block und IP-Ranges o. ä. abgebildet werden. Alternativ über einen "Else"-Zweig mit "Server_Name _" (bin mir mit der Syntax nicht ganz sicher).

Nginx weiß über welche öffentliche Url / Domain die Anfrage reinkommt und entscheidet anhand der Server-Blocks.

[SouzA]

Ich habe mal ein paar Neuerung im development Branch eingebaut...wer Lust hat, kann gerne schon mal testen.
git checkout development (direkt in ghome-fhem)

Changelog
- Xiaomi Vacuum wird unterstützt (dock, pause, locate, mode[leider nur englisch])
- Neu hinzugefügte Geräte können direkt über "OK Google, synchronisiere meine Geräte" neu hinzugefügt werden. Kein Restart oder ähnliches notwendig.
- Automatische Erkennung des richtigen Raums wenn mehrere Räume einem Device zugewiesen sind (z.B. Raum=GoogleHome,Wohnzimmer => Wohnzimmer wird automatisch in Google Home App angezeigt)
- realRoom wird als neues userattr angelegt um den richtigen Raum gleich in Google Home anzugeben - erspart jede Menge Arbeit, für Geräte wo die automatische Erkennung funktioniert, kann man sich das sparen
- Thermostate unterstützen nun aus- und einschalten (aus => minValue, ein => im Moment 21Grad, soll zukünftig den letzten Modus wiederherstellen)
- Fix Login bei der Einrichtung in manchen Situation
- Geräte mit volume haben nun immer die Möglichkeit über ("Stelle Wohnzimmer Radio auf 20%") die Lautstärke zu ändern

Bitte gebt Bescheid wenn was nicht funktioniert.

Hi,
nachdem mein Proxy ja nun nicht mehr funktioniert und das ghome erstmal so wieder läuft, habe ich mal getestet.

Die automatische Erkennung funktioniert ohne Neustart.
RealRoom funktioniert auch. (Klasse!)

Zu den Thermostaten kann ich sagen, dass Aus und Ein (21°C) generell funktioniert. Allerdings wird es in der App erst bei der zweiten Abfrage angezeigt.
Bedeutet, dass nach dem betätigen von "Aus" in der App das Thermostat aktualisiert wird, in der App danach aber noch "Heizen" angehakt ist und die letzte Solltemp angezeigt wird. Das Thermostat (das echte) ist dann aber schon Aus (5°C). Bei zweiten betätigen von "Aus" in der App, wird danach Aus und 5°C angezeigt.

Die anderen Sachen kann ich nicht testen.

Frage:
Kann man sowas wie RealRoom auch für die Namen (RealName) einführen?
EDIT II: Alias wird ja übernommen, womit man leben könnte. Allerdings werden hier leider nur Kleinbuchstaben verwendet bzw. in der App angezeigt...

Thx & bis denn
SouzA

EDIT:
Wenn man in FHEM Devices aus dem GoogleHome-Raum löscht, wird dies nicht erkannt. Erst nach restart des ghome.

EDIT III:
Proxy funzt wieder... Warum auch immer. Es funktioniert allerdings nicht mehr mit den Locations. Für den ghome-Zugriff muss wohl jetzt mehr geöffnet werden außer /oauth /token und /login. (Alle drei Seiten waren über den proxy erreichbar. Verknüpfen konnte der Assistant dennoch nicht!)
Entsprechend kommt nun zunächst folgendes zum Einsatz:

Code Auswählen Erweitern


ProxyErrorOverride On
ProxyPass / http://localhost:3010/
ProxyPassReverse / http://localhost:3010/

@kadettilac89
Wenn ich nun einen Aufruf von /ghome weiterleiten will, muss ich dann die gesamte Installation von ghome in dem Ordner /home/pi/ghome stattfinden lassen? Also in /home/pi/ghome/.ghome und in /home/pi/ghome/ghome-fhem? Oder ist das irgendwo einen Angabe? Ich frage dies, weil die Änderung in der action.json und eine entsprechende Anpassung in den Google Actions kein zufriedenstellendes Ergebnis gebracht haben.

[kadettilac89]

Wenn ich nun einen Aufruf von /ghome weiterleiten will, muss ich dann die gesamte Installation von ghome in dem Ordner /home/pi/ghome stattfinden lassen? Also in /home/pi/ghome/.ghome und in /home/pi/ghome/ghome-fhem? Oder ist das irgendwo einen Angabe? Ich frage dies, weil die Änderung in der action.json und eine entsprechende Anpassung in den Google Actions kein zufriedenstellendes Ergebnis gebracht haben.

Ein Tipp komplett off topic ... Die Frage ist komplett untergegangen da durch einen Edit kein notify ausgeführt wird, am besten ein zusätzlicher Post wenn hier zusätzliche Fragen sind Habe es jetzt gesehen, da ich eine andere Frage posten wollte (gleich machen werde) ...

Zu deiner Frage: Wo letztendlich die Files liegen ist dem Reverse Proxy völlig egal. Der Reverse Proxy arbeitet mit dem Webserver bzw. dessen Root- oder Webverzeichnis. Meist bildet der Webserver ein Verzeichnis im www-Verzeichnis ab, das muss aber nicht so sein. Ghome nutzt einen node.js Webserver. Du siehst ja an den Freigaben /oauth, /token, /login  dass hier keine Verzeichnisstruktur vorhanden ist (es gibt als Beispiel keinen Ordner login).

Bei mir kommt es nicht in Frage, das Root-Verzeichnis einzig und alleine für Ghome freizugeben. Wenn das bei dir möglich ist, könntest du genau das machen was ich vor ein paar Posts schon gepostet habe. Unten in Nginx-Syntax. Du musst halt aufpassen, dass du im Root-Verzeichnis oder darunter keine sicherheitskritische Einstellungen oder Seiten hast. Außerdem geht dann auch der Aufruf **/fhem zum Ghome-node.js und nicht zu Fhem außer du konfigurierst das zusätzlich  ... du musst wissen, was gewollt ist. Will nur sagen, pass auf dass du dein System auch abgesichert ist.

Nochmal OT ... gibt es einen Grund der für Apache Reverse Proxy spricht? Apache macht sicher seinen Job genau so gut wie ein Nginx, aber in Apache will ich micht nicht einarbeiten, wenn du Nginx im Einsatz hättest, könntest du meine Config fast 1:1 übernehmen ... Am besten SD-Karte kopieren und auf der Kopie arbeiten. Wenns funktioniert darauf bleiben, wenn nicht, Karte wieder zurücktauschen und nichts verloren.

Die Config meine ich ...

Code Auswählen Erweitern


server {

    listen 443;
    server_name nvsxtvq6.spdns.*;   <--- das würde bei dir fehlen

    ssl_certificate /etc/letsencrypt/live/nvsxtvq6.spdns.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/nvsxtvq6.spdns.de/privkey.pem;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    access_log            /var/log/nginx/jenkins.access.log;

    error_page 497 @drop;
    location @drop { return 0; }

    location / {

       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;
    }

}


[kadettilac89]

Frage an Dominik,

ist es gewolltes Verhalten, dass die Werte im Cache unverändert bleiben wenn ich im Fhem etwas ändere?

Thermostat Wohnzimmer hat beim Start von Ghohme eine Solltemperatur von 11 Grad (desired-temp). Wenn ich nun in Fhem die Temperatur auf 18 Grad ändere wird trotzdem in Ghome 11 Grad angezeigt. Sowohl im neune Widget in GHome-App als auch in der Sprachausgabe. Wenn ich Ghome restarte wird die neue Temperatur - 18 Grad - angezeigt.

Ist es möglich per notify aus Fhem die Werte neu lesen zu lassen? Möchte ungern jedes mal ghome selbst restarten, auch wenn ich das in Fhem einbauen könnte.

[SouzA]

Hi,
Danke für deine Ausführungen. Ich komme darauf nochmal zurück.

Allerdings muss ich gerade darauf hinweisen, dass Google nach einer mir noch unbekannten Zeit die Verbindung zum ghome verliert. Die login, oauth und token sind erreichbar.
Da hilft auch kein restart vom ghome und oder apache.
Nur die neuverbindung in der app hilft.
Benutze die developer version.

Meld mich heute Abend noch mal.
Bis denn
SouzA

[kadettilac89]

Allerdings muss ich gerade darauf hinweisen, dass Google nach einer mir noch unbekannten Zeit die Verbindung zum ghome verliert. Die login, oauth und token sind erreichbar.
Da hilft auch kein restart vom ghome und oder apache.
Nur die neuverbindung in der app hilft.

Hast du im Apache R-Proxy ein Access-Log? Siehst du ob von Google überhaupt eine Anfrage kommt? Und wenn auf welche Url. Wäre für die Ursachenforschung hilfreich.

Hast du auf deinem Raspi eine Firewall laufen? Hast du da ggf. was im Log?

An sich habe ich das (willkürlicher Abbruch) aber bei mir noch nicht festgestellt. Kannst ja mal zum Test den public-Build nutzen ...

[dominik]

Frage an Dominik,

ist es gewolltes Verhalten, dass die Werte im Cache unverändert bleiben wenn ich im Fhem etwas ändere?

Thermostat Wohnzimmer hat beim Start von Ghohme eine Solltemperatur von 11 Grad (desired-temp). Wenn ich nun in Fhem die Temperatur auf 18 Grad ändere wird trotzdem in Ghome 11 Grad angezeigt. Sowohl im neune Widget in GHome-App als auch in der Sprachausgabe. Wenn ich Ghome restarte wird die neue Temperatur - 18 Grad - angezeigt.

Ist es möglich per notify aus Fhem die Werte neu lesen zu lassen? Möchte ungern jedes mal ghome selbst restarten, auch wenn ich das in Fhem einbauen könnte.

Nein, das sollte definitiv nicht so sein. Kannst du mir die Details zu diesem Device posten oder das homebridgeMapping welches du verwendest? Funktioniert der Cache bei anderen Readings?


Das Problem, dass die Verbindung verloren geht, kann ich auch nicht bestätigen. Ich habe meine Connection (developer Branch) vor ca. 2 Wochen eingerichtet und läuft noch immer. Hat sich vielleicht deine IP Adresse geändert und du musst nur den DNS Eintrag aktualisieren?

[SouzA]

Hast du im Apache R-Proxy ein Access-Log? Siehst du ob von Google überhaupt eine Anfrage kommt? Und wenn auf welche Url. Wäre für die Ursachenforschung hilfreich.

Hast du auf deinem Raspi eine Firewall laufen? Hast du da ggf. was im Log?

An sich habe ich das (willkürlicher Abbruch) aber bei mir noch nicht festgestellt. Kannst ja mal zum Test den public-Build nutzen ...

Hi,
Access-Log ja. Firewall noch nicht. Den genauen Zeitpunkt kann ich gerade nicht einordnen. Das nächste mal schaue ich direkt.
Ist bei dir im access auch jede Stunde ein Zugriff von Google drin?

Ich nutze jetzt weiter noch den developer-build um beim nächsten Abriss mal die Anfrage von der App zu checken.
bis denn
SouzA

[kadettilac89]

Nein, das sollte definitiv nicht so sein. Kannst du mir die Details zu diesem Device posten oder das homebridgeMapping welches du verwendest? Funktioniert der Cache bei anderen Readings?

ich weiß woran es liegt, ich habe per event-on-change-reading reduziert und desired-temp/measured-temp war nicht drin. Die Readings-Events werden vermutlich benutzt um ein Update zu triggern. Jetzt funktioniert es.

Ist bei dir im access auch jede Stunde ein Zugriff von Google drin?

Sowas hier? Das ist der Google-Crawler ... ist normal.

Code Auswählen Erweitern


66.102.9.15 - - [24/Oct/2018:09:12:33 +0200] "POST / HTTP/1.1" 200 231 "-" "Mozilla/5.0 (compatible; Google-Cloud-Functions/2.1; +http://www.google.com/bot.html)"


[SouzA]

Hi,
Ja sowas meinte ich. Dann ist ja alles gut... 

Kurze Rückmeldung:
Seit meiner letzten Meldung habe ich keine Abrisse mehr. Habe auch nichts mehr geändert und nicht an den Einstellungen rumgespielt. Nur normal genutzt! Funktioniert super.

Wenn man ein Rollo einbindet als blind, dann wird dies in der App als Schalter erkannt.... Da muß noch was passieren. 

Bis denn
SouzA