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

[vbs]

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.

Öhm, "alexaName" wird doch von ghome-fhem genau NICHT übernommen, oder? Soweit ich weiß, ist das einzige, was beide Assistenten gleichermaßen benutzen das "genericDeviceType"? Evtl. macht es sogar auch da Sinn, das irgendwann mal zu trennen, so dass man das pro Assistent spezifisch angeben kann.

Den Vorschlag mit den Prioritäten finde ich ganz gut.
1. ghomeName
2. assistantName
3. alexaName bzw. weitere in Zukunft
4. alias
5. NAME

Bin nicht so sicher, ob ghome wirklich auf alexaName zurückfallen sollte. Ich verstehe die ghome/alexaName-Attribute wirklich als hart assistenten-spezifisch. Wenn im Normalfall alle meine Devices nur "alias" haben und ich dann speziell für Alexa bei einem Device alexaName vergebe, dann würde dieser Name ja auch sofort von ghome verwendet werden? Man hat dann ja keine Chance mehr, spezifisch für einen Assistenten einen Namen zu vergeben ohne andere auch mit zu beeinflussen.

[SouzA]

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 "-".

Die Config mit den Ghomeroom oder eben Alexroom finde ich mehr als Sinnvoll. Man hat halt alle Devices, die im Assistant Verwendung finden sollen, auf einem Blick.
Zudem kannst du ja den Raum auch einfach Assistant nennen und in der jeweiligen Config anpassen. Dann hast du halt nur noch einen Raum für beide Assistants.

Wie die einezlnen Namen heißen ist mir eigentlich völlig wurscht. Ich würde assistantName als sinnvoll ansehen, da die Gerätschaften sich selbst als Assistenten beschimpfen.
Weiterhin ghomeName und alexaName.

Code Auswählen Erweitern


1. ghomeName / alexaName / ... (da muss jeder Moduler nach seinem Attribut gucken und wenn nicht vorhanden das anderen nehmen, wenn vorhanden)
2. assistantName
3. alias
4. NAME


Bis denn
SouzA

[gvzdus]

Meine Überlegung bei "Voice" ggü. "Assistant": Zumindest Alexa ist eine Zicke, was Namen betrifft. Ich verstehe auch nicht, warum, wenn ich ein Zimmer "Carl" und ein Zimmer "Anna" habe, mir regelmäßig gesagt wird, dass kein Zimmer Karel und kein Zimmer Hanna gefunden wurde. Zumindest Alexa interessiert sich nicht dafür, einen "Best-Match" zu finden. Kurz: Ich habe die Namen für die Voice-Assistenten teilweise anders als in der GUI gewählt, damit die Trefferquote steigt.

Zur Anmerkung von vbs: Kann gut sein. Ich habe die harte Tour gewählt und mit der "yanniks"-Version gestartet - siehe meinen Beitrag "Eselsmütze"

[Phantomato]

Hallo,
vielen Dank für das tolle Addon. Endlich konnte ich damit mein Google Home mini im Betrieb nehmen. Alles funktioniert wunderbar. Allerdings habe ich noch 3 Unklarheiten.

1. In der Google Home App steht öfters der falsche Schaltzustand drin. Soweit ich sehen kann kriegt der Connector den neuen zustand mit, dennoch zeigt die App falsch an (Lampen und Schalter).
2. Die Schaltbestätigung "na klar, ich schalte jetzt das Licht in Bad an" ist irgendwie nervig. Lässt sich irgendwo eine kürzere Antwort einstellen? (so zb ein "OK" wie bei Alexa?)
3. Dummys werden nicht angezeigt obwohl genericDeviceType und homebridgeMapping gesetzt ist. Alexa room ist richtig. Alexa und GoogleHome haben bei mir einen gemeinsamen Room

Code Auswählen Erweitern


define BzEnableMotionDetection dummy
attr BzEnableMotionDetection alias Bewegungsmelder Bad
attr BzEnableMotionDetection devStateIcon on:on:off off:off:on
attr BzEnableMotionDetection genericDeviceType switch
attr BzEnableMotionDetection homebridgeMapping on=state,cmdOn=on,cmdOff=off
attr BzEnableMotionDetection mqttForward all
attr BzEnableMotionDetection mqttPublish state:topic={"stat/$device/$reading"} *:retain=1
attr BzEnableMotionDetection mqttSubscribe state:stopic={"cmnd/$device/$reading"}
attr BzEnableMotionDetection room Alexa,Bad
attr BzEnableMotionDetection webCmd on:off[/code}


[dominik]

Danke euch fuer das Feedback. Ich denke folgende Variante von euch macht nun am meisten Sinn:

1. ghomeName / alexaName / ... (da muss jeder Moduler nach seinem Attribut gucken und wenn nicht vorhanden das anderen nehmen, wenn vorhanden)
2. assistantName
3. alias
4. NAME

Damit kann jeder seine Spezialitaeten pro Assistant definieren, aber auch Gemeinsamkeiten ueber assistantName nutzen.

@Phantomato
1. Wird jedes mal aktualisiert wenn du das jeweilige Device oeffnest. Das dauert leider ein paar Sekunden, da Google zuerst die QUERY an FHEM schickt. Google hat vor paar Wochen eine Report State API rausgebracht die den Status gleich bei Google speichert. Damit geht es dann schneller, aber das muss zuerst noch in ghome-fhem implementiert werden.
2. Ist leider nicht moeglich.
3. Dein Dummy hat keine setList mit on/off, das ist wahrscheinlich der Grund wieso es nicht funktioniert.

[Phantomato]

3. Dein Dummy hat keine setList mit on/off, das ist wahrscheinlich der Grund wieso es nicht funktioniert.

Vielen Dank. Das war der Grund.

[moi]

Hallo,
vorab vielen Dank für die Software bzw. die Anleitung.
Ich wollte gestern ghome-fhem einrichten und bin auch ziemlich weit gekommen.
Beim Abrufen der FHEM-Instanz über den Google Assistenten kann ich mich erfolgreich authentifizieren-jedoch falle ich anschließend immer wieder auf den ursprünglichen Screen "Smart-Home-Steuerung" im Google Assistenten zurück.

Im Log findet sich folgender Eintrag:

Code Auswählen Erweitern

Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] got: 3 results
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] REED_3 is contact
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] REED_3 has
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] WZ.LICHT is light
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] WZ.LICHT has
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] ebusd.log.Aussentemp is thermometer
Dec 09 21:46:50 raspberrypi ghome[21664]: [12/9/2018, 9:46:50 PM] [FHEM] ebusd.log.Aussentemp has
Dec 09 21:46:50 raspberrypi ghome[21664]: response :{"requestId":"4460450891362497168","payload":{"devices":[]}}
Dec 09 21:46:50 raspberrypi ghome[21664]: POST / 200 77.801 ms - -
Dec 09 21:46:51 raspberrypi ghome[21664]: GET /service-worker.js 200 4.760 ms - 678

Ich habe 2 Devices den Raum zugewiesen und das GenericDeviceType Attribut vergeben:

Code Auswählen Erweitern

defmod REED_3 KNX 4/0/2:dpt1
attr REED_3 IODev tul
attr REED_3 alias Kuche
attr REED_3 devStateIcon on:fts_window_1w_open@red off:fts_window_1w@green
attr REED_3 event-on-change-reading .*
attr REED_3 genericDeviceType contact
attr REED_3 group Fensterkontakte EG
attr REED_3 room Fensterkontakte,GoogleHome

defmod ebusd.log.Aussentemp dummy
attr ebusd.log.Aussentemp alias Aussentemperatur
attr ebusd.log.Aussentemp event-on-change-reading .*
attr ebusd.log.Aussentemp genericDeviceType thermometer
attr ebusd.log.Aussentemp group Warmepumpe
attr ebusd.log.Aussentemp icon temp_outside
attr ebusd.log.Aussentemp room GoogleHome,Mosquitto
attr ebusd.log.Aussentemp setList 1

Gibt's da etwas was ich übersehen habe? Für Hilfe wäre ich sehr dankbar!

beste Grüße, Martin

[vbs]

@dominik
Wie ist deine Meinung bzgl. Sicherheit dieser Lösung? Ist das wirklich so, dass es technisch seitens Google nicht möglich ist, die HTTP-Schnittstelle per basic-auth oder ähnlichem zu sichern? Ich mag da die Hoffnung momentan noch nicht aufgeben...
Ich hab da etwas Bauchschmerzen, den ghome-fhem direkt ohne weiteren Schutz im Internet erreichbar zu machen. Wie siehst du das?

[SouzA]

Hi,
warum eigentlich ohne weiteren Schutz?
Du gibst doch deinen user und nen PW bei Google Actions ein.
Oder hab ich jetzt irgendwas grundlegend noch nicht verstanden?

Bis denn
SouzA

[vbs]

Der ghome-fhem ist im Endeffekt ein http-Server, der auf einem TCP-Port auf Verbindungen aus dem Internet lauscht. Der Prozess muss also sämtliche Pakete, die bei ihm ankommen möglichst fehlerfrei verarbeiten, da sonst Sicherheitslücken drohen. Andere große Webserver wie apache oder nginx durchlaufen zu diesem Zweck viele Code-Reviews, Sicherheitsaudits, jahrelange Codepflege usw.

Kurz gesagt: wie sicher ist man sich, dass es keinem Hacker gelingt, den PW-Schutz in ghome-fhem zu umgehen bzw. gleich den ganzen Prozess per Buffer-Overflow o.ä. zu kapern?

[dominik]

Mal ein kurzes Update zur Realisierung eines offiziellen FHEM Smart Home Actions (alles proof of concept aktuell!):

Folgendes habe ich gemacht...
- Auth0 eingerichtet
- Google Firebase Cloud Functions eingerichtet
- Google Firestore eingerichtet
- Google Action eingerichtet

Resultat
- ghome-fhem fragt nach dem Auth0 Login (es geht auch Login with Google oder neuen Account anlegen)
- ghome-fhem synchronisiert die Devices nach Google Firestore, welches ebenfalls nur mit dem Auth0 Account moeglich ist, KEIN Portforwarding notwendig
- Ich kann mich per "Login with Google" (oder neuen Account) in der Home App anmelden
- Devices werden synchronsiert

Einfache "Architekturdarstellung"
ghome-fhem <=> Google Firestore <=> Firebase Cloud Functions <=> Google Assistant
Token und Authorization Service von Auth0. Der Token wird bei jedem Service geprueft.

Damit ist die gesamte Strecke inkl. der Firestore Datenbank ueber auth0 (OAuth2) gesichert und niemand anders kann irgendwo zugreifen.

Wie gesagt, im Moment alles als Proof of Concept. Ich werde nun noch EXECUTE und QUERY implementieren und sobald das laeuft eine moegliche Produktiveinrichtung vornehmen.

[SouzA]

Von was redet der?
Soll das bedeuten, dass keine eigenen Actions mehr nötig wären?
Bin mal gespannt....

Bis denn
SouzA

[dominik]

Ja, das habe ich vergessen zu schreiben 

Man muss dann nur mehr:
- Den abgespeckten ghome-fhem Client starten
- Authentifizieren
- Home App oeffnen und dort FHEM auswaehlen
- Authentifizieren

Fertig! Kein Action einrichten, kein Portforwarding und alles sicher.

[SouzA]

Goil!
Du bist der Beste! 

[FEHMPiDi]

Das wäre ja echt genial. Wann kann man denn mit der ersten Testversion rechnen? Ich wollte nämlich auch mal mit Google home starten. Alexa hatte ich jetzt ein paar Wochen zu Hause, war aber nicht zufrieden. Ich hoffe Google kann mich da besser überzeugen.
Die Frage ist nun starte ich noch mit dem alten HowTo, oder warte ich auf Deine neue Lösung.