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

[kadettilac89]

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?

ist alles über den link mit port ungleich 443 erreichbar? was wird angezeigt wenn du diese urls aufrufst?

https://<yourdomain>:<your_port>/login
https://<yourdomain>:<your_port>/oauth
https://<yourdomain>:<your_port>/token

POrt ungleich 443 funktioniert, habe ich seit anfang so am laufen.

welche version hast du laufen, branch master oder development?

[habl]

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.

Dann sieht deine Conf ungefähr so aus wie meine, ich würde gerne noch nur die IP-Adressen von google erlauben, habe aber noch keine Möglichkeit gefunden das umzusetzen.

VG
  habl

[kadettilac89]

Dann sieht deine Conf ungefähr so aus wie meine, ich würde gerne noch nur die IP-Adressen von google erlauben, habe aber noch keine Möglichkeit gefunden das umzusetzen.

VG
  habl

nginx kann IP blocken / erlauben .... https://willy-tech.de/nginx-ip-adressen-blockieren/
du musst die IP Bereiche von Google suchen ... ggf.     https://www.lifewire.com/what-is-the-ip-address-of-google-818153

[vbs]

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.

Habe das gleiche Problem mit einem Port ungleich 443: Wenn ich auf die Login-Seite geleitet werden soll, fehlt hinten der Port Gibt es da noch eine weitere Stelle, wo man den Port angeben kann/muss?

[kadettilac89]

Problem Port:

habt ihr nachdem die Konfiguration in Google Action gemacht, oder geändert wurde auch "save" und "test" angeklickt? Warum auch immer wird erst nachdem test aktiviert (geklickt) wurde die Änderung aktiviert.

[vbs]

Danke dir! Mit "Test" hat es dann auf Anhieb geklappt!
Ich hatte insgeheim gehofft, dass damit evtl. auch http-auth gehen würde, aber dem war leider nicht so

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.

nginx matcht ja alle URLs die anfangen wie deine location. Also "location /" filtert nichts und lässt alles durch. Z.b "/login", "/fhem" und eben auch "/oauth". Wenn du darüber filtern willst, musst du wohl einen RegEx-Match bauen, der nur die benötigten URLs zu lässt, also "/login", "/token", "/auth" und vermutlich noch mehr.
Außerdem bedenken, dass der (Sub)domain-Name unverschlüsselt durchs Netz geht. DNS ist fast immer unverschlüsselt und auch in der HTTPS-Anfrage selber, ist die der Domainname zu sehen. Kann also nicht als geheim angesehen werden.

[kadettilac89]

Ich hatte insgeheim gehofft, dass damit evtl. auch http-auth gehen würde, aber dem war leider nicht so
nginx matcht ja alle URLs die anfangen wie deine location. Also "location /" filtert nichts und lässt alles durch. Z.b "/login", "/fhem" und eben auch "/oauth". Wenn du darüber filtern willst, musst du wohl einen RegEx-Match bauen, der nur die benötigten URLs zu lässt, also "/login", "/token", "/auth" und vermutlich noch mehr.
Außerdem bedenken, dass der (Sub)domain-Name unverschlüsselt durchs Netz geht. DNS ist fast immer unverschlüsselt und auch in der HTTPS-Anfrage selber, ist die der Domainname zu sehen. Kann also nicht als geheim angesehen werden.

ich sehe das vielleicht zu unkritisch ... wie kommt man an meine "geheime domain" ... google server hacken, oder netzwerk traffic sniffen. zumindest hoher aufwand. ohne oauth token führt rumtesten über gefundnene, geheime url zu einem 400/404 ... code in nginx und da macht fail2ban die türe zu.

normaler angriff ist ein portscan -- aha, port 1234 offen, schaun wir mal was da läuft -- aha, https -- in diesem scenario kommt die anfrage über die ip und die schließt dann nginx sofort.

für den fall, dass sowohl "geheime domain" bekannt ist, und auch oauth von google gesnifft wird kann jemand bei mir schalten. ansonsten ist das risiko (bei dem ich voll bei dir bin) dass ein bug in node js / oder der ghome lib einen angriffspunkt bietet.

[vbs]

Klar, muss jeder selbst wissen, wie sicher er es haben möchte. Ich geh halt immer davon aus, dass es genug Leute gibt, die da deutlich mehr Ahnung von haben als ich und auch mehr Tricks kennen als ich. Darum bin ich da eher defensiv. Meiner Sorge ist nicht das oauth, sondern eben der Prozess an sich. Ich geh einfach mal pessimistisch davon aus, dass ghome-fhem angreifbar ist. Und da ist halt der einzige Schutz, dass hoffentlich niemand das Ding findet im Netz ist mir persönlich zu wenig, wenn die Domain auch noch ständig unverschlüsselt durchs Netz geht. Bin da jetzt nicht panisch und erwarte da nicht morgen einen Angriff, aber ist für mich sicherlich kein Dauerzustand mit dem ich gut leben kann.
Der Punkt ist vor allem, dass man sich bewusst ist, was man da macht bzw. wie sicher oder unsicher es ist und sich nicht in falscher Sicherheit wähnt... oder sich gar nur Configs aus dem Netz copy/pastet und es dann für sicher hält. Da reicht ja ein falscher Config-Schalter irgendwo und die Sicherheit ist dahin.


Ich hab noch zwei Punkte zu dem Ding an sich:

1. Ich wollte mir gerne ein Dummy-Device in FHEM bauen, welches ein Scene-Device ist bzw. die Scene-Traits hat. Ich dachte, mit "genericDeviceType" könne man einen Gerätetype sozusagen "forcieren", auch wenn die automatische Erkennung es nicht als ein solches Gerät erkannt hat. Also ich hab einfach "genericDeviceType" auf "scene" gesetzt. Das klappt aber so nicht. Wird dann im SYNC-Kommando nicht als "Scene"-Device annonciert. So wie ich den Code verstehe, muss wirklich TYPE selber "LightScene" sein. Also "genericDeviceType" wird da gar nicht ausgewertet (wird sowieso überraschend selten ausgewertet?).

Ich hab dann mal in der ersten Zeile in dem Code "|| genericType == 'scene'" ergänzt, damit er mein Dummy als Szenen-Device behandelt und das klappt damit auch dann. Ich kann dann z.B. mit "aktiviere film" meine Dummy-Device schalten und darauf reagieren.

Code Auswählen Erweitern

    if (s.Internals.TYPE == 'LightScene' || genericType == 'scene') {
        //name attribut ist der name der scene
        this.mappings.Scene = [];
        let m;
        if (m = s.PossibleSets.match(/(^| )scene:(\S+)\b/)) {
            let availableScenes = m[2].split(",");
            availableScenes.forEach(function(scene) {
                this.mappings.Scene.push({scenename: scene, cmdOn: 'scene ' + scene})
            }.bind(this));
        }
    }

Also die Frage: Kriegt man das irgendwie mit Hausmitteln hin? Versteh ich "genericDeviceType" falsch?

2. Als Name der Geräte wird ja das Attribut "alias" übernommen. Bei alexa-fhem gibt es außerdem das Attribut "alexaAlias", mit dem man für Alexa nochmal einen anderen Namen vergeben kann. Es gibt aber offenbar analog kein "ghomeAlias"? Also ich möchte in Google einen anderen Namen als den im "alias" hinterlegten verwenden. Ich weiß, dass ich in der GoogleApp selber auch einen Spitznamen vergeben kann, aber ich würde das gerne fest in FHEM abbilden, damit das nicht verloren gehen kann. Geht das irgendwie?

[kadettilac89]

hast du den master oder development branch aus github eingebunden? dominik hat im development einiges erweitert, ich glaub im master  sind die änderungen noch nicht. scenen nutze ich nicht, kann da sonst nichst dazu beitragen.

[dominik]

development und master sind aktuell gleich auf. Ich empfehle vorerst den master zu verwenden, da es durchaus vorkommen kann, dass ich im development mal was teste was vielleicht paar Fehler hervorruft.

@vbs, das ist richtig. Da fehlt noch eine Abfrage. Ich werde das mit aufnehmen, dass man eine scene die nicht LightScene ist mit on/off steuern kann. Damit kann dann jedes Device eine scene sein.

[dominik]

@vbs, danke für deinen Pull Request für ghomeName. Ich würde das Thema jedoch gerne hier in der Runde vorher besprechen.

Macht es Sinn, dass wir für Google Geräte ein extra Attribut ghomeName einführen? Alexa nutzt bereits alexaName. Aus meiner Sicht müsste das Attribut aber "assistantName" oder so ähnlich heißen. Dann könnte man nämlich in Alexa, Siri, ... immer dieses Attribut nutzen und muss nicht für jedes Teil wieder ein neues Attribut erstellen. Aus diesem Grund habe ich auch keinen alexaRoom erstellt, sondern realRoom. Was meint ihr? Gibt es Vorschläge für einen vernünftigen Namen des Attributs?

[vbs]

Meiner Meinung nach, macht es Sinn, den Namen für jeden Assistenten getrennt definieren zu können. Einfach da verschiedene Assistenten verschieden arbeiten. Zum Beispiel kennt der Alexa-CustomSkill keine Räume (zumindest mein Stand), so dass man einen Spot im Wohnzimmer "Wohnzimmer Spot" nennen musste (falls es noch weitere Spots gab). Hier bei Google möchte ich den gleichen Spot nur "Spot" nennen und den Raum getrennt ansprechen per "schalte Spot im Wohnzimmer ein".
Mag evtl. jetzt (oder auch zukünftig) noch andere Gründe geben, warum man die Geräte unterschiedlichen nennen wollen sollte.

Evtl. kann man aber sogar "assistentName" und ghomeName/alexaName kombinieren? Also es würden (priorisiert) beide benutzt werden: ghomeName/alexaName -> assistentName -> alias -> NAME. Dann hätte man mMn das beste aus beiden Welten.

Das setzt aber in jedem Fall voraus, dass da alle Assistenten-Entwickler mitmachen und sich auf ein Interface einigen.

[SouzA]

Prinzipiell finde ich den Vorschlag gut, einen Namen nur für den Assistant vergeben zu können.
Der Einwand von vbs ist wichtig und muss Beachtung finden. Allerdings wäre das "uns" ghome Usern ja herzlich egal, ob die Alexas ihre Devices mit dem Raumnamen benennen müssen... Das wird wirklich erst interessant, wenn man mehrere Assistants nutzt.
Und hier wäre ich dann auch wieder bei vbs.
Um Leuten, die mal die andere Seite ausprobieren wollen, die einfache Möglichkeit zu geben, sollten getrennte Namen vergeben werden können.
Den Vorschlag mit der Priorisierung würde ich dementsprechend auch unterstützen. Allerdings sehe ich hier die Problematik in der Absprache mit den anderen Modulerstellern.

Bis denn
SouzA

[gvzdus]

Zunächst mal: Ich habe bei der Konfiguration von alexa-Fhem ebensowenig verstanden, warum da in der filter-Config "room=alexa" stand, wie ich jetzt verstehe, warum bei ghome-fhem da "room=GoogleHome" steht. Finde ich doppelt gemoppelt. Am einfachsten ist doch, ich gehe meine zig Devices durch und überlege mir den Namen. Deswegen steht bei mir in der config.json:

Code Auswählen Erweitern

"filter": "alexaName=...*"

(Sollte ich vielleicht ausführen: Ich habe Strukturen, z.B. aus 2 Thermostaten in einem Raum. Da soll die Struktur sichtbar sein, die Thermostate aber nicht. Deswegen haben die Thermostate den alexaName=-, damit sie nicht den Strukturnamen erben. Und der Filter schliesst Namen mit nur einem Zeichen aus).
Auf jeden Fall finde ich die Existenz eines assitantName sinnvoll.

Zweitens und zum Diskussionspunkt: Ich war natürlich glücklich, dass ich - von Alexa kommend - für die zweite Dame des Hauses fast nichts konfigurieren musste, sondern die "alexaNames" übernommen wurden.
Eigentlich wäre aber assistantName logischer. Oder besser noch: "voiceName"? Allerdings macht man die Welt nicht unbedingt besser, wenn man einen dritten Namen in die Welt setzt.
Vorschlag:
ghome-fhem sucht nach "voiceName" (oder wie auch immer), "alexaName" und "ghomeName". Prio 1 hat "ghomeName" wenn vorhanden, Prio 2 "voiceName" und Prio 3 alexaName. Wenn ich etwas exklusiv bei Alexa haben will, setze ich ghomeName auf "-".

[dominik]

Den Vorschlag mit den Prioritäten finde ich ganz gut.

1. ghomeName
2. assistantName
3. alexaName bzw. weitere in Zukunft
4. alias
5. NAME

...und andere würden dann die Prioritäten 1 und 3 tauschen, je nach Device.

Fragt sich nun nur noch ob assistantName der richtige Name ist? Bei Wikipedia werden die Devices als Assistant (virtual Assistant) bezeichnet:
https://en.wikipedia.org/wiki/Virtual_assistant#Full_comparison_of_assistants
Man muss auch bedenken, dass sich das Thema nicht nur auf Voice beschränkt, da die Steuerung auch über die jeweiligen Apps (Home, ...) möglich ist.