Diese Anleitung wird nicht mehr offiziell supported, bitte waehle den einfacheren Weg den Google Assistant Einrichtung ueber folgende Anleitung:
https://forum.fhem.de/index.php/topic,96696.0.html
Hallo zusammen,
ich möchte an dieser Stelle nun offiziell die FHEM Integration in Google Home/Assistant vorstellen. Danke vielmals an die Vorarbeiten von justme-1968 (homebridge-fhem) und yanniks (ghome-fhem) ohne die ich die Integration sicher nicht weiter verfolgt hätte.
Anleitung
https://github.com/dominikkarall/ghome-fhem/blob/master/README.md
Bitte beachtet, dass ich versuche die Integration der Devices weitestgehend automatisch durchzuführen. Das bedeutet, dass im Normalfall kein genericDeviceType oder homebridgeMapping gesetzt werden muss, sondern das Device, wie in der Anleitung beschrieben, nur dem Raum hinzugefügt werden muss.
Nützliche Informationen
Hier die Liste der Device Traits (https://developers.google.com/actions/smarthome/traits/) welche unterstützt werden. In Klammer wo diese aktuell verwendet werden und darunter Beispiele für die Verwendung mit OK Google...
- Brightness (Helligkeit, Volume, Rollo)
"...stelle die Wohnzimmerlampe auf 50%"
"...stelle das Wohnzimmer Radio auf 13%"
- ColorSetting (RGB, HSV und Color Temperature Lichter)
"...stelle die Lampe auf rot"
"...stelle die Lampe auf warm weiß"
- Dock (Xiaomi Vacuum)
"...ist der Staubsauger angedockt?"
"...sende den Staubsauger in die Ladestation"
- FanSpeed (-)
Funktioniert auf Deutsch noch nicht, daher nicht in Verwendung.
- Locator (Xiaomi Vacuum)
"...suche den Staubsauger"
- Modes (Xiaomi Vacuum)
Funktioniert auf Deutsch noch nicht, daher nicht voll integriert.
- OnOff (alle Geräte die on/off als cmd nutzen)
"...schalte die Kaffeemaschine ein"
"...schalte die Lichter im Wohnzimmer aus"
- Scene (LightScene)
"...aktiviere den Partymodus"
- StartStop (Xiaomi Vacuum)
"...starte den Staubsauger"
"...stoppe den Staubsauger"
"...läuft der Staubsauger gerade?"
"...pausiere den Staubsauger"
- TemperatureSetting (Thermostat, Temperatursensor)
"...stelle die Wohnzimmer Heizung auf 22 Grad."
"...auf wie viel Grad steht die Lüftung?"
- Toggles (-)
Funktioniert auf Deutsch noch nicht, daher nicht in Verwendung.
Neue Attribute:
- realRoom
Wird verwendet um den Raum bei der ersten Synchronisation des Gerätes in Google zu setzen. Google hat es so implementiert, dass es nur bei der erstmaligen Synchronisation in Google Home gesetzt wird!
- genericDeviceType
Erweitert um Google Device Types (https://developers.google.com/actions/smarthome/guides/). Muss im Normalfall nicht gesetzt werden.
Bei Problemen, Wünschen, Anregungen, ... nutzt bitte ausschließlich diesen Thread. Code Beiträge nehme ich sehr gerne als Pull Request für den development Branch (https://github.com/dominikkarall/ghome-fhem/tree/development) auf.
Danke nochmals an alle die bei der Entwicklung mitgeholfen haben (Dokumentation, Code Beiträge, Support, ...)!
Viel Spaß!
Gruß,
Dominik
Reserviert
Reserviert
Reserviert
Folgendes Szenario:
Ich würde gern einen über MQTT angebundenen Dimmer steuern.
Mit diesem Device würde ich gern den Dimmzustand setzen. (an/aus funktioniert bereits)
List vom MQTT Dev:
Internals:
IODev mqtt
NAME mqtt_regal
NR 373
STATE 0
TYPE MQTT_DEVICE
READINGS:
2018-11-28 01:54:57 state 0
2018-11-28 01:54:57 transmission-state incoming publish received
message_ids:
publishSets:
:
topic adl/Schalter/regal/schalte
values:
on
off
state:slider,0,1,100
state:
topic adl/Schalter/regal/schalte
values:
slider,0,1,100
sets:
off
on
state:slider,0,1,100
subscribe:
adl/Schalter/regal/state
subscribeExpr:
^adl\/Schalter\/regal\/state$
subscribeQos:
adl/Schalter/regal/state 0
subscribeReadings:
adl/Schalter/regal/state:
cmd
name state
Attributes:
IODev mqtt
alias Regal
publishSet on off state:slider,0,1,100 adl/Schalter/regal/schalte
room GoogleHome
stateFormat state
subscribeReading_state test/Schalter/regal/state
webCmd off:state:on
Grüße
Klaus
Kannst du mir sagen wie das Command für das Dimmen lautet und aus welchem Reading man den aktuellen Wert des Dimmers erhält? Dann könnte ich das mit integrieren.
Hi,
Was mir gerade zu scenes auffällt ist, dass wenn einzelne Szenen entfernt werden oder das gesamte LightScenes device aus dem Synchordner entfernt wird, wird dies nicht in der App nachgeführt. Selbst nach mehrmaligem synchen und zwei Stunden warten sind die scenes noch da.
Eine Neuverbindung in der App bereinigt dies wieder.
Bei anderen Devices geht das allerdings durch das normale synchen. Nur halt bei scenes nicht.
Ist das bei anderen auch so?
Bis denn
SouzA
Zitat von: dominik am 28 November 2018, 21:23:33
Kannst du mir sagen wie das Command für das Dimmen lautet und aus welchem Reading man den aktuellen Wert des Dimmers erhält? Dann könnte ich das mit integrieren.
Auf 5% setzen:
set <gerätename> 5
Aus
set <gerätename> off
Ein
set <gerätename> on
Der Dimmwert ist in state. Das lässt sich aber anpassen.
Das macht vielleicht auch Sinn. Aber das weisst du sicher besser.
@Klaus, ist das "normal" bei den MQTT Devices, dass nur ein set <name> PROZENT notwendig ist? Also muss ich aus state on/off 0-100 auswerten?
@SouzA, das muss ich mir genauer anschauen woran das liegt. Ich melde mich dazu noch...
Zitat von: dominik am 28 November 2018, 22:38:21
@Klaus, ist das "normal" bei den MQTT Devices, dass nur ein set <name> PROZENT notwendig ist? Also muss ich aus state on/off 0-100 auswerten?
nein, MQTT ist da sehr flexibel. Es können beliebige set Befehle angelegt werden, welche dann die Werte über MQTT rausschicken.
Im Regenzug können ankommende Werte in beliebige Readings gesteckt werden.
man könnte als auch ein
set <name> dim PROZENT machen.
Eventuell mußt du gar nix anpassen und ich erzeuge die entsprechenden readings/set befehle.
Das wäre sogar sinnvoller. Da man sich an bestehenden Strukturen anlehnt.
Ich hätte noch eine Frage. Was ist bei Geräten mit gleichem Namen in unterschiedlichen Räumen?
Geht das, oder muß ich mir für jedes Licht einen separaten Namen ausdenken?
Ja, in diesem Fall ist es definitiv sinnvoller wenn du das MQTT Device so anlegst, dass es die Standardkommandos unterstützt:
on / off / pct 0-100
Aktuelle Helligkeit gespeichert im Reading: pct
Damit wird es als Licht inkl. Helligkeitsregelung richtig erkannt.
Gleiche Name in unterschiedlichen Räumen sollte kein Problem sein. Wenn du "alias" für die Namen verwendest, ist das sowieso nur ein informativer Wert.
Zitat von: SouzA am 28 November 2018, 22:20:33
Hi,
Was mir gerade zu scenes auffällt ist, dass wenn einzelne Szenen entfernt werden oder das gesamte LightScenes device aus dem Synchordner entfernt wird, wird dies nicht in der App nachgeführt. Selbst nach mehrmaligem synchen und zwei Stunden warten sind die scenes noch da.
Eine Neuverbindung in der App bereinigt dies wieder.
Bei anderen Devices geht das allerdings durch das normale synchen. Nur halt bei scenes nicht.
Ist das bei anderen auch so?
Kannst du bitte mal beim SYNC im Log prüfen ob die Scenes auch wirklich nochmals an Google übertragen werden? Ich habe gerade im Code geprüft und da sollte definitiv nichts mehr übertragen werden, egal ob eine einzelne Scene weg ist oder das gesamte Device.
Hallo,
so ganz will das bei mir nicht klappen. Ich habe bereits den alexa connector auf port 3000 am laufen. Der GHome braucht ebenfalls diesen. Lässt es sich ohne weiteres ändern?
Zitat von: kadettilac89 am 24 November 2018, 19:07:47
Beide auf selbem Port geht nicht.
In Config.json kannst du den Port beliebig ändern.
{
"ghome": {
"port": 3005,
"name": "Google Home",
Ok. Danke. Dachte da steckt mehr dahinter.
In der Anleitung sollte auch aufgenommen werden was zu tun ist wenn fhem durch passwort und ssl abgesichert ist:
"connections": [
{
"name": "FHEM",
"server": "127.0.0.1",
"port": "8083",
"ssl":true,
"auth": {"user": "fhemUser", "pass": "fhemUserPasswort"},
"webname": "fhem",
"filter": "room=GoogleHome"
}
hallo,
ich komm trotz der sehr guten Anleitung einfach nicht weiter :-[
ich denke ich bin gefühlt 5x nach Anleitung vorgegangen, ich bekomme einfach die login Seite nicht angezeigt (Cannot GET /login).
oauth (response_type undefined must equal "code") und
token (missing required parameter) funktionieren soweit.
wenn ich ghome per cmd starte, erhalte ich folgende Ausgabe:
root@server:/opt/ghome-fhem/bin# ./ghome
[2018-12-2 16:16:29] using /root/.ghome/config.json
[2018-12-2 16:16:29] ---
[2018-12-2 16:16:29] this is ghome-fhem 0.4.0
[2018-12-2 16:16:29] Fetching FHEM devices...
[2018-12-2 16:16:29] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1543763789999
[2018-12-2 16:16:30] Server listening on: https://:::3000
[2018-12-2 16:16:30] [FHEM] Checking devices and attributes...
[2018-12-2 16:16:30] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22,%22userattr%22,%22%22)%7D&fwcsrf=csrf_483417543482159&XHR=1
[2018-12-2 16:16:30] [FHEM] Fetching FHEM devices...
[2018-12-2 16:16:30] [FHEM] fetching: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20room=GoogleHome&fwcsrf=csrf_483417543482159&XHR=1
[2018-12-2 16:16:30] [FHEM] got: 1 results
[2018-12-2 16:16:30] [FHEM] r4ArbeitszLampe1 has
[2018-12-2 16:16:30] [FHEM] On [state;on,off]
[2018-12-2 16:16:30] [FHEM] { reading: 'state',
valueOff: '/off|A0|000000/',
cmdOn: 'on',
cmdOff: 'off',
device: 'r4ArbeitszLampe1',
format: 'bool',
informId: 'r4ArbeitszLampe1-state',
characteristic_type: 'On',
log:
{ [Function: bound ]
debug: [Function],
info: [Function],
warn: [Function],
error: [Function],
log: [Function],
prefix: 'FHEM' } }
2018-12-02 16:16:30 caching: r4ArbeitszLampe1-state: on
GET /oauth 400 27.812 ms - 41
/token query {}
/token body {}
missing required parameter
GET /token 400 10.557 ms - 26
GET /login 404 63.785 ms - 144
ich würde ja vermuten, das hier das frontend nicht installiert ist. Ist es aber.
Ich habe es momentan auf ein Debian Strech installiert, allerdings auch schon auf ein Ubuntu 18.04 getestet: genauso erfolglos.
Was kann ich noch überprüfen/testen...
fragende Grüße
habl
Ist der login-pfad lokal erreichbar? Was passierten wenn du http://<lokale ip>:3000/login aufrufst? Nutzt du reverse Proxy?
Mal rebootet?
Zitat von: kadettilac89 am 02 Dezember 2018, 18:52:01
Ist der login-pfad lokal erreichbar? Was passierten wenn du http://<lokale ip>:3000/login aufrufst? Nutzt du reverse Proxy?
Mal rebootet?
nein, auch lokal nicht erreichbar und auch ein reboot hat bisher leider nicht geholfen, andere ideen? gib es evtl logdateien?
Schau mal bitte, dein ghome start log zeigt https://:::3000 dies bedeutet, das du auch den Testaufruf mit https machen musst.
Läuft dein ghome unter root? Ist aus security sicht nicht zu empfehlen. Ich weiß nicht ob irgendwo in nodejs eine prüfung darauf läuft. Teste mal mit pi oder einem anderen normalen user. Ggf. Musst fu fie Rechte entsprechend setzen.
Zitat von: pattex am 02 Dezember 2018, 19:11:41
Schau mal bitte, dein ghome start log zeigt https://:::3000 dies bedeutet, das du auch den Testaufruf mit https machen musst.
ja, hatte ich schon beides durch, weder mit noch ohne ssl geht's (probier schon ein wenig länger ;) )
Hat das denn mal funktioniert? Ich habe von ca. 1 Woche ein Änderung an den Urls gemacht, damit der ghome besser Reverse Proxy tauglich wird. Evtl. ist da was bei schief gelaufen...
Ich konnte gerade das Verhalten was du beschrieben hast bei mir nachstellen. Wenn ich ghome unter dem User pi starte, bekomme ich die gleichen Meldungen wie du. Wenn ich ghome normal über service ghome start starte, dann funktioniert es. Kannst du das bestätigen?
Wenn du ghome direkt aus dem bin Verzeichnis aufrufst, kommst es zu dem Verhalten. rufst du aus dem ghome-fhem verzeichnis mit ./bin/ghome auf, klappt es.
Zitat von: pattex am 02 Dezember 2018, 19:23:34
Hat das denn mal funktioniert? Ich habe von ca. 1 Woche ein Änderung an den Urls gemacht, damit der ghome besser Reverse Proxy tauglich wird. Evtl. ist da was bei schief gelaufen...
vor ca 1 Monat hat es funktioniert, dann hat's vorletzte Woche durch ein Stromausfall mein Wlan Router zerschossen.
Ich wollte jetzt das ganze mal aktualisieren.. und jetzt bekomme es nicht mehr am hin :-[
Ich habe es auch schon auf einer virtuellen Ubuntu 18.04 versucht, da war das gleiche Problem.
es könnte natürlich auch an der Änderung liegen ?!
Zitat von: pattex am 02 Dezember 2018, 19:39:18
Ich konnte gerade das Verhalten was du beschrieben hast bei mir nachstellen. Wenn ich ghome unter dem User pi starte, bekomme ich die gleichen Meldungen wie du. Wenn ich ghome normal über service ghome start starte, dann funktioniert es. Kannst du das bestätigen?
Wenn du ghome direkt aus dem bin Verzeichnis aufrufst, kommst es zu dem Verhalten. rufst du aus dem ghome-fhem verzeichnis mit ./bin/ghome auf, klappt es.
ja, kann ich bestätigen. So funktioniert es, Super vielen Dank!
Wobei, wo ist jetzt ein Unterschied? Es sollte doch eigentlich beides funktionieren?!
Da gebe ich dir recht. Für die Authentifizierung wird das Verzeichnis frontend benutzt. Verweise darauf beginnen mit ./frontend er sucht also in bin nach frontend. da gibts kein frontend und somit wird nichts angezeigt.
Ich versuche gerade durch den code zu blicken. Evtl. kann man das Abfangen, damit nicht noch jemand in die Falle tappt :-)
einen hab ich noch :)
sofern ich die Login - Seite aufrufe und ohne (oder mit?) Credentials den Login Button betätige, erhalte ich das als Rückgabe:
Error: No default engine was specified and no extension was provided.
at new View (/opt/ghome-fhem/node_modules/express/lib/view.js:61:11)
at Function.render (/opt/ghome-fhem/node_modules/express/lib/application.js:570:12)
at ServerResponse.render (/opt/ghome-fhem/node_modules/express/lib/response.js:1008:7)
at login (/opt/ghome-fhem/lib/auth-provider.js:390:16)
at /opt/ghome-fhem/lib/auth-provider.js:211:20
at Layer.handle [as handle_request] (/opt/ghome-fhem/node_modules/express/lib/router/layer.js:95:5)
at next (/opt/ghome-fhem/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/opt/ghome-fhem/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/opt/ghome-fhem/node_modules/express/lib/router/layer.js:95:5)
at /opt/ghome-fhem/node_modules/express/lib/router/index.js:281:22
ist das bei euch auch so?
Sieht deine Login Seite so wie im Anhang hier aus?
Zitat von: pattex am 02 Dezember 2018, 20:41:13
Sieht deine Login Seite so wie im Anhang hier aus?
Ja, genauso. Wenn ich die richtigen Credentials eingebe funktioniert es auch.
Hi Dominik,
angenommen, ich merge alexa-fhem von justme-1968 mit ghome-fhem: Zunächst als Branch, nach "Abnahme" dann in den Head.
Würde Dir das passen, oder ist Dir das Google-Only lieber?
Hintergrund: Ich habe einerseits den Code von justme-1968 etwas erweitert, z.B. um generische Erkennung meines Zoos. Andererseits habe ich mir jetzt auch Google-Home zwecks Vergleich zugelegt. Ich denke, es wäre sinnvoller, wenn die beiden Damen in einer Codebasis gepflegt werden, weil die Arbeit wohl eher in der Device-Seite besteht.
Cheers, Georg
Hi Georg,
gerne kannst du das machen. Ich hatte einiges aus dem homebridge Code entfernt, um mir überhaupt mal einen Überblick zu verschaffen.
Manche Sachen sind jedoch Device spezifisch, z.B. unterstützt Google Assistant "Modes" die es meines Wissens bei Alexa noch nicht gibt. Man kann aber solche Dinge einfach im Code belassen und in der server.js werden die dann nicht verarbeitet.
Gruß
Dominik
Okay, das ist ein Wort. Dann mal gucken, dass ich den ersten Wurf eines Merge hinbekomme.
Weitere Perspektive:
Ich hatte heute mein "Heureka". Über Google Home und ngrok bin ich auf https://serveo.net/ gestoßen. Wenn man sich anguckt, wie viele Beiträge hier um "ich krieg' die Connectivity" nicht hin gehen, und sich anguckt, wie viele Verrenkungen es benötigt, um Alexa zu integrieren (bei Google ist das ja etwas einfacher), ist eigentlich da eine Lösung in Form eines Public-Skills m.E. etwas überfällig. justme-1968 hatte ja mal was angedacht - ist dann aber wohl - wie ich oft auch - nicht zur Umsetzung gekommen.
Meine Idee ist nun folgende, die würde ich gerne mal zur Diskussion stellen:
1) Der Nutzer baut den SSH-Tunnel a la serveo.net zum "Einheitsserver" mit Reverse-Tunnel auf. Bzw.: ghome-fhem macht das automatisch.
2) Der neue Key wird erkannt, der "Einheitsserver" sendet einen längeren Auth-Code (Zufallszahl) zurück, der beim OAuth2-Connect von Google und Amazon händisch eingegeben werden muss, wenn der FHEM-Smarthome-Skill installiert wird.
3) Der "Einheitsserver" kann auch OAuth. Beim Account-Linking vergibt er nach Eingabe des Auth-Codes den OAuth2-Code bzw. die Tokens.
4) Kommt nun ein HTTPS-Request vom Skill beim "Einheitsserver" an, schickt der die Requests in den anhand des Bearer-Tokens identifizierten persönlichen SSH-Tunnel mit dem zugeordneten SSH-Key, wo sie dann beim lokalen nodejs landen und zu FHEM gehen.
Der "Einheitsserver" hat also 3 Interfaces:
- SSH inbound zum "Raspberry" etc. mit Auto-Provisionierung (Authcode für Anmeldung)
- HTTPS: OAuth2, zur Vergabe Authcode -> Code für Oauth2 -> Bearer-Token
- HTTPS: Inbound als zentraler Host für Requests vom Skill, die anhand des Bearer-Tokens in den richtigen SSH-Tunnel des Nutzers geroutet werden.
Vorteile:
- Keine offenen Ports
- Simple Installation ohne Developer-Registration etc. - wie die kommerzielle Welt.
- nodejs kann und sollte auf localhost laufen.
- Deutlich schneller, weil kein SSL-Context aufgebaut werden muss.
- Den ganzen hässlichen Overhead von Correlation-ID und Bearer-Token (bei Amazon) muss man eigentlich nicht durchreichen, und die Kommunikation kann per HTTP geführt werden, weil SSH schon Security & Encryption bereitstellt.
Nachteile:
- Muss jemand machen :-) Und den "Einheitsserver" sponsern :-)
- "Die dritte Partei" im Spiel, eine Sache des Vertrauens.
Da mein DS-Light Unitymedia Anschluss zur Zeit auf IPv4-Layer sehr unzuverlässig ist, und inbound IPv4 ohnehin nicht klappt, ist meine Krücke z.Zt. der eigene Webserver beim Hosting-Partner, der dann über IPv6 zum heimischen Raspberry als Reverse-Proxy geht. Alles irgendwie krank, und auch definitiv langsamer als z.B. Hue.
Ich bin auch schon am überlegen eine offizielle Action zu bauen, um diese mühsame Einrichtung zu umgehen.
Meine aktuelle Idee:
- Auth0 als Authentication Provider
- Firebase mit Auth0 authentifizieren
- Lokaler nodejs mit Auth0 authentifizieren und Firestore Verbindung
- Cloud Function als Endpoint für Assistant welches dann über Firestore die Verbindung zum lokalen nodejs aufbaut
Ich habe jedoch noch nie mit Firestore gearbeitet, daher muss ich mich mal einlesen ob das überhaupt so gehen kann.
Schon ziemlich fette Frameworks, wenn ich das richtig gegooglet habe: Ich mag an serveo.net diesen Ansatz: "Probier doch mal das eine Kommando oben aus, und Du hast es".
Egal. Ich glaube, was auch immer jenseits von "Werde Developer bei Amazon etc" real da wäre, würde gut ankommen.
Hallo, bei mir bleibt der Dienst immer stehen... Ich habe alles nach ANleitung installiert komme aber nicht weiter. wo finde ich denn die logs, weshalb der dienst stehenbleibt?
Das sonstige Einrichten hat super geklappt...
Danke für Eure Hilfe...
pi@raspberrypi:~/.ghome $ sudo systemctl status ghome
● ghome.service - Google Assistant FHEM Connector
Loaded: loaded (/lib/systemd/system/ghome.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2018-12-03 20:36:40 CET; 17s ago
Process: 2778 ExecStart=/home/pi/ghome-fhem/bin/ghome (code=exited, status=1/FAILURE)
Main PID: 2778 (code=exited, status=1/FAILURE)
Dez 03 20:36:39 raspberrypi systemd[1]: ghome.service: Unit entered failed state.
Dez 03 20:36:39 raspberrypi systemd[1]: ghome.service: Failed with result 'exit-code'.
Dez 03 20:36:40 raspberrypi systemd[1]: ghome.service: Service hold-off time over, scheduling restart.
Dez 03 20:36:40 raspberrypi systemd[1]: Stopped Google Assistant FHEM Connector.
Dez 03 20:36:40 raspberrypi systemd[1]: ghome.service: Start request repeated too quickly.
Dez 03 20:36:40 raspberrypi systemd[1]: Failed to start Google Assistant FHEM Connector.
Dez 03 20:36:40 raspberrypi systemd[1]: ghome.service: Unit entered failed state.
Dez 03 20:36:40 raspberrypi systemd[1]: ghome.service: Failed with result 'exit-code'.
sudo journalctl -u ghome.service
Mit den Cursortasten kann man durch das Log navigieren.
ok DANKE :-) Problem gefunden war ein Fehler in der config json... Jetzt komm ich auf die seite im eigenen netz, aber noch nicht hinter dem reverse proxy...
Zitat von: dominik am 29 November 2018, 19:34:12
Kannst du bitte mal beim SYNC im Log prüfen ob die Scenes auch wirklich nochmals an Google übertragen werden? Ich habe gerade im Code geprüft und da sollte definitiv nichts mehr übertragen werden, egal ob eine einzelne Scene weg ist oder das gesamte Device.
Hi,
ich hab mal versucht das nachzuvollziehen.
Mit
journalctl -u ghome --no-pagerkriege ich ja eigentlich alles angezeigt. Nach "synchronisiere meine Geräte" kommt erst einmal eine ganze Latte an removing's.
Darunter auch mein LightScene-Device.
Das ist aber auch das einzige mal, dass das Device im Log auftaucht. (Es ist noch im "Sync-Raum") Wie soll ich nun beurteilen, ob da noch was übergeben wird? :o
Namensänderungen der Szenen werden aber definitiv sofort mitgenommen.
Bis denn
SouzA
Btw.
Jetzt habe ich die Scenen einmal umbenannt und wieder zurück benannt. Jetzt habe ich zwei weitere Szenen unter "Ambiente steuern" in der App. Unter Geräte taucht allerdings nur eine Szene auf(was auch richtig wäre). Scheint nen Bug in der App zu sein.
Zitat von: jf.mennedy@gmail.com am 03 Dezember 2018, 21:12:53
ok DANKE :-) Problem gefunden war ein Fehler in der config json... Jetzt komm ich auf die seite im eigenen netz, aber noch nicht hinter dem reverse proxy...
Hi,
Apache?
Wie sieht deine sites-available config aus?
Folgendes zu meiner config:
1.) Einen willkürlichen Port in den Actions bei Google eingetragen. Z.B: https://<<sub.deineSeite>>:55786 ..../oauth ..../token
2.) Diesen Port "55786" in der FritzBox auf Port "443" des Raspi umgeleitet. Ein anderer Port hat bei mir nicht funktioniert. Unfähigkeit oder Ungeduld. Beides möglich...
3.) sites-available config:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName <<sub.deineSeite.de>>
ServerAdmin <<info@deineSeite.de>>
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/<<sub.deineSeite.de>>.error.log
CustomLog ${APACHE_LOG_DIR}/<<sub.deineSeite.de>>.access.log combined
SSLCertificateFile /etc/letsencrypt/live/<<sub.deineSeite.de>>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<<sub.deineSeite.de>>/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
ProxyTimeout 60
ProxyErrorOverride On
ProxyPass / http://localhost:<<deinGhomePort>>/
ProxyPassReverse / http://localhost:<<deinGhomePort>>/
<Directory />
RedirectPermanent / /
</Directory>
</VirtualHost>
</IfModule>Voraussetzung dafür ist natürlich ein aktuelles ssl-Zertifikat. (LetsEncrypt z.B.)
4.) Den Port <<deinGHomePort>> in der GHome config.json eintragen.
Das wars eigentlich.
Bis denn
SouzA
So, vielen Dank für die Unterstützung. Habe es endlich mit einem TestDevice laufen... Allerdings nicht auf meinem Apache sondern erstmal auf einem Standalone System... Komme da irgendwie nicht so richtig weiter mit dem Reverse Proxy. Hatte es genauso konfiguriert wie beschrieben, wollte aber nicht so richtig :-( Ich bleib dran ...
Hallo nochmals... Ich bekomme es einfach nicht hin... Ich habe den Reverse Proxy für meine FHEM Instanz laufen mit folgender Konfiguration:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName meine.url.de
ServerAdmin abc@meine.url.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/meine.url.de.error.log
CustomLog ${APACHE_LOG_DIR}/meine.url.de.access.log combined
SSLCertificateFile /etc/letsencrypt/live/meine.url.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/meine.url.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
ProxyTimeout 60
ProxyErrorOverride On
<Location /fhem>
ProxyPass http://192.168.0.252:8086/fhem
ProxyPassReverse http://192.168.0.252:8086/fhem
AuthType Basic
AuthName "Password for FHEM Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Location>
<Location /api>
ProxyPass http://192.168.0.252:8085/fhem
ProxyPassReverse http://192.168.0.252:8085/fhem
AuthUserFile /etc/fhemapi-htpasswd
</Location>
<Directory />
RedirectPermanent / /fhem
</Directory>
<Proxy *>
AuthType Basic
AuthName "Password for FHEM Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Proxy>
</VirtualHost>
</IfModule>
Wie muss ich denn die KOnfiguration anpassen, damit ghome auch weitergeleitet wird.
Wenn ich ghome auf einem separaten Raspberry laufen habe ohne apache und direkte weiterleitung von port 443 auf den von ghome läuft alles wunderbar, aber ich würde das gerne hinter meinem apache laufen lassen...
Sorry, bin in den Angelegenheiten noch recht frisch hinter den Ohren und freue mich über jeglichen Input, der förderlich ist, solche Probleme auch mal selber gelöst zu bekommen...
Merci im Voraus :-)
Jan
Moin, ich bin z.Zt. einigermaßen aktiv z.Zt. am Code.
Ein Bug:
In handleControlSetTargetTemperature wird die humidity (sinnlos) abgefragt. Da MAX-Thermostate das nicht haben, fällt ghome-fhem da auf die Nase. Kann man einfach löschen.
Zitat von: jf.mennedy@gmail.com am 04 Dezember 2018, 20:50:48
Hallo nochmals... Ich bekomme es einfach nicht hin... Ich habe den Reverse Proxy für meine FHEM Instanz laufen mit folgender Konfiguration:
....
Wie muss ich denn die KOnfiguration anpassen, damit ghome auch weitergeleitet wird.
Wenn ich ghome auf einem separaten Raspberry laufen habe ohne apache und direkte weiterleitung von port 443 auf den von ghome läuft alles wunderbar, aber ich würde das gerne hinter meinem apache laufen lassen...
Sorry, bin in den Angelegenheiten noch recht frisch hinter den Ohren und freue mich über jeglichen Input, der förderlich ist, solche Probleme auch mal selber gelöst zu bekommen...
Merci im Voraus :-)
Jan
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
Zitat von: gvzdus am 04 Dezember 2018, 21:49:11
Moin, ich bin z.Zt. einigermaßen aktiv z.Zt. am Code.
Ein Bug:
In handleControlSetTargetTemperature wird die humidity (sinnlos) abgefragt. Da MAX-Thermostate das nicht haben, fällt ghome-fhem da auf die Nase. Kann man einfach löschen.
Hi,
wenn du von MAX-Thermostaten ausgehst vielleicht. Meine haben (noch) das Reading humidity.
Nachdem Dominik es fertig gebracht hatte Thermometer inkl. humidity in Google abzubilden, habe ich mich dennoch dazu entschlossen, die Readings in den Thermostaten zu belassen. Aus dem einfachen Grund, dass man nicht Unmengen an Devices in Google hat.
Je nach Installation sind das echt viel. Und wenn man dann doch nochmal 6 Thermometer sparen kann, warum nicht?
Also für mich ist das nicht sinnlos. Und ich denke, dass es noch andere Hersteller gibt, wo humidity ebenfalls vorhanden ist.
Bis denn
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".
Zitat von: SouzA am 04 Dezember 2018, 21:59:23
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
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 (https://forum.fhem.de/index.php/topic,74371.msg844822.html#msg844822) und die nächsten Seiten... Davor ging es auch schon um proxy...
Zitat von: gvzdus am 04 Dezember 2018, 22:07:39
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... ;D
Bis denn
SouzA
Zitat von: SouzA am 04 Dezember 2018, 22:38:56
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 (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.
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
Hier noch meine Konfiguration in Screenshots... Hoffe es hilft jemandem anderen weiter, wenn benötigt...
Zitat von: kadettilac89 am 05 Dezember 2018, 06:12:00
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
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.
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.
@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:
- 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.
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:
https://<user>:<password>@<domain>/oauth
https://<user>:<password>@<domain>/tokenIch 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:
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.
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
Zitat von: kadettilac89 am 07 Dezember 2018, 17:52:41
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
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.
Zitat von: habl am 07 Dezember 2018, 19:34:24
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.
Zitat von: vbs am 07 Dezember 2018, 20:02:45
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.
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?
Zitat von: X-Byte am 08 Dezember 2018, 01:48:52
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?
Zitat von: kadettilac89 am 07 Dezember 2018, 21:18:20
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
Zitat von: habl am 08 Dezember 2018, 09:06:12
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
Zitat von: X-Byte am 08 Dezember 2018, 01:48:52
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?
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.
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 :(
Zitat von: kadettilac89 am 07 Dezember 2018, 21:18:20
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.
Zitat von: vbs am 08 Dezember 2018, 13:43:05
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.
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 :o 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.
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?
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.
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.
@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?
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.
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
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:
"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 "-".
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.
Zitat von: gvzdus am 09 Dezember 2018, 07:47:14
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.
Zitat von: dominik am 09 Dezember 2018, 10:22:09
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.
Zitat von: gvzdus am 09 Dezember 2018, 07:47:14
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:
"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.
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
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" :-)
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
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}
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.
Zitat von: dominik am 09 Dezember 2018, 16:14:19
3. Dein Dummy hat keine setList mit on/off, das ist wahrscheinlich der Grund wieso es nicht funktioniert.
Vielen Dank. Das war der Grund.
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:
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:
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
@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?
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
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?
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.
Von was redet der?
Soll das bedeuten, dass keine eigenen Actions mehr nötig wären?
Bin mal gespannt....
Bis denn
SouzA
Ja, das habe ich vergessen zu schreiben 8)
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.
Goil!
Du bist der Beste! 8) ;D
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.
Danke dominik, klingt gut! Verstehe ich dann auch als indirekte Antwort auf meine Frage bzgl. Sicherheit 8)
Hab mir jetzt dafür was gebastelt, was ich für einigermaßen sicher halte (zumindest bis jemand Einwände hat): Per iptables-Firewall nur Verbindung von Google-IPs auf den Port von ghome-fhem zulassen. Alles andere wird verworfen. Die IPs werden stündlich frisch aus dem TXT-Feld des Google-DNS-Eintrags geholt.
Falls das jemand nachnutzen möchte:
- Script downloaden (z.B. nach /opt/google_iprange_update):
https://gist.github.com/verybadsoldier/fc84f9e6dca241c95681fa97ec81f50d
- im Script die Zeile für euren Port anpassen:
port="7654"
- Namen der iptables-Regeln o.ä. können natürlich nach Belieben verändert werden
- per cron regelmäßig aufrufen (z.B. stündlich in cron.hourly)
ln -s /opt/google_iprange_update/google_iprange_update.sh /etc/cron.hourly/
Das Script legt die Liste der IPv4-Adressen als ipset an. Es sind dann nur noch Verbindungen auf den o.g. Port von diesen IPs aus erlaubt.
Prüfen:
- "ipset list google-ips" sollte Liste der Google IPs zeigen (Script muss einmal gelaufen sein)
- Ausgabe von "iptables -L nginx-google-whitelist"sollte so aussehen:
Chain nginx-google-whitelist (0 references)
target prot opt source destination
DROP all -- anywhere anywhere ! match-set google-ips src
Nachteile:
- Ohne weitere Maßnahmen ist das ipset nur im RAM und nach dem Booten erstmal leer. Also nach einem Reboot ist der Schutz dann erst zur nächsten vollen Stunde (bei cron.hourly)
- Für den initialen Login per App muss der Schutz kurzzeitig deaktiviert werden. Dafür muss dann kurzzeitig dir Funktion deaktiviert werden mit z.B.
ipset add google-ips 0.0.0.0/1
Danach Script starten, um Filter wieder zu aktiveren (oder vollte Stunde abwarten).
Hallo,
ich konnte dann doch nicht mehr warten und habe google home Gestern Abend noch zum Laufen gebracht :D
Ich bin aber von Google etwas enttäuscht, da die Geräte irgendwie nicht richtig erkannt werden, bzw. die Integration in meinem Augen irgendwie komisch ist.
Hier meine Beispiele/Probleme:
1. Rolladenaktor von Homematic wird bei mir als Lampe erkannt. Ich kann die Rolladen dann auch nur Steuern in dem ich sage "setze Rolladen auf 100%". "Mache Rolladen auf", funktioniert hingegen nicht. Den GenericDeviceType habe ich auf "blind" gesetzt. Das ist doch so richtig, oder? Die Rückmeldung von Google lautet dann zu allem Überfluss " Die Lampe Rollo ist auf 100% gesetzt".
2. Ich habe Temp/humidity Sensoren von HM. Diese werden trotz gesetztem GenericDeviceType "thermometer" meiner Meinung nach als Thermostat von Google interpretiert. Wenn ich frage "wie warm es im Wohnzimmer ist" bekomme ich als Antwort "Es sind 22 grad und das Thermostat Wohnzimmer ist aus".
3. Ich habe einen Mi-RBG controler, der aber nur als normale Lampe erkannt wird. Farbwerte kann ich nicht setzen. Google nimmt den Befehl zwar an es passiert aber nichts.
4. Mein Xiaomi Vacuum Robot wird auch erkannt, aber wenn ich Ihn mit "Starte den Staubsauger" losschicken will antwortet mir Google "Ich bin nicht sicher welches Gerät du mit Staubsauger meinst"
Erwarte ich hier von Google einfach zu viel, oder mache ich irgendetwas prinzipielles falsch?
Ich hoffe die Fragen sind hier an dieser Stelle richtig.
Ansonsten noch einen schönen dritten Advent :)
Hi,
einen Zeitpunkt wann ich mit der Entwicklung fertig bin, wage ich noch nicht zu nennen. Aktuell, wie gesagt, alles Proof of Concept. Daher schon mal gut, dass du mit der Anleitung begonnen hast :)
Zu deinen Fragen:
1. Ist korrekt, leider hat Google noch keinen Typ Rollo/blind, daher wird der Umweg ueber die Lampe gemacht
2. Auch korrekt, leider hat Google noch keinen Typ TempSensor, daher wird der Umweg ueber das Thermostat gemacht
3. Kannst du mir zu den Device ein paar Infos posten? Internals, Readings, Attribute und die Commands. RGB, HSV und ColorTemperature sollte funktionieren und tut auch bei einigen hier im Thread inkl. mir.
4. Wird dein Xiaomi Vacuum auch als Vacuum erkannt? In der App taucht er dann mit so einem komischen Symbol auf ohne Aus/An (leider liegt das auch an Google). Ich habe den gleichen und da funktioniert "Starte den Staubsauger". Oder hast du mehrere?
Alexa unterstuetzt aktuell noch mehr Device Typen. Mein Grund auf Google zu wechseln war jedoch die Spracherkennung. Meinen Staubsauger mit den Namen "Wall-E" konnte Alexa naemlich nie starten, Google kann es :)
Gruss
Dominik
Hallo,
zu 1 und 2. Schade, dann schauen wir mal wann Google das kann. Ich hatte gehofft da geht schon mehr
zu 3. Internals:
CONNECTION bridge-V3
DEF RGBW2 bridge-V3:192.168.178.28
IP 192.168.178.28
LEDTYPE RGBW2
NAME LED_Kueche
NR 524
NTFY_ORDER 50-LED_Kueche
PORT 8899
PROTO 0
SLOT 5
STATE off
TYPE WifiLight
READINGS:
2018-12-16 08:10:23 RGB 000000
2018-12-16 08:10:23 brightness 0
2018-12-16 08:10:23 hue 0
2018-12-16 08:10:23 saturation 0
2018-12-16 08:10:23 state off
helper:
COMMANDSET on off dim dimup dimdown HSV RGB sync pair unpair
colorLevel 0
colorValue -1
llLock 0
mode 0
targetHue 0
targetSat 0
targetTime 1544944223.42615
targetVal 25
whiteLevel 0
COLORMAP:
168
167
167
166
166
165
165
164
163
163
162
162
161
161
160
159
159
158
158
157
157
156
156
155
154
154
153
153
152
152
151
150
150
149
149
148
148
147
146
146
145
145
144
144
143
142
142
141
141
140
140
139
139
138
137
137
136
136
135
135
134
133
132
132
131
130
129
129
128
127
126
126
125
124
123
122
122
121
120
119
119
118
117
116
116
115
114
113
113
112
111
110
109
109
108
107
106
106
105
104
103
103
102
101
100
99
99
98
97
96
96
95
94
93
93
92
91
90
90
89
88
87
87
86
86
85
85
84
84
83
83
82
82
81
81
80
79
79
78
78
77
77
76
76
75
75
74
74
73
73
72
71
71
70
70
69
69
68
68
67
67
66
66
65
65
64
63
63
62
62
61
61
60
60
59
59
58
58
57
57
56
55
54
54
53
52
51
50
50
49
48
47
46
46
45
44
43
42
42
41
40
39
38
38
37
36
35
34
34
33
32
31
30
30
29
28
27
26
26
25
24
23
22
22
21
20
19
18
18
17
16
15
14
14
13
12
11
10
10
9
9
8
7
6
5
4
3
2
2
1
0
254
253
252
251
250
249
248
247
246
245
244
243
243
242
241
240
239
238
237
236
235
234
233
232
231
230
229
229
228
227
226
225
224
223
222
221
220
219
218
217
216
215
215
214
213
212
211
210
209
208
207
207
206
205
205
204
203
203
202
201
201
200
199
199
198
197
197
196
195
195
194
193
193
192
191
191
190
189
189
188
187
187
186
185
185
184
183
183
182
181
181
180
179
179
178
177
177
176
175
175
174
173
173
172
171
171
170
169
169
GAMMAMAP:
0
0.182084917038383
0.470591230357907
0.820096073367633
1.21622432924022
1.65107624587364
2.11950570346478
2.61783651126499
3.14328343499055
3.69364788963403
4.26714092851856
4.86227250061747
5.47777824197178
6.112568939676
6.76569440648595
7.43631690144944
8.12369109476553
8.82714865073238
9.54608615125084
10.2799554881179
11.0282561143647
11.7905287188301
12.566350006457
13.3553283490082
14.1571001291331
14.971326642687
15.7976914549342
16.6358981290745
17.4856682626968
18.3467397808198
19.2188654442296
20.1018115396355
20.9953567242883
21.899291002556
22.8134148158172
23.7375382301393
24.6714802087245
25.615067958155
26.5681363391464
27.5305273339062
28.5020895633382
29.4826778482926
30.4721528098611
31.470380504392
32.4772320894657
33.4925835175601
34.5163152545402
35.5483120204638
36.5884625504948
37.6366593739748
38.6927986099313
39.7567797774927
40.8285056198529
41.9078819405719
42.994817451133
44.0892236287856
45.1910145838062
46.3001069353943
47.4164196955005
48.5398741599513
49.6703938062953
50.8079041978503
51.9523328934805
53.1036093626722
54.2616649055192
55.4264325772608
56.5978471170475
57.7758448806357
58.9603637767409
60.1513432067978
61.3487240079
62.5524483987055
63.7624599281173
64.9787034265577
66.2011249596724
67.429671784312
68.6642923066494
69.9049360423029
71.1515535783445
72.4040965370806
73.6625175415008
74.9267701822992
76.1968089863762
77.4725893867394
78.7540676937228
80.0412010674534
81.3339474914964
82.6322657476148
83.9361153915856
85.2454567300145
86.5602507980997
87.8804593382937
89.2060447798182
90.5369702189896
91.8731994003132
93.21469669831
94.5614271000383
95.9133561882787
97.2704501253487
98.6326756375187
100
hlCmdQueue:
llCmdQueue:
Attributes:
genericDeviceType light
group Licht
room GoogleHome,Küche
webCmd on:off
zu 4.: ok, ich hatte Ihn 2x mal in meiner App (1x fhem, 1x MiHome) daher wohl die Frage von Google. Funktionieren tut es aber trotzdem noch nicht richtig. Das einzige was funktioniert ist, das ich fragen kann wo der Staubsauger ist. Dann bekomme ich eine Antwort von Ihm. Start/ Stop funktioniert nicht. Google sagt zwar dass das Gerät gestartet wird, aber es tut sich nichts. Kann man irgendwie rausbekommen was Google für commands sendet und was Fhem empfängt?
Zu 1 stellt sich mir noch die Frage ob es dann momentan nicht noch besser ist Google über IFTTT und talk2Fhem zu realisieren. Da kann man ja dann die Antworten und Aktionen konfigurieren wie man möchte. Es ist aber leider auch viel aufwändiger. Ich habe mir das zwar noch nicht komplett durchgelesen, aber so hatte ich es zumindest verstanden.
Danke und Gruß
1,2) Andere Services (IFTTT) kamen bei mir nicht in Frage, das hat 2 Gruende:
- Ich moechte die nativen Services (SmartHome Action) nutzen und erwarte durch Google eine Weiterentwicklung
- Ich moechte kein "Hey Google, sprich mit James, ..." sagen.
3) Schau ich mir noch an. Wobei WifiLight haben hier schon paar in Verwendung meines Wissens.
4) Poste mal ein das Log (journalctl -u ghome.service) wenn der Staubsauger nicht das tut was du erwartest. Folgendes sollte gehen und ist bei mir getestet:
Wo ist der Staubsauger?
Suche den Staubsauger?
Start den Staubsauger.
Pausiere den Staubsauger.
Schalte den Staubsauger ein.
Modes habe ich fuer den cleaning_mode konfiguriert, jedoch funktionieren diese noch nicht auf Deutsch.
Btw, die Aktionen in der Google Home App kann man schoen konfigurieren, wenn man was anderes sagen moechte. Ich habe bei mir zum Beispiel "Hey Google, guten Morgen Google" konfiguriert um ein Device zu schalten.
Zitat von: dominik am 16 Dezember 2018, 18:23:31
Btw, die Aktionen in der Google Home App kann man schoen konfigurieren, wenn man was anderes sagen moechte. Ich habe bei mir zum Beispiel "Hey Google, guten Morgen Google" konfiguriert um ein Device zu schalten.
Hi, da nutze ich einen "wilden" Mix aus Abläufen, LightScenes und direkter Device Schaltung.
Wobei ich es gut finde, dass die Szenen nicht alle in den Räumen in der Übersicht angezeigt werden aber trotzdem direkt angesprochen werden können. So kann man schön viele basteln ohne, dass es unübersichtlich wird.
Weihnachtsbeleuchtung_Ein und Weihnachtsbeleuchtung_Aus sind Szenen bei mir. Ohne Device nen Haufen Geräte schalten rockt! :D ;D
Daran, dass die Rolläden Lampen sind habe ich mich auch gewöhnt. Mann muss sich halt "schalte alle Lampen an/aus" verkneifen.
Eigentlich gibt es imom nichts, was ich mit Google nicht steuern könnte, was ich nicht auch steuern wollen würde.
Bis denn
SouzA
Hallo,
Danke an Euch erst mal für die Antworten. Heißt das ich kann mir eigene Befehle konfigurieren die dann beliebige Devices Schalten? Die Devices müssen aber unterstützt werden, oder? Meinen Worx Rasenmähoboter könnte ich dann vermutlich nur über einen Dummy steuern, oder? Kann man auch eigene Antwortsätze konfigurieren?
Das Logfile schicke ich heute Abend. Bin momentan unterwegs.
Danke und einen schönen Tag
Gesendet von meinem VTR-L09 mit Tapatalk
Hallo,
Danke erst einmal für die tolle Anleitung.
Habe jetzt schon zum vierten Mal alles neu installiert. Wenn ich dann den Dienst manuell starte bekomme ich immer folgende Fehlermeldung:
[2018-12-18 12:59:49] using /home/pi/.ghome/config.json
[2018-12-18 12:59:49] ---
[2018-12-18 12:59:49] this is ghome-fhem 0.4.0
_tls_common.js:88
c.context.setCert(options.cert);
^
Error: error:0906D06C:PEM routines:PEM_read_bio:no start line
at Object.createSecureContext (_tls_common.js:88:17)
at Server (_tls_wrap.js:819:25)
at new Server (https.js:60:14)
at Object.createServer (https.js:80:10)
at Server.startServer (/home/pi/ghome-fhem/lib/server.js:135:40)
at Server.run (/home/pi/ghome-fhem/lib/server.js:256:10)
at module.exports (/home/pi/ghome-fhem/lib/cli.js:30:10)
at Object.<anonymous> (/home/pi/ghome-fhem/bin/ghome:17:22)
at Module._compile (module.js:653:30)
at Object.Module._extensions..js (module.js:664:10)
so sieht meine action.json aus:
{
"actions": [
{
"name": "actions.devices",
"deviceControl": {
},
"fulfillment": {
"conversationName": "automation"
}
}
],
"conversations": {
"automation": {
"name": "automation",
"url": "https://meinedomain.ddnss.de"
}
},
"locale": "de"
}
und meine config.json:
{
"ghome": {
"port": 3001,
"name": "Google Home",
"ssl": true,
"keyFile": "/home/pi/.ghome/key.pem",
"certFile": "/home/pi/.ghome/cert.pem",
"oauthClientId": "NRRjsdufIOIU4LI4JXSvrUfS4enB6j64klj4nn46cOsTi26GZOEtr2M9LNC6",
"oauthClientSecret": "LHiLSBuPqeIZUZ3GQEvrAh5UjMPOIsJvue229d4jP25dIjOZ0",
"oauthUsers": {
"TZhziuz": {
"password": "ebEbQ5W3IfxX3EBKHKHjjU4TOPiPHFj6DB3xhHJHgr2eAKHdG",
"authtoken": "bQBVq3JHKJHvRCkyyS5mm5uGOAHuQd9kJLKJJCWRwhcJSQnXAz"
}
}
},
"connections": [
{
"name": "FHEM",
"server": "meine IP",
"port": "8083",
"webname": "fhem",
"auth": {"user": "myuser", "pass": "mypass"},
"ssl": true,
"filter": "room=GoogleHome"
}
]
}
leider habe ich schon alles mögliche probiert, leider ohne Erfolg.
(z.B Port mit angegeben)
Hat noch jemand eine Idee
Gruß rippi
PS: die Passwörter und User in den beiden Dateien sind nicht die "echten" Werte
Idee:
1) hat der User unter dem Ghome läuft (pi?) leserecht auf die Zertifikate?
2) hast du die Certifikate (den Text darin) kopiert und neu abgespeichert? Fehler deutet auf falsches Format oder ungültige Zeichen hin ... https://stackoverflow.com/questions/20837161/openssl-pem-routinespem-read-biono-start-linepem-lib-c703expecting-truste
Hast du die Zertifikate für einen anderen Webserver im Einsatz, funktionieren die damit?
Hallo kadettilac89,
Habe die Certifikate mit
sudo certbot certonly --standalone --agree-tos
erzeugt.
Ist das nicht in Ordnung?
Und mit
cd $HOME/.ghome
sudo cp /etc/letsencrypt/live/<change_me___domain>/privkey.pem $HOME/.ghome/key.pem
sudo cp /etc/letsencrypt/live/<change_me___domain/fullchain.pem $HOME/.ghome/cert.pem
sudo chown pi *.pem
ins entsprechende Verzeichnis kopiert.
damit kann sie der User pi lesen.
Gruß rippi
sieht eigentlich gut aus, ich glaub das sind genau die schritte aus der anleigtung. certbot habe ich auch im einsatz und das läuft.
der fehlermeldung nach passt irgend was mit den zertifikaten nicht. schau dir mal mit
nano $HOME/.ghome/key.pem
nano $HOME/.ghome/cert.pem
an was in den zertifikaten steht. ggf. sind die dateien leer. wie sehen die dateien aus, kannst hier mal posten ... die zeichenfolgen aus-x-en, nur um zu sehen, dass das format passt.
Hallo kadettilac89,
Asche auf mein Haupt!!!
Wenn man natürlich 2-mal das gleiche Zertifikat ins Verzeichnis kopiert kann es nicht funktionieren.
Jetzt funktioniert alles.
PS: Müsste man nicht in der Anleitung noch den Port bei der Domain hinzufügen, sonst landet man immer auf der Fritzbox oder Router?
Gruß rippi
Zitat von: rippi46 am 18 Dezember 2018, 19:55:56
PS: Müsste man nicht in der Anleitung noch den Port bei der Domain hinzufügen, sonst landet man immer auf der Fritzbox oder Router?
Gruß rippi
wo genau, poste mal den text der anleitung den du meinst. wenn port 443 -> defaul für https, kann man weglassen, ansonsten hast du recht.
edit: meinst du den teil hier?
Port 443 (extern) auf 3000 (intern, auf Raspberry oder Server) weiterleiten. Auch das muss wieder am Router gemacht werden. Hier ist zu beachten, dass sich externer und interner Port unterscheidet.
--> in der Anleitung wird von Port 443 ausgegangen. Wenn abweichend davon musst du Port überall mit :<port> mit angeben.
Hatte es so gemacht wie in der Anleitung und bin dann immer auf der Fritzbox gelandet.
Nachdem ich dann den Port mit angegeben habe hatte es funktioniert.
Gruß rippi
Hey Dominik,
was genau soll ich dir den aus dem journalctl -u ghome.service posten. Das File ist ja endlos ::)
Gruß
Zitat von: FEHMPiDi am 18 Dezember 2018, 08:43:24
Hallo,
Danke an Euch erst mal für die Antworten. Heißt das ich kann mir eigene Befehle konfigurieren die dann beliebige Devices Schalten? Die Devices müssen aber unterstützt werden, oder? Meinen Worx Rasenmähoboter könnte ich dann vermutlich nur über einen Dummy steuern, oder? Kann man auch eigene Antwortsätze konfigurieren?
Das Logfile schicke ich heute Abend. Bin momentan unterwegs.
Danke und einen schönen Tag
Gesendet von meinem VTR-L09 mit Tapatalk
Hi,
du kannst Abläufe in Google konfigurieren. In diesen Abläufen kannst du Devices oder Szenen ansteuern.
Devices, die Google bekannt sind, kannst du natürlich auch direkt schalten.
Über die LightScene in FHEM kannst du auch Devices schalten oder in Abläufe einbinden, die mit Google nicht direkt steuerbar wären (oder halt über Dummy).
Bis denn
SouzA
Hallo,
anbei jetzt mal ein Auszug vom
Das passiert wenn ich Google bitte den Staubsauger zu starten:
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: **** User: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: **** Received Directive: {"inputs":[{"context":{"locale_language":"de"},"intent":"action.devices.EXECUTE","payloa
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: cmd: [object Object]
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: {"devices":[{"customData":{"device":"Pucky"},"id":"Pucky"}],"execution":[{"command":"action.devices.commands.Star
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: [12/19/2018, 8:10:30 PM] [FHEM] mapping: {"reading":"state","cmdPause":"pause","cmdUnpause":"on","cmdOn":"on","cm
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: [12/19/2018, 8:10:30 PM] [FHEM] Pucky: executing set cmd for StartStop with value 1
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: [12/19/2018, 8:10:30 PM] [FHEM] executing: http://xxx.xxx.xxx.xx:8083/fhem?cmd=set%20Pucky%20on&fwcsrf=pnKcqHbd
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: response :{"requestId":"XXXXXXXXXXXXXXXXXXXXXX","payload":{"commands":[{"states":{"isRunning":1},"status":"success",
Dec 19 20:10:30 raspberrypi_HWR ghome[550]: POST / 200 8.169 ms - -
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: **** User: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: **** Received Directive: {"inputs":[{"intent":"action.devices.QUERY","payload":{"devices":[{"customData":{"device
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: **** QUERY: "Pucky"
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: **** Error: {}
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: response :{"requestId":"XXXXXXXXXXXXXXXXXXXXXXX","payload":null}
Dec 19 20:10:31 raspberrypi_HWR ghome[550]: POST / 200 5.525 ms - -
Bei umschalten der Lichtfarbe passiert folgendes:
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: **** User: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: **** Received Directive: {"inputs":[{"context":{"locale_language":"de"},"intent":"action.devices.EXECUTE","payloa
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] mapping: {"reading":"hue","cmd":"HSV","max":359,"maxValue":359,"device":"LED_Kuec
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] LED_Kueche: executing set cmd for Hue with value 120
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] value converted to 120,0,37
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] executing: http://xxx.xxx.xxx.xx:8083/fhem?cmd=set%20LED_Kueche%20HSV%20120,0,3
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] mapping: {"reading":"brightness","cmd":"HSV","max":100,"maxValue":1,"delay":true,
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] LED_Kueche: executing set cmd for HSVBrightness with value 1
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] value converted to 120,0,37
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] executing: http://xxx.xxx.xxx.xx:8083/fhem?cmd=set%20LED_Kueche%20HSV%20120,0,3
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] mapping: {"reading":"saturation","cmd":"HSV","max":100,"maxValue":1,"device":"LED
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] LED_Kueche: executing set cmd for Saturation with value 1
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] value converted to 120,1,37
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:12 PM] [FHEM] executing: http://xxx.xxx.xxx.xx:8083/fhem?cmd=set%20LED_Kueche%20HSV%20120,1,3
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: response :{"requestId":"XXXXXXXXXXXXXXXX","payload":{"commands":[{"states":{"color":{"spectrumHsv":{"hue":120
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: POST / 200 15.273 ms - -
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: 2018-12-19 20:18:12 caching: LED_Kueche-hue: 120
Dec 19 20:18:12 raspberrypi_HWR ghome[550]: 2018-12-19 20:18:12 caching: LED_Kueche-saturation: 0
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: **** User: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: **** Received Directive: {"inputs":[{"intent":"action.devices.QUERY","payload":{"devices":[{"customData":{"device
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: **** QUERY: "LED_Kueche"
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] caching: On: true (as boolean; from 'on')
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] LED_Kueche-brightness empty format
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] caching: Brightness: 37 (as number; from '37')
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: **** QUERY: "LED_Kueche"
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] caching: On: true (as boolean; from 'on')
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] LED_Kueche-brightness empty format
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: [12/19/2018, 8:18:13 PM] [FHEM] caching: Brightness: 37 (as number; from '37')
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: response :{"requestId":"XXXXXXXXXXXXXXXX","payload":{"devices":{"LED_Kueche":{"online":true,"on":true,"bright
Dec 19 20:18:13 raspberrypi_HWR ghome[550]: POST / 200 12.784 ms - -
Bei Staubsauger fällt mir auf das im Commando das gesendet wird "on" und nicht "start" gesendet wird. Muss ich irgendwo die Sprache umstellen?
Hi,
kurze Frage:
Ist es normal, dass ghome "crasht" wenn man nen FHEM shutdown restart macht? In ner alten Version war das nicht der Fall, aber jetzt bekomme ich nach nem FHEM Neustart:
018-12-22 10:33:53] [FHEM] longpoll ended, reconnect in: 200msec
[2018-12-22 10:33:53] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1545471179.082;fmt=JSON×tamp=1545471233758
[2018-12-22 10:33:53] [FHEM] longpoll error: Error: connect ECONNREFUSED 127.0.0.1:8083, retry in: 10000msec
[2018-12-22 10:34:03] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1545471179.082;fmt=JSON×tamp=1545471243775
[2018-12-22 10:34:03] [FHEM] Checking devices and attributes...
[2018-12-22 10:34:03] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22,%22userattr%22,%22%22)%7D&XHR=1
[2018-12-22 10:34:03] [FHEM] Fetching FHEM devices...
[2018-12-22 10:34:03] [FHEM] fetching: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20room=ghome&XHR=1
[2018-12-22 10:34:04] [FHEM] got: 11 results
[2018-12-22 10:34:04] [FHEM] Amazon is already published
[2018-12-22 10:34:04] [FHEM] Chaos_PC is already published
[2018-12-22 10:34:04] [FHEM] GaragenTor is already published
[2018-12-22 10:34:04] [FHEM] HM_Weihnachtsbaum is already published
[2018-12-22 10:34:04] [FHEM] Karen_PC is already published
[2018-12-22 10:34:04] [FHEM] Netflix is already published
[2018-12-22 10:34:04] [FHEM] Plex is already published
[2018-12-22 10:34:04] [FHEM] TV is already published
[2018-12-22 10:34:04] [FHEM] Zocken is already published
[2018-12-22 10:34:04] [FHEM] goodmorning is already published
[2018-12-22 10:34:04] [FHEM] goodnight is already published
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
/opt/ghome-fhem/lib/server.js:220
device.ghomeName = device.ghomeName.replace(/\+/g, ' ');
^
TypeError: Cannot read property 'replace' of undefined
at Server.addDevice (/opt/ghome-fhem/lib/server.js:220:40)
at Server.<anonymous> (/opt/ghome-fhem/lib/server.js:314:26)
at FHEM.<anonymous> (/opt/ghome-fhem/lib/fhem.js:794:21)
at Request.self.callback (/opt/ghome-fhem/node_modules/request/request.js:185:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:194:7)
at Request.<anonymous> (/opt/ghome-fhem/node_modules/request/request.js:1161:10)
at emitOne (events.js:96:13)
at Request.emit (events.js:191:7)
at Gunzip.<anonymous> (/opt/ghome-fhem/node_modules/request/request.js:1083:12)
Neustart von Ghome löst das Problem dann.
MfG
Manuel
Guten Abend,
hätte evtl. jemand eine Idee wieso mein Staubsaugroboter nicht gestartet wird und die Lichtfarbe nicht geändert wird?
Ich komme dem Problem nicht auf die Spur.
Auszug aus dem Log ist in meinem letzten Beitrag.
Danke
Hi,
Siehst du die Devices in der App?
Anscheinend hast du noch nen paar nicht zugeordnete Devices in fhem und ghome kann damit nichts anfangen.
Versuch mal den Ordner "unsorted" aufzuräumen.
Bis denn
SouzA
Hi,
Ich wollte heute mal wieder einen Reconnect in der App machen. Massiv viele Szenen doppelt usw...
Allerdings wird mir nach dem Trennen ghome gar nicht mehr in der App angezeigt. Nicht mehr da. Nix mehr einbinden.
Hat jemand gleiches oder ähnliches Problem?
Bis denn
SouzA
Edit:
Anscheinend wurde von Google was geändert.
Es muss für die Aktivierung des Tests in Google - Actions nun zwingend zusätzlich die Englische Sprache ausgewählt sein.
Dann wird die Action in der App angezeigt. Allerdings nicht mehr unter dem Namen wie in Actions benannt, sondern als "[test] my test app".
Weihnachten doch noch gerettet...
Bis denn
SouzA
Bald bin ich hoffentlich mit dem offiziellen Action fertig. Muss noch paar Details implementieren und dann kann ich das Projekt für erste Tests freigeben.
Grundsätzlich funktioniert schon alles was ich an Devices testen kann :)
Eine erste Testversion (nicht final und nicht für den dauerhaften Betrieb!!) des Actions könnte ich zum Testen für ein paar User anbieten. Ich möchte damit schnell ein erstes Feedback bekommen.
Bei Interesse bitte eine kurze PN mit eurer gmail Adresse.
Ich hätte eine Frage zu der Lebensdauer der (Draft-)Actions: laut FAQ müssen nicht veröffentlichte Actions alle drei Tage "erneuert" werden (was immer das heißt), ansonsten sind sie nicht mehr zu erreichen. Macht ihr das? Wenn ja, wie (gactions update...)? Oder habt ihr festgestellt, dass das nicht notwendig ist?
Das hatte ich auch gelesen, bislang sind meine Testactions aber noch nie deaktiviert worden.
Hi! Erstmal ganz großen Dank hierfür.
Ich bin nun an dem Punkt angelangt, dass ich in der Google Home App "[test] FHEM Connector" hinzufügen möchte. Es erscheint auch ein "Accounts now linked", nachdem ich Username und PW eingegeben und auf "Login" geklickt habe. Allerdings erhalte ich dann die Meldung, dass die "Einstellungen nicht aktualisiert werden konnten" und dass ich "meine Verbindung überprüfen" soll. Habe das ganze jetzt schon mehrfach probiert und erhalte immer die gleiche Meldung. Hatte das auch schonmal jemand?
Beste Grüße
-triagony
Zitat von: triagony am 30 Dezember 2018, 18:48:36
Hi! Erstmal ganz großen Dank hierfür.
Ich bin nun an dem Punkt angelangt, dass ich in der Google Home App "[test] FHEM Connector" hinzufügen möchte. Es erscheint auch ein "Accounts now linked", nachdem ich Username und PW eingegeben und auf "Login" geklickt habe. Allerdings erhalte ich dann die Meldung, dass die "Einstellungen nicht aktualisiert werden konnten" und dass ich "meine Verbindung überprüfen" soll. Habe das ganze jetzt schon mehrfach probiert und erhalte immer die gleiche Meldung. Hatte das auch schonmal jemand?
Beste Grüße
-triagony
deine domain von außen erreichbar? zertifikat gültig?
links s. post ....
https://forum.fhem.de/index.php/topic,93814.msg869222/topicseen.html#msg869222
ZitatHi,
Siehst du die Devices in der App?
Anscheinend hast du noch nen paar nicht zugeordnete Devices in fhem und ghome kann damit nichts anfangen.
Versuch mal den Ordner "unsorted" aufzuräumen.
Bis denn
SouzA
Hi SouzA,
ich verstehe jetzt zwar Deine Antwort nicht ganz, aber ich räume trotzdem mal auf und melde mich dann wieder. Kann ja nichts schaden :)
Aber könntest Du mir sagen woran Du erkennst das ghome Probleme mit nicht zugeordneten Devices hat. Wo erkennst Du das in den beiden Logs?
Danke
Zitat von: kadettilac89 am 30 Dezember 2018, 19:36:33
deine domain von außen erreichbar? zertifikat gültig?
links s. post ....
https://forum.fhem.de/index.php/topic,93814.msg869222/topicseen.html#msg869222
Hey, ja, ist alles erreichbar. Sonst hätte das ganze wohl m.E. schon wesentlich früher abgebrochen als im allerletzten Schritt während der Einrichtung in der GHome-App. Trotzdem danke für deinen Lösungsansatz. :)
Zitat von: FEHMPiDi am 30 Dezember 2018, 20:58:13
Hi SouzA,
ich verstehe jetzt zwar Deine Antwort nicht ganz, aber ich räume trotzdem mal auf und melde mich dann wieder. Kann ja nichts schaden :)
Aber könntest Du mir sagen woran Du erkennst das ghome Probleme mit nicht zugeordneten Devices hat. Wo erkennst Du das in den beiden Logs?
Danke
Gar nicht, das war aus dem log von chaos... ;D
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
/opt/ghome-fhem/lib/server.js:220
device.ghomeName = device.ghomeName.replace(/\+/g, ' ');
^
TypeError: Cannot read property 'replace' of undefined
Achso,
Hat vielleicht jemand eine Idee wie ich bei mir weiter kommen kann? Ich versteh immer noch nicht wieso mein Staubsauger nicht startet. Ich vermute das Problem liegt daran das Ghome das Kommando on verwendet, der Staubsauger aber das Kommando Start erwartet.
Bei dem rbg Mi-light habe ich keine Idee woran es liegen kann.
Danke und guten Rutsch
Gesendet von meinem VTR-L09 mit Tapatalk
Hi,
Ich glaube, dein Schlagwort für den Staubsauger ist Homebridgemapping.
Für Alexa und Siri gibt es dafür Beispiele.
Allerdings weiß ich nicht 100%tig, ob die auch komplett von ghome unterstützt werden. Dominik arbeitet ja darauf hin, dass keine Mappings verwendet werden müssen.
Ich weiß zZ nicht woraus ghome die Möglichkeiten des Devices zieht. Ggf vll noch aus der setlist...
Einen Versuch ist es dennoch wert. Ich kann mich entsinnen, mit dem Mapping auch schon gespielt zu haben.
Bis denn
SouzA
Anbei mal eine Definition von einem RGB-Device von mir.
Dies lässt sich per Sprache an/aus/dim/farbe steuern.
defmod ku_LED_auf_Schrank_color HUEDevice 6 IODev=HUEBridge
attr ku_LED_auf_Schrank_color userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr ku_LED_auf_Schrank_color IODev HUEBridge
attr ku_LED_auf_Schrank_color alias Schrankbeleuchtung Farbe
attr ku_LED_auf_Schrank_color color-icons 2
attr ku_LED_auf_Schrank_color devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr ku_LED_auf_Schrank_color group Beleuchtung Wozi/Küche
attr ku_LED_auf_Schrank_color icon light_led_stripe_rgb
attr ku_LED_auf_Schrank_color model FLS-PP3
attr ku_LED_auf_Schrank_color realRoom Küche
attr ku_LED_auf_Schrank_color room GoogleHome,HUEBridge,Küche
attr ku_LED_auf_Schrank_color subType extcolordimmer
attr ku_LED_auf_Schrank_color webCmd rgb:rgb ff0000:rgb DEFF26:rgb 0000ff:ct 490:ct 380:ct 270:ct 160:toggle:on:off
Hi,
Zitat von: SouzA am 31 Dezember 2018, 00:53:23
Gar nicht, das war aus dem log von chaos... ;D
[2018-12-22 10:34:04] [FHEM] Please add undefined to a room in FHEM.
/opt/ghome-fhem/lib/server.js:220
device.ghomeName = device.ghomeName.replace(/\+/g, ' ');
^
TypeError: Cannot read property 'replace' of undefined
mir war auch nicht klar, dass das ne Antwort auf meine Frage war :-D
Unsorted hab ich nicht und ein Device namens undefined auch nicht ;-)
ghome läuft wunderbar, einzig nach nem "shutdown restart" vom fhem muss ich manuell den ghome Dienst neustarten, da er den o.g. Fehler bringt und nicht mehr funktioniert.
MfG
Manuel
Der Xiaomi Vacuum benötigt keine homebridgeMappings und auch keinen genericDeviceType. Das wird automatisch erkannt.
Bitte generell immer zuerst OHNE homebridgeMapping und genericDeviceType die Geräte testen. Erst wenn dann nichts geht, könnt ihr beides einrichten. Wenn es danach läuft, gebt mir bitte Bescheid, dann baue ich das im Code ein damit weitere User kein Einstellungen mehr treffen müssen.
Zitat von: Chaos am 31 Dezember 2018, 11:41:53
Hi,
mir war auch nicht klar, dass das ne Antwort auf meine Frage war :-D
Unsorted hab ich nicht und ein Device namens undefined auch nicht ;-)
ghome läuft wunderbar, einzig nach nem "shutdown restart" vom fhem muss ich manuell den ghome Dienst neustarten, da er den o.g. Fehler bringt und nicht mehr funktioniert.
MfG
Manuel
Fehler suchen hat natürlich Vorrang, du schreibst, du musst den Dienst neu starten nach Fhem reboot ...
Teste mal und ändere mal das systemd-script mit den u. g. 2 Zeilen ab ... damit wird der Dienst automatisch neu gestartet wenn er crasht. Du hast aber eine Fehlermeldung im Log. RestartSec ... verzögert den Dienst etwas damit fhem auch sicher online ist.
nano /lib/systemd/system/ghome.service
Restart=always <-- Restart=on-failure muss dafür raus
RestartSec=2 <-- neu
Nach der Änderung noch ein "sudo systemctl daemon-reload" auf der Console ausführen.
Zur Info, es dürfte in nächster Zeit ein paar sehr interessante neue Traits und Device Typen geben die Google zukünftig unterstützt.
Zitat
Hi,
There is no support or documentation, but some traits and devices already exists :
action.devices.traits.OpenClose
action.devices.traits.UpDown
action.devices.traits.LockUnlock
action.devices.traits.ArmDisarm
action.devices.traits.Sensor
action.devices.traits.SensorState
action.devices.traits.Fill
action.devices.types.BLINDS
action.devices.types.DOOR
action.devices.types.GATE
action.devices.types.WINDOW
action.devices.types.LOCK
action.devices.types.SECURITYSYSTEM
action.devices.types.SENSOR
action.devices.types.BATHTUB
action.devices.types.CLOCK
action.devices.types.DOORBELL
action.devices.types.HUMIDIFIER
action.devices.types.DEHUMIDIFIER
Gerade auf github entdeckt :)
Sehr cool,
Endlich Rolläden! 8)
Was meinen die mit traits?
Bis denn
SouzA
Traits sind die Funktionen die man den Devices zuordnen kann. Z.B. Ein-/Ausschalten, Rauf-/Runter, Oeffnen/Schliessen, usw.. Ist eigentlich das, was man beim Assistenten als Funktion sagt. Der Geraetetyp ist bei Google fast nebensaechlich. Dient nur dazu, dass ein anderes Symbol in der Home App angezeigt wird und man die Devices auch ohne Namen ansprechen mit deren Typ (Licht, Geraet, Rolladen, Staubsauger, etc.) ansprechen kann.
Hi,
Zitat von: kadettilac89 am 31 Dezember 2018, 12:09:18
Fehler suchen hat natürlich Vorrang, du schreibst, du musst den Dienst neu starten nach Fhem reboot ...
Teste mal und ändere mal das systemd-script mit den u. g. 2 Zeilen ab ... damit wird der Dienst automatisch neu gestartet wenn er crasht. Du hast aber eine Fehlermeldung im Log. RestartSec ... verzögert den Dienst etwas damit fhem auch sicher online ist.
nano /lib/systemd/system/ghome.service
Restart=always <-- Restart=on-failure muss dafür raus
RestartSec=2 <-- neu
Nach der Änderung noch ein "sudo systemctl daemon-reload" auf der Console ausführen.
Gute Idee. Hab den Dienst jetzt mal auf systemd umgestellt (ohne restart=always) denn das war vorher noch init. Dabei fiel mir aber auf, dass da noch ein ghome prozess im Hintergrund lief, den ich mal manuell gestartet hab.
Über systemd gestarted blieb er jetzt zumindest laut Log auch nach fhem restart fehlerlos. Denke das Problem ist damit gelöst.
Danke Manuel
Was mir am meisten fehlt, ist Lautstärkesteuerung und Steuerung eines MediaPlayers (Start/Stop/Pause/Zurück/Vor etc.). Hat jemand eine Idee, warum es das nicht gibt? Strategie von Google?
Zitat von: vbs am 01 Januar 2019, 14:46:30
Was mir am meisten fehlt, ist Lautstärkesteuerung und Steuerung eines MediaPlayers (Start/Stop/Pause/Zurück/Vor etc.). Hat jemand eine Idee, warum es das nicht gibt? Strategie von Google?
Habe mich vor einer Weile selber geärgert, habe dann letztendlich einen Chromecast für Spotify gekauft. Scheinbar damit auch der eigene Chromecast verkauft werden kann. Aus Marketing Sicht ist es nachvollziehbar wenn damit das eigene Produkt unnötig würde (sowohl Chromecast als auch google music).
edit: ach ja .... je nach Anwendung, Logitec Hub geht scheinbar mit Google Home, vielleicht als Workaround brauchbar
Zitat von: vbs am 01 Januar 2019, 14:46:30
Was mir am meisten fehlt, ist Lautstärkesteuerung und Steuerung eines MediaPlayers (Start/Stop/Pause/Zurück/Vor etc.). Hat jemand eine Idee, warum es das nicht gibt? Strategie von Google?
Ich glaub das geht nur für Google Cast Geräte und das dürfte auch die Strategie von Google sein das bislang nicht für weitere Geräte anzubieten. Zumindest beim Chromecast und Google Home kann ich diese Kommandos sagen.
Aktuell nutze ich bei mir die Helligkeitsregelung für Volume. Start/Stop könnte man noch über das Start/Stop Trait implementieren, da geht dann sogar Pause. Vor und Zurück wäre noch über Modes umsetzbar und dann im Google Assistant einen Shortcut setzen "Spiele das nächste Lied" => "Stelle den Lautsprecher Modus auf next" oder so ähnlich.
Oder man streamt vom Home auf ein Bluetooth Gerät, dann geht es out of the Box. Weitere Möglichkeit ist noch ein Chromecast Audio.
Hi, im Moment habe ich noch alexa im Einsatz, aber sobald das Google Assistupdate für meine Sonos one kommt will ich das hier natürlich auch mal testen.
Habe gerade vom vorherigen alexa selber bauen skill zum alexa fhemlazy geändert. Der kommt mit einem offiziellen Skill und einem super installer.
Lange Rede kurzer Sinn.
Wird es für den google Assistent auch mal so ein sikll/installer geben? Ist ja ähnlich!
Zitat von: Badflex am 04 Januar 2019, 22:10:59
Wird es für den google Assistent auch mal so ein sikll/installer geben? Ist ja ähnlich!
Dominik arbeitet aktuell an was ähnlichem.
Ja. Ist ein anderer Ansatz, aber es wird auch funktionieren, habe ich selber testen können.
Alles wird gut :-)
Zitat von: vbs am 01 Januar 2019, 14:46:30
Was mir am meisten fehlt, ist Lautstärkesteuerung und Steuerung eines MediaPlayers (Start/Stop/Pause/Zurück/Vor etc.). Hat jemand eine Idee, warum es das nicht gibt? Strategie von Google?
Es gibt eine Indikation auf github, dass Google das zukünftig unterstützen wird. Angeblich funktioniert schon der Device Type SPEAKER und Trait Volume :)
Yay, das wäre ja klasse :-*
Hallo zusammen,
ich bin mittlerweile auch wieder dazu gekommen, weiter einzurichten, scheitere aber derzeit daran, fhem mit google bekannt zu machen:
pi@raspberrypi:~/.ghome $ ./gactions update --action_package action.json --project fhem-connector-XXXXX
ERROR: Failed to update the app for the Assistant
ERROR: Request contains an invalid argument.
Field Violations:
# Field Description
1 URL for conversation is invalid 'xxxxxx.ddns.net'
2019/01/08 20:18:15 Server did not return HTTP 200
(ausgeXtes ist per c&p eingetragen bzw. doppelt geprüft)
Wenn ich den daemon separat starte, kommt dies:
pi@raspberrypi:~/ghome-fhem/bin $ ./ghome &
[1] 1272
pi@raspberrypi:~/ghome-fhem/bin $ [2019-1-8 20:24:01] using /home/pi/.ghome/config.json
[2019-1-8 20:24:01] ---
[2019-1-8 20:24:01] this is alexa-fhem 0.3.4
[2019-1-8 20:24:01] Fetching FHEM devices...
[2019-1-8 20:24:01] [FHEM] starting longpoll: http://127.0.0.1:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1546975441444
[2019-1-8 20:24:01] Server listening on: https://:::3000
[2019-1-8 20:24:01] [FHEM] Checking devices and attributes...
[2019-1-8 20:24:01] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=%7BAttrVal(%22global%22,%22userattr%22,%22%22)%7D&XHR=1
[2019-1-8 20:24:01] [FHEM] executing: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20TYPE=ghome&XHR=1
[2019-1-8 20:24:01] [FHEM] Fetching FHEM devices...
[2019-1-8 20:24:01] [FHEM] fetching: http://127.0.0.1:8083/fhem?cmd=jsonlist2%20room=GoogleHome&XHR=1
[2019-1-8 20:24:01] [FHEM] got: 1 results
[2019-1-8 20:24:01] [FHEM] testlamp is switch
[2019-1-8 20:24:01] [FHEM] testlamp has
Mein Device hat ein folgendes list in Fhem:
Internals:
NAME testlamp
NR 1237
STATE off
TYPE dummy
READINGS:
2019-01-08 20:17:33 state off
Attributes:
genericDeviceType switch
room GoogleHome,9.98_Alphatest
Über den Browser lässt sich https://xxxxx.ddns.net aufrufen (Schloss ist grün, Zertifikat wird also erkannt):
Cannot GET /
https://xxxxx.ddns.net/oauth:
response_type undefined must equal "code"
https://xxxxx.ddns.net/token
missing required parameter
Wo kann ich denn weiter prüfen bzw. habe ich irgendwo einen Denkfehler drin? Danke nochmals fürs drüberschauen!
Bitte schick mir eine kurze PN mit deiner gmail Adresse, dann schalte ich dich als Beta Tester frei. Das erspart mir den Support für die alte Version und hilft mir beim Testen :)
Hi,
habe die ghome App nun einmal auf meinem FHEM Server installiert und soweit alles laut Anleitung konfiguriert.
Sobald ich in der Google Home APp FHEM verbinden will, erscheint die Website mit dem Button Login - kann aber keine Zugangsdaten eingeben. Die Felder sind nicht vorhanden.
Klicke ich auf "login" erhalte ich
Error: No default engine was specified and no extension was provided.
Habe auch schon versucht die App unter einem anderen User laufen zu lassen - aber das gleiche Problem.
Wenn ich die Seite lokal aufrufe habe ich genau dasselbe Problem.
Jemand eine Idee?
Danke.
Gruß
Hermann
Hi.
Habe noch einmal alles kontrolliert. Beim bower install hat es wohl Probleme gegeben, da ich dieses als sudo ausgeführt habe. Nun habe ich es als normalen User ausgeführt und die Website usw. wird nun angezeigt.
Jedoch erhalte ich nach Eingabe des User und Passworts wieder die Google Home App Seite und der Account wurde nicht verbunden. Auch nach mehrmaligen Versuchen.
Wenn ich dieses im Browser versuche, erhalte ich die Meldung "authCode Failed".
Steht auch im LOG File.
Kennt jemand eine Lösung?
Danke.
Gruß
Hermann
Zitat von: SouzA am 19 Oktober 2018, 23:15:40
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... :o ;D
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 ;D
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
Browsercache löschen...
Bis denn
SouzA
Hi,
ich bekomme aktuell mit der Google Home App 2.8.15.6 die Geräte nicht mehr angezeigt/hinzugefügt. Bei der Einrichtung sieht alles normal aus, nach Username/Passwort Bestätigung springt er wieder in die Providerübersicht und es sind keine Geräte hinzugefügt. Im Log vom ghome sehe ich eine erfolgreiche oauth Authentifizierung aber danach keinen Gerätelisten Request. Kann jemand noch dieses Verhalten bestätigen? Ich habe das Actions Projekt bereits neu erstellt.
Danke!
Hi,
probier bitte mit dem aktuellen Beta Action ob du dort auch das Problem hast. Schick mir dazu einfach eine PN mit deiner gmail Adresse und ich schalte dich dafür frei.
Zur Info, ich habe die Anleitung zur Nutzung des FHEM Connect Google Assistant Actions hier im Wiki publiziert:
https://wiki.fhem.de/wiki/Google_Assistant_FHEM_Connect
Aktuell benötige ich noch eure gmail Adresse per PN damit ich euch freischalte, da der Action noch nicht offiziell published ist.
Gruß,
Dominik
Leider exakt das gleiche mit dem neuen Service.
Könnte denn mir jemand bestätigen, das das komplette neu hinzufügen einer Verbindung aktuell funktioniert? Nachher liegt das an Google ?!?
Ich habe gerade im Log geschaut und kein einziges SYNC die letzte Stunde gesehen - also auch nichts von Google empfangen. Habe es mit meinen Devices nochmals getestet, da funktioniert es.
Starte bitte nochmals fhemconnect neu, warte dann ca. 2 Minuten und verbinde dann FHEM Connector Beta in der Home App.
Hi,
habe die Beta nun auch einmal installiert. Erst habe ich die ApErweiterung FHEM Connect im der Home App gar nicht gesehen.
Nachdem ich in Google Action Website den Test für das Projekt aktiviert habe, konnte ich die [test] FHEM Connect sehen.
Sobald ich mich aber damit verbinden will, erscheint in einem Fenster kurz "Account is now linked", springt dann aber wieder zum Einrichtungsfenster in der Home App zurück. Es wurde dann auch nichts verbunden.
Im LOG der fhemconnect App sehe ich:
SYNC UPDATED RECEIVED: {"syncactive":1}
SYNC UPDATED RECEIVED: {"disconnected":0,"syncactive":1}
GOOGLE MSG RECEIVED: {"id":"1123423470178334575911","msg":"RELOAD_DEVICES"}
**** Received firestore2fhem: {"id":"114256734578334575911","msg":"RELOAD_DEVICES"}
SYNC UPDATED RECEIVED: {"disconnected":0,"syncactive":0}
SYNC UPDATED RECEIVED: {"disconnected":0,"syncactive":1}
Idee?
Gruß
Hermann
Hi,
bitte sicherstellen, dass das Device auch ein on/off als Command akzeptiert - erkennbar wenn es im FHEM Web als Auswahl angezeigt wird. Dazu muss zumindest setList "on off" gesetzt sein wenn man ein Dummy Device verwendet.
Uiuiui.... Das war's.
Umgestellt und angemeldet und funktioniert.
Perfekt. Danke.
Nochmal eine doofe Frage: Wie kann ich das Programm den als daemon letzten lassen?
Genauso wie mit der gHome App?
Danke nochmals für das Modul und den tollen Support.
Gruß
Hermann
Aktuell ist es am einfachsten über systemd.
Es kommt aber noch eine Lösung direkt in FHEM, justme wird dazu den Alexa Starter für Google Assistant bereitstellen und dann läuft es automatisch.
Hi.
Habe nun etwas weiter mit der Sprachsteuerung gespielt - macht echt Spass :-)
Was mir aufgefallen ist: Ich habe eine Jalousie hinzugefügt (Homematic HM-LC-Bl1PBU-FM). In der Home App wird diese dann als "dimmbare Lampe" angezeigt. Soweit so gut.
Ich kann aber nicht auf 50% oder einen anderen Wert stellen. Es geht nur 0% und 100%.
Und bei 0% geht die Jalousie zu und bei 100% auf. Kann man das auch noch drehen (0% offen und 100% zu?)
Gruß
Hermann
Dafür gibt es im HM-Device das Attribut param und dort dem Parameter levelInverse.
Hallo,
habe mehrere Lampen dem Raum GoogleAssitant hinzu gefügt. Leider werden nicht alle Lampen in der Google Home App angezeigt.
Es handelt sich hierbei um IKEA-Tradfri Lampen. Die eine, die auch in der App erscheint ist über das Tradfri-Gateway eingebunden, die andere über zigbee2mqtt.
hier die Konfiguration der Lampe über zigbee2mqtt:
defmod 0x90fd9ffffedd7c9e XiaomiMQTTDevice LED1545G12 0x90fd9ffffedd7c9e
attr 0x90fd9ffffedd7c9e IODev mqtt
attr 0x90fd9ffffedd7c9e alexaName Treppenlicht
attr 0x90fd9ffffedd7c9e alias Treppenlicht
attr 0x90fd9ffffedd7c9e eventMap 350:standard 250:cold 454:warm
attr 0x90fd9ffffedd7c9e room GoogleAssistant,Treppe,XiaomiMQTTDevice,alexa
attr 0x90fd9ffffedd7c9e webCmd on:off:brightness:color_temp
attr 0x90fd9ffffedd7c9e widgetOverride brightness:slider,0,1,254 color_temp:warm,cold,standard
setstate 0x90fd9ffffedd7c9e off
setstate 0x90fd9ffffedd7c9e 2019-01-15 06:28:19 brightness 90
setstate 0x90fd9ffffedd7c9e 2019-01-15 06:28:19 color_temp 350
setstate 0x90fd9ffffedd7c9e 2019-01-15 06:28:19 state off
setstate 0x90fd9ffffedd7c9e 2019-01-15 08:37:02 transmission-state subscription acknowledged
hier die Konfiguration der Lampe über Tradfrigateway:
defmod MilenaSchlaf TradfriDevice 65537
attr MilenaSchlaf genericDeviceType light
attr MilenaSchlaf room GoogleAssistant,Haus_Oberweier,Tradfri
setstate MilenaSchlaf on
setstate MilenaSchlaf 2019-01-10 19:33:49 color f5faf6
setstate MilenaSchlaf 2018-11-09 07:17:51 createdAt Sat, 08 Sep 2018 17:54:15 GMT
setstate MilenaSchlaf 2019-01-10 19:33:49 dimvalue 254
setstate MilenaSchlaf 2019-01-15 06:48:07 lastSeen Tue, 15 Jan 2019 05:48:11 GMT
setstate MilenaSchlaf 2018-11-09 07:17:51 manufacturer IKEA of Sweden
setstate MilenaSchlaf 2018-11-09 07:17:51 name Licht
setstate MilenaSchlaf 2019-01-15 06:41:49 onoff on
setstate MilenaSchlaf 2019-01-15 06:41:49 pct 100
setstate MilenaSchlaf 2019-01-14 19:08:45 reachableState 1
setstate MilenaSchlaf 2018-11-09 07:17:51 softwareVersion 1.2.217
setstate MilenaSchlaf 2019-01-15 06:41:49 state on
setstate MilenaSchlaf 2018-11-09 07:17:51 type TRADFRI bulb E14 WS opal 400lm
und hier die Ausgabe von fhemconnect:
Refreshing tokens...
Firestore login succeed!
[2019-1-15 10:36:24] using /home/pi/.fhemconnect/config.json
[2019-1-15 10:36:24] ---
[2019-1-15 10:36:24] config:
{"connections":[{"name":"FHEM","server":"192.168.178.59","port":"8083","webname":"fhem","auth":{"user":"xxx","pass":"xxx"},"ssl":true,"filter":"room=GoogleAssistant"}]}
[2019-1-15 10:36:24] ---
[2019-1-15 10:36:24] Google Assistant FHEM Connect 1.0.0 started
[2019-1-15 10:36:25] Fetching FHEM connections...
[2019-1-15 10:36:25] [FHEM] starting longpoll: https://192.168.178.59:8083/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON×tamp=1547544985016
(node:27281) DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead
SYNC UPDATED RECEIVED: {"disconnected":0,"syncactive":0}
[2019-1-15 10:36:27] [FHEM] Checking devices and attributes...
starting FHEM_execute
executing: https://192.168.178.59:8083/fhem?cmd=%7BAttrVal(%22global%22,%22userattr%22,%22%22)%7D&XHR=1
handling informid: IT_0FF000FFFF-state
handling informid: IT_0FF00F0FFF-state
handling informid: IT_0FF00FF0FF-state
handling informid: MAX_07794a-desiredTemperature
handling informid: MAX_07794a-temperature
handling informid: MilenaSchlaf-pct
handling informid: SB_PLAYER_60a44c45c992-state
handling informid: SB_PLAYER_60a44c45c992-volume
[2019-1-15 10:36:27] [FHEM] Fetching FHEM devices...
[2019-1-15 10:36:27] [FHEM] fetching: https://192.168.178.59:8083/fhem?cmd=jsonlist2%20room=GoogleAssistant&XHR=1
[2019-1-15 10:36:30] [FHEM] got: 9 results
-----------------------------------------------
Ready! Open Home app and connect to FHEM.
-----------------------------------------------
Muss noch etwas beachtet werden oder ist dieser Fall noch nicht eingebunden?
Gruß rippi
Hi Dominik,
ist geplant dieses Modul an die neue alexa-fhem Architektur anzugleichen bzw. auch über NPM anzubieten?
Wenn es ein offizielles Modul wird, dann würde ich es auch bei Zeiten ins FHEM Docker Image aufnehmen.
Gruß
Julian
ich antworte mal schnell:
ja. ist geplant.
ich mache dominik demnächst ein modul fertig das hinsichtlich start genau so funktioniert wie alexa-fhem.
alle drei drei module sollen auch so weit es geht auf gemeinsam genutzten
code umgestellt werden.
Absolut sinnvoll, prima! 8)
Diese Entwicklung macht mich gerade wirklich sehr froh :D
@justme1968
Aktuell gibt es bei der Implementierung des "lokalen" GHome Modules Probleme mit mehreren konfigurierten FHEM-Instanzen. Könntest du das bitte im Hinterkopf halten und evtl. im Zuge der Umsetzung berücksichtigen.
Danke!
@pattex, ich glaub das muss ich in meinem Code noch anpassen. Zuerst möchte ich aber noch die Anpassungen vornehmen, dass wir das Modul von justme1968 dann nutzen können.
Hallo dominik,
habe eine RGBWW-Controller über den Fhem-Connector Beta eingebunden.
Über die Sprachsteuerung kann ich die Farben und die Helligkeit steuern, aber in der App auf dem Handy leider nur die Helligkeit.
Wird das von der App nicht unterstützt oder muß ich noch etwas beachten?
Gruß rippi
Hi Dominik, ich habe FHEM mit deinem ghome modul mittlerweile in meinem und meinem Elternhaus erfolgreich im Einsatz und bin trotz der noch limitierten Möglichkeiten, die die Google Home App und Sprachsteuerung bisher bietet begeistert.
Jetzt habe ich ein neues Gerät bei meinen Eltern zum GoogleHome Raum hinzugefügt, welches scheinbar das komplette Parsing durch ghome auf dei Bretter gehen lässt. Im syslog ist nach "Fetching FHEM devices..." und Aufruf der URL nur noch "got: undefined results" als Eintrag. Das hat wohl zur Folge das auch kein anderes bereitsdefiniertes Gerät "erkannt" wird. Sobald ich dieses Gerät wieder aus dem GoogleHome Raum herausnehme und den ghome Dienst nochmal neu starte,
Bei dem Gerät handelt es sich um eine Z-Wave Qubino ZMNHOD1 Flush Shutter DC.
Wenn ich die URL aus "Fetching FHEM devices..." im Browser aufrufe, werden alle 11 Geräte aus dem Raum geliefert, inklusive dem folgenden Übeltäter:
{
"Name":"1og_vorratsraum_rolladen",
"PossibleSets":"associationAdd associationDel basicSet basicValue configActivateDeactivateFunctionsALLON10:ALLONIsNotActiveALLOFFIsNot0,ALLONActiveALLOFFIsNotActive,ALLONIsNotActiveALLOFFActive,ALLONActiveALLOFFActive configByte configDefault configDelayTimeBetweenOutputs configDigitalTemperatureSensor120 configForcedShutterCalibration:Default,StartCalibrationProcess configLong configMotorMovingUpDownTime configMotorOperationDetection configOperatingModes:Venetian,Shutter configPowerConsumptionAtLimitSwitch86 configPowerConsumptionMaxDelayTime configPowerReportingInWattsByTime42 configPowerReportingInWattsOnPower40 configPowerReportingToController:Disabled,Enable configSelfMeasurement:Eable,Disabled configSlatsPosition:UIControlMomentarySwitch1,UIControlPushButtonLimitSwitchIs2,UIControl configSlatsTiltingFullTurnTime configTemperatureSensorOffsetSettings configWord dim:slider,0,1,99 dimUpDown dimUpDownIncDecWithDuration dimUpDownWithDuration dimWithDuration mcaAdd mcaDel meterReset:noArg neighborUpdate:noArg off:noArg on:noArg powerlevel powerlevelTest returnRouteAdd returnRouteDel:noArg stop:noArg swaIncludeNone:noArg swaIncludeOff:noArg swaIncludeOn:noArg swaIncludeOnOff:noArg swaOff:noArg swaOn:noArg on-till-overnight intervals on-for-timer off-till-overnight on-till blink off-for-timer toggle off-till ",
"PossibleAttrs":"alias comment:textField-long eventMap:textField-long group room suppressReading userReadings:textField-long verbose:0,1,2,3,4,5 IODev WNMI_delay classes disable:0,1 disabledForIntervals do_not_notify:noArg dummy:noArg eventForRaw extendedAlarmReadings:0,1,2 ignore:noArg ignoreDupMsg:noArg neighborListPos noExplorerFrames:noArg noWakeupForApplicationUpdate:noArg secure_classes showtime:noArg vclasses useMultiCmd:noArg useCRC16:noArg zwaveRoute event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading cmdIcon devStateIcon devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,aircondition,airpurifier,camera,coffeemaker,dishwasher,dryer,fan,kettle,oven,refrigerator,scene,sprinkler,vacuum,washer homebridgeMapping:textField-long icon realRoom:textField sortby webCmd webCmdLabel:textField-long widgetOverride userattr",
"Internals": {
"DEF": "fa88be03 2",
"NAME": "1og_vorratsraum_rolladen",
"NR": "39",
"STATE": "dim 99",
"TYPE": "ZWave",
"ZWaveSubDevice": "no",
"homeId": "fa88be03",
"nodeIdHex": "02"
},
"Readings": {
"assocGroupCmdList_1": { "Value":"DEVICE_RESET_LOCALLY:01 SWITCH_MULTILEVEL:03 SENSOR_MULTILEVEL:05 METER:02", "Time":"2019-01-17 23:23:35" },
"assocGroupCmdList_2": { "Value":"BASIC:01", "Time":"2019-01-17 23:23:39" },
"assocGroupCmdList_3": { "Value":"BASIC:01", "Time":"2019-01-17 23:23:40" },
"assocGroupCmdList_4": { "Value":"BASIC:01", "Time":"2019-01-17 23:23:42" },
"assocGroupCmdList_5": { "Value":"BASIC:01", "Time":"2019-01-17 23:23:43" },
"assocGroupCmdList_6": { "Value":"BASIC:01", "Time":"2019-01-17 23:23:45" },
"assocGroupCmdList_7": { "Value":"SWITCH_MULTILEVEL:01", "Time":"2019-01-17 23:23:46" },
"assocGroupCmdList_8": { "Value":"SWITCH_MULTILEVEL:01", "Time":"2019-01-17 23:23:48" },
"assocGroupCmdList_9": { "Value":"SENSOR_MULTILEVEL:05", "Time":"2019-01-17 23:23:49" },
"assocGroupName_1": { "Value":"\u0008lifeline", "Time":"2019-01-17 23:23:54" },
"assocGroupName_2": { "Value":"BasicSetKey1", "Time":"2019-01-17 23:23:56" },
"assocGroupName_3": { "Value":"BasicSetKey2", "Time":"2019-01-17 23:23:57" },
"assocGroupName_4": { "Value":"\u0010BasicSetMovement", "Time":"2019-01-17 23:23:58" },
"assocGroupName_5": { "Value":"\u0013BasicSetEndPosition", "Time":"2019-01-17 23:24:00" },
"assocGroupName_6": { "Value":"\u0010BasicSetAtClosed", "Time":"2019-01-17 23:24:02" },
"assocGroupName_7": { "Value":"MultilevelSetRollerPosition", "Time":"2019-01-17 23:24:03" },
"assocGroupName_8": { "Value":"\u0019MultilevelSetTiltPosition", "Time":"2019-01-17 23:24:05" },
"assocGroupName_9": { "Value":"\u0011TemperatureReport", "Time":"2019-01-17 23:24:07" },
"assocGroup_1": { "Value":"Max 1 Nodes ZWDongle_0", "Time":"2019-01-17 23:23:19" },
"assocGroup_2": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_3": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_4": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_5": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_6": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_7": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_8": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroup_9": { "Value":"Max 16 Nodes", "Time":"2019-01-17 23:23:19" },
"assocGroups": { "Value":"9", "Time":"2019-01-17 23:23:27" },
"basicReport": { "Value":"0", "Time":"2019-01-17 23:24:13" },
"configActivateDeactivateFunctionsALLON10": { "Value":"ALLONActiveALLOFFActive", "Time":"2019-01-17 23:24:17" },
"configDelayTimeBetweenOutputs": { "Value":"5", "Time":"2019-01-17 23:24:17" },
"configDigitalTemperatureSensor120": { "Value":"5", "Time":"2019-01-17 23:24:17" },
"configForcedShutterCalibration": { "Value":"Default", "Time":"2019-01-17 23:24:17" },
"configMotorMovingUpDownTime": { "Value":"0", "Time":"2019-01-17 23:24:17" },
"configMotorOperationDetection": { "Value":"6", "Time":"2019-01-17 23:24:18" },
"configOperatingModes": { "Value":"Shutter", "Time":"2019-01-17 23:24:18" },
"configPowerConsumptionAtLimitSwitch86": { "Value":"8", "Time":"2019-01-17 23:24:18" },
"configPowerConsumptionMaxDelayTime": { "Value":"8", "Time":"2019-01-17 23:24:18" },
"configPowerReportingInWattsByTime42": { "Value":"300", "Time":"2019-01-17 23:24:18" },
"configPowerReportingInWattsOnPower40": { "Value":"1", "Time":"2019-01-17 23:24:18" },
"configPowerReportingToController": { "Value":"Enable", "Time":"2019-01-17 23:24:18" },
"configSelfMeasurement": { "Value":"Disabled", "Time":"2019-01-17 23:24:18" },
"configSlatsPosition": { "Value":"UIControlMomentarySwitch1", "Time":"2019-01-17 23:24:18" },
"configSlatsTiltingFullTurnTime": { "Value":"150", "Time":"2019-01-17 23:24:18" },
"configTemperatureSensorOffsetSettings": { "Value":"32536", "Time":"2019-01-17 23:24:18" },
"mcaGroups": { "Value":"9", "Time":"2019-01-17 23:24:36" },
"mca_1": { "Value":"Max 1 Nodes ZWDongle_0", "Time":"2019-01-17 23:24:30" },
"mca_2": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_3": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_4": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_5": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_6": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_7": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_8": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"mca_9": { "Value":"Max 16", "Time":"2019-01-17 23:24:30" },
"meterSupported": { "Value":"type: energy scales: 0:kWh, 2:W resetable: yes", "Time":"2019-01-17 23:24:47" },
"model": { "Value":"Qubino ZMNHOD1 Flush Shutter DC", "Time":"2019-01-17 23:24:55" },
"modelConfig": { "Value":"qubino/ZMNHODx.xml", "Time":"2019-01-17 23:24:55" },
"modelId": { "Value":"0159-0003-0053", "Time":"2019-01-17 23:24:55" },
"neighborList": { "Value":"ZWDongle_0", "Time":"2019-01-17 23:25:01" },
"power": { "Value":"0 W", "Time":"2019-01-18 15:26:00" },
"powerlvl": { "Value":"current 0 remain 0", "Time":"2019-01-17 23:25:09" },
"reportedState": { "Value":"dim 99", "Time":"2019-01-18 14:39:08" },
"state": { "Value":"dim 99", "Time":"2019-01-18 14:39:08" },
"swa": { "Value":"on off", "Time":"2019-01-17 23:25:13" },
"swmSwitchType": { "Value":"primary Up/Down secondary Undefined", "Time":"2019-01-17 23:25:30" },
"timeToAck": { "Value":"0.030", "Time":"2019-01-18 14:38:37" },
"transmit": { "Value":"OK", "Time":"2019-01-18 14:38:37" },
"version": { "Value":"Lib 3 Prot 4.05 App 1.1 HW 1 FWCounter 0", "Time":"2019-01-17 23:25:47" },
"zwavePlusInfo": { "Value":"version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:1a00 userIcon:1a00", "Time":"2019-01-17 23:25:57" }
},
"Attributes": {
"IODev": "ZWDongle_0",
"alias": "Rolladen Vorratsraum",
"classes": "ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL BASIC SWITCH_ALL SWITCH_BINARY SWITCH_MULTILEVEL METER ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO CONFIGURATION MARK BASIC SWITCH_MULTILEVEL",
"devStateIcon": "on:fts_shutter_10@green off:fts_shutter_100@black dim\u005cs9\u005cd.*:fts_shutter_10 dim\u005cs8\u005cd.*:fts_shutter_20 dim\u005cs7\u005cd.*:fts_shutter_30 dim\u005cs6\u005cd.*:fts_shutter_40 dim\u005cs5\u005cd.*:fts_shutter_50 dim\u005cs4\u005cd.*:fts_shutter_60 dim\u005cs3\u005cd.*:fts_shutter_70 dim\u005cs2\u005cd.*:fts_shutter_80 dim\u005cs1\u005cd.*:fts_shutter_90 dim\u005cs0\u005cd.*:fts_shutter_100",
"genericDeviceType": "blind",
"group": "Rolladen",
"icon": "fts_shutter_20",
"room": "GoogleHome,Vorratsraum",
"vclasses": "ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 METER:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2"
}
},
Nach ein wenig herumprobieren, scheint folgendes Reading mit Sonderzeichen das Problem zu verursachen:
"assocGroupName_7": { "Value":"MultilevelSetRollerPosition", "Time":"2019-01-17 23:24:03" },
Nachdem ich dieses Reading gelöscht habe und den ghome Dienst neu gestartet habe, lief es wieder einwandfrei.
Evtl. muss dem Parser das verarbeiten/ignorieren dieses Sonderzeichens noch beigebracht werden. FHEM scheint diesen nicht als escapeten Unicode HTML code zu liefern, sondern direkt als Sonderzeichen.
Zitat von: rippi46 am 18 Januar 2019, 14:28:32
Hallo dominik,
habe eine RGBWW-Controller über den Fhem-Connector Beta eingebunden.
Über die Sprachsteuerung kann ich die Farben und die Helligkeit steuern, aber in der App auf dem Handy leider nur die Helligkeit.
Wird das von der App nicht unterstützt oder muß ich noch etwas beachten?
Gruß rippi
Die App unterstuetzt aktuell nur Helligkeit und Ein/Aus, leider noch keine Farben. Die Farben gehen nur per Sprachsteuerung.
@X-Byte, danke dir fuer die Info, da muss ich im Code mal nachschauen wo der Parser nicht richtig tut.
Kurzes Update...ich habe den Action nun bei Google eingereicht. Laut deren Info dauert es ca. 5 Wochen bis alles durch ist. Im Moment fordert Google auch noch Devices die ich ihnen zuschicken soll, mal sehen ob ich die dazu überreden kann, dass die Verbindung nur von Software zu Software erfolgt und der Rest eigentlich Sache von FHEM ist.
Wer nicht solange warten will, braucht mir nur eine PN mit seiner gmail Adresse schicken.
Hallo Zusammen,
ich habe die Version "FHEM Connector Beta" zum laufen bekommen, aber die Verbindung zwischen FHEM und Google Home wird nach kurzer Zeit wieder unterbrochen (ungefähr nach 10 Minuten).
Wenn ich dann das Skript bin/fhemconnect wieder ausführe, funktioniert es wieder für 10 min. Woran kann das liegen?
Habe ich irgendwas vergessen oder übersehen?
VG Andreas
Zitat von: anco1726 am 22 Januar 2019, 16:14:08
Hallo Zusammen,
ich habe die Version "FHEM Connector Beta" zum laufen bekommen, aber die Verbindung zwischen FHEM und Google Home wird nach kurzer Zeit wieder unterbrochen (ungefähr nach 10 Minuten).
Wenn ich dann das Skript bin/fhemconnect wieder ausführe, funktioniert es wieder für 10 min. Woran kann das liegen?
Habe ich irgendwas vergessen oder übersehen?
VG Andreas
Hi,
bitte poste das Log von fhemconnect, dann kann ich mir das anschauen.
Hallo,
ich brauche bitte eure Unterstützung für die Google Zertifizierung:
- Könnt ihr mir einen Thermostat Typ nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
- Könnt ihr mir einen Zwischenstecker nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
Ich selbst habe kein Homematic IP, aber ich denke Homematic IP würde machbar sein, oder? Ich brauche nämlich ein Device das bei Google bereits abgenommen wurde und daher die Hardware schon bei ihnen verfügbar ist.
Danke!
Zitat von: dominik am 22 Januar 2019, 17:54:08
Hi,
bitte poste das Log von fhemconnect, dann kann ich mir das anschauen.
Hi,
wo finde ich das Log?
Starte bitte mit
bin/fhemconnect
und warte dann bis der Fehler auftritt. Sobald der Fehler kommt, kopier mir bitte den Fehlerfall hier rein.
@dominik
Zwischenstecker habe ich über Philips Hue den OSRAM Plug 01 V1.04.12 https://www.amazon.de/gp/product/B074PZLX2P
Zitat von: dominik am 22 Januar 2019, 21:00:55
ich brauche bitte eure Unterstützung für die Google Zertifizierung:
- Könnt ihr mir einen Thermostat Typ nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit
Ich selbst habe kein Homematic IP, aber ich denke Homematic IP würde machbar sein, oder? Ich brauche nämlich ein Device das bei Google bereits abgenommen wurde und daher die Hardware schon bei ihnen verfügbar ist.
ich nutze homematic classic. leider keine hilfe.
homematic ip verbindet zu ghome nur mit access point aber nicht über ccu2. ccu3 weiß ich nicht ob da ghome mittlerweile integriert ist, denke aber auch nicht. access point ist bindeglied zur homematic cloud die mit ghome spricht.
fhem spricht aber zur ccu, zumindest weren es die meisten so machen.
in dem post unten wir erklärt wie man über umwege an die homematic cloud kommt. ob das reicht?
https://forum.fhem.de/index.php?topic=83115.0
Ich habe zwei shelly 1 mit der original Software über mqtt angebunden. Shelly sollte bei google bekannt sein, da die gerade auch in der gleichen Phase stecken.
Aber mal was anderes, oder ich habe hier was überlesen, willst du als Anbieter auftreten und man kann sich bei dir anmelden und dann sein eigenes fhem mit google verbinden?
Hallo dominik,
habe aktuell das Problem, dass alle Geräte, die ich in den Raum GoogleAssistant schiebe vom Fhem Connector Beta erkannt werden und ich sie auch über die App bedienen kann. Wenn zB. sage "ok Google schalte Leiste ein oder stelle Heizung auf 20° findet er die Geräte nicht.
Habe schon die Verbindung zu fhem Connector Beta getrennt und wieder neu eingerichtet, aber das Ergebnis ist das gleiche. ich kann die Geräte nicht mehr schalten. Es tauchen aber auch Geräte auf, die schon lange nicht mehr im Raum GoogleAssistant sind. Habe auch schon mehrfach synchronisiert.
Gibt es aktuell Probleme, oder muss ich noch etwas ändern?
Gruß rippi
PS: es hat doch alles schon funktioniert :(
Zitat von: dominik am 22 Januar 2019, 21:00:55
Hallo,
ich brauche bitte eure Unterstützung für die Google Zertifizierung:
- Könnt ihr mir einen Thermostat Typ nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
- Könnt ihr mir einen Zwischenstecker nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
Ich selbst habe kein Homematic IP, aber ich denke Homematic IP würde machbar sein, oder? Ich brauche nämlich ein Device das bei Google bereits abgenommen wurde und daher die Hardware schon bei ihnen verfügbar ist.
Danke!
Thermostat:
Homematic Funk-Heizkörperthermostat HM-CC-RT-DN (sind über einen CUL angebunden)
Lassen sich leicht einrichten
Nutze 10 Stück über deinen Beta Connector
Zwischenstecker:
- G-Homa WLAN Plug
- Homematic HM-LC-Sw1-Pl-2
- FIBARO FIBEFGWPF-102-5 FGWP-102 Wall Plug
Alle 3 Varianten in Betrieb
Edit: den letzten Satz hatte ich auf dem Handy nicht gesehen.
Homematic IP geht in FHEM in Verbindung mit einer CCU2, CCU3 oder OCCU (das ist eine SW die auf dem Raspberry parallel zu FHEM laufen kann).
Aber so ganz verstehe ich das mit der Zertifizierung nicht.
Bedeutet es die wollen das selbst testen?
Zitat von: anco1726 am 22 Januar 2019, 22:17:56
Hi,
wo finde ich das Log?
Hi Dominik,
ich habe festgestellt, solange ich fhenconnect im Terminalfenster laufen habe, funktioniert alles. Wenn ich das Terminalfenster schließe, ist die Verbindung weg.
VG Andreas
Hallo anco1726,
wenn du das Terminalfenster beendest, beendest du auch fhemconnect.
Entweder du lässt fhemconnect als Service laufen oder du beendest das Terminal nicht.
Eine Datei anlegen in:
/lib/systemd/system/
mit dem namen ghomeassistant.service mit folgendem Inhalt:
[Unit]
Description=Google Assistant FHEM Connector Beta
After=network-online.target
[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/fhem-google-assistant-connector
ExecStart=/home/pi/fhem-google-assistant-connector/bin/fhemconnect
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=ghomeassistant.service
und dann
sudo systemctl enable ghomeassistant.service
ausführen, dan läuft das Ganze als Service
Gruß rippi
Hallo rippi,
danke, jetzt funktioniert es.
VG Andreas
Zitat von: dominik am 22 Januar 2019, 21:00:55
Hallo,
ich brauche bitte eure Unterstützung für die Google Zertifizierung:
- Könnt ihr mir einen Thermostat Typ nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
- Könnt ihr mir einen Zwischenstecker nennen, den man leicht in FHEM einbinden kann und den ihr bereits erfolgreich mit dem Beta Connector nutzt?
Ich selbst habe kein Homematic IP, aber ich denke Homematic IP würde machbar sein, oder? Ich brauche nämlich ein Device das bei Google bereits abgenommen wurde und daher die Hardware schon bei ihnen verfügbar ist.
Danke!
Hi. Ich setze auch die Jomematic HM-CC-RT-DN Heizungsregler ein. Funktionieren sehr gut :-)
Hallo Zusammen,
ich teste aktuell den Beta Connector und mir ist aufgefallen, dass sich Geräte teilweise vervielfachen. Ich habe im Esszimmer 3 Lampen eingerichtet und wenn ich das Kommando gebe, schalte das Licht im Esszimmer ein, funktioniert dieses, aber es kommt die Info "ich habe neun Geräte eingeschaltet" (siehe Log).
Ich kann die Lampen auch nicht mehr einzeln bedienen, weil ghome nicht weiß, z.B. welche Wandlampe eingeschaltet werden soll.
Kennt jemand dieses Verhalten?
VG Andreas
Zitat von: grabbman am 23 Januar 2019, 07:10:44
Ich habe zwei shelly 1 mit der original Software über mqtt angebunden. Shelly sollte bei google bekannt sein, da die gerade auch in der gleichen Phase stecken.
Aber mal was anderes, oder ich habe hier was überlesen, willst du als Anbieter auftreten und man kann sich bei dir anmelden und dann sein eigenes fhem mit google verbinden?
FHEM Connect wird nur die Verbindung deines FHEM mit Google Assistant ermöglichen. Die "Anmeldung" ist nur erforderlich, da Google einen Account benötigt mit dem der Dienst verlinkt wird.
Zitat von: rippi46 am 23 Januar 2019, 08:50:03
Hallo dominik,
habe aktuell das Problem, dass alle Geräte, die ich in den Raum GoogleAssistant schiebe vom Fhem Connector Beta erkannt werden und ich sie auch über die App bedienen kann. Wenn zB. sage "ok Google schalte Leiste ein oder stelle Heizung auf 20° findet er die Geräte nicht.
Habe schon die Verbindung zu fhem Connector Beta getrennt und wieder neu eingerichtet, aber das Ergebnis ist das gleiche. ich kann die Geräte nicht mehr schalten. Es tauchen aber auch Geräte auf, die schon lange nicht mehr im Raum GoogleAssistant sind. Habe auch schon mehrfach synchronisiert.
Gibt es aktuell Probleme, oder muss ich noch etwas ändern?
Gruß rippi
PS: es hat doch alles schon funktioniert :(
Kannst du mir bitte die Logeinträge aus deinem Client posten wenn es nicht funktioniert?
Zitat von: klausw am 23 Januar 2019, 13:15:04
Thermostat:
Homematic Funk-Heizkörperthermostat HM-CC-RT-DN (sind über einen CUL angebunden)
Lassen sich leicht einrichten
Nutze 10 Stück über deinen Beta Connector
Zwischenstecker:
- G-Homa WLAN Plug
- Homematic HM-LC-Sw1-Pl-2
- FIBARO FIBEFGWPF-102-5 FGWP-102 Wall Plug
Alle 3 Varianten in Betrieb
Edit: den letzten Satz hatte ich auf dem Handy nicht gesehen.
Homematic IP geht in FHEM in Verbindung mit einer CCU2, CCU3 oder OCCU (das ist eine SW die auf dem Raspberry parallel zu FHEM laufen kann).
Aber so ganz verstehe ich das mit der Zertifizierung nicht.
Bedeutet es die wollen das selbst testen?
Ja, Google testen den gesamten Action selbständig mit physischen Geräten. Eine Zertifizierung mit "virtuellen Geräten" ist leider nicht erlaubt. Daher ist mein Plan, ihnen eine Lampe, einen Zwischenstecker und ein Thermostat zu nennen mit welchen sie testen können.
Zitat von: anco1726 am 24 Januar 2019, 20:10:06
Hallo Zusammen,
ich teste aktuell den Beta Connector und mir ist aufgefallen, dass sich Geräte teilweise vervielfachen. Ich habe im Esszimmer 3 Lampen eingerichtet und wenn ich das Kommando gebe, schalte das Licht im Esszimmer ein, funktioniert dieses, aber es kommt die Info "ich habe neun Geräte eingeschaltet" (siehe Log).
Ich kann die Lampen auch nicht mehr einzeln bedienen, weil ghome nicht weiß, z.B. welche Wandlampe eingeschaltet werden soll.
Kennt jemand dieses Verhalten?
VG Andreas
Siehst du auch in der Home App mehrere gleiche Geräte? Teilweise konnte ich ein ähnliches Verhalten bei mir feststellen, wenn ich oftmals einen Link und Unlink des Actions durchgeführt habe. Ich habe dann manchmal nach dem Unlink eine Nacht gewartet, dann waren die Geräte wieder da und dann wieder einen Unlink gemacht.
Ich glaube es hat mit dem Home Graph bei Google zu tun. Ich konnte ähnliche Probleme bereits auf github von anderen lesen.
Bei mir funktionieren auch die eq3 Max Thermostat, hat jemand Rollos im Einsatz? ::)
ZitatSiehst du auch in der Home App mehrere gleiche Geräte? Teilweise konnte ich ein ähnliches Verhalten bei mir feststellen, wenn ich oftmals einen Link und Unlink des Actions durchgeführt habe. Ich habe dann manchmal nach dem Unlink eine Nacht gewartet, dann waren die Geräte wieder da und dann wieder einen Unlink gemacht.
Ich glaube es hat mit dem Home Graph bei Google zu tun. Ich konnte ähnliche Probleme bereits auf github von anderen lesen.
Nein, in der Home App war die Anzahl richtig. Ich habe es so gemacht wie du geschrieben hattest und jetzt passt die Anzahl der Geräte wieder. Es scheint daran zu liegen, wenn man den Connector kurz hintereinander unlinked und wieder linked.
Hallo Zusammen!
Erst einmal vielen Dank an Dominik für die geile Umsetzung! Die Beta läuft bei mir sehr zuverlässig. Hinzufügen und die Einrichtung lief bei mir relativ problemfrei. Die Anlehnung an den Alexa-Fhem Skill macht das Nachschlagen von Probleme etwas leichter. Ein Hinweis, dass bei gesichertem FHEM-WEB ein anpassen der config.json nötig ist, würde sich ganz gut im Wiki Artikel machen, das ist aber sicher eher Prio 5 ;).
Meine Wifilight LD382A LED Streifen lassen sich schalten und dimmen, Farben ändern habe ich aber nicht hin bekommen.
Auch ein Tradfri Treiber der via MQTT angebunden ist wird nicht erkannt (soll heißen das Gerät wird nicht in der Liste des FHEM-Connect aufgeführt). Heißt aber nicht, dass ich nicht irgendwas falsch konfiguriert habe.
Wenn Du dafür Logs haben willst kann ich dir gerne etwas zur Verfügung stellen.
Insgesamt aber "stable as a rock!", zumindest was ich bis jetzt probiert habe. Vielen Dank dafür! Endlich keine 300 IFTTT Aktionen mehr für alle Geräte und Zustände.
Gibts eigentlich ne Möglichkeit Ligthscene einzubinden?
Zitat von: the-vince am 27 Januar 2019, 18:00:45
Gibts eigentlich ne Möglichkeit Ligthscene einzubinden?
Hi, einfach das LightScene-Device in den Google-Raum packen. Die Szenen (alle) aus der Lightscene kannst du dann in der Ambientesteuerung finden.
Bis denn
SouzA
WifiLight Farbsteuerung geht noch nicht, ist noch ein Bug.
LightScene wird erkannt, beim Aktivieren ist noch ein Bug drin den ich beheben muss.
Bin aktuell gerade mit justme-1968 dran das gassistant-fhem Modul zu integrieren, dann wird die Installation noch einfacher. Sobald das fertig ist, kann ich mich wieder um die Bugs kuemmern.
Hi,
ich habe zur Zeit ein Problem mit dem Jalousie Schalter von HM. Wenn ich ghome sage er soll die Küchenjaousie auf 40 Prozent schalten, kommt nur ein "Der Anbieter FHEM Connector Beta ist zur Zeit nicht erreichbar." Sage ich danach dass er die kleine Küchenlampe einschalten soll, funktioniert es wie gewünscht. Sogar die Abfrage der Heizung in der Küche funktioniert. Nur der Jalousie Schalter funktioniert nicht mehr. In den ersten 2 Wochen funktionierte dieser einwandfrei.
Hier ein list des Devices:
Internals:
DEF 507447
FUUID 5c4593b8-f33f-7494-a79c-2d7c4b94c0df9b3d
IODev RM_HmUART_EG
LASTInputDev RM_HmUART_EG
MSGCNT 13
NAME Kueche_Jalousie
NOTIFYDEV global
NR 237
NTFY_ORDER 50-Kueche_Jalousie
RM_HmUART_EG_MSGCNT 13
RM_HmUART_EG_RAWMSG 0501003C58A410507447F6A4B20601C800
RM_HmUART_EG_RSSI -60
RM_HmUART_EG_TIME 2019-01-28 14:48:58
STATE off
TYPE CUL_HM
lastMsg No:58 - t:10 s:507447 d:xxxxxx 0601C800
protLastRcv 2019-01-28 14:48:58
protRcv 12 last_at:2019-01-28 14:48:58
protResnd 1 last_at:2019-01-27 10:46:48
protSnd 14 last_at:2019-01-28 14:48:58
protState CMDs_done
rssi_RM_HmUART_EG cnt:3 min:-67 max:-64 avg:-65 lst:-64
rssi_at_RM_HmUART_EG cnt:13 min:-63 max:-57 avg:-59.84 lst:-60
READINGS:
2019-01-28 11:30:38 CommandAccepted yes
2019-01-13 18:05:48 D-firmware 2.8
2019-01-13 18:05:48 D-serialNr NEQ1601634
2019-01-15 20:47:25 PairedTo 0xxxxxxx
2019-01-15 20:47:26 R-driveDown 17 s
2019-01-13 18:05:54 R-driveTurn 0.5 s
2019-01-15 20:47:00 R-driveUp 17 s
2019-01-13 18:05:56 R-pairCentral 0xxxxxxx
2019-01-13 18:05:54 R-powerUpAction off
2019-01-13 18:05:54 R-sign off
2019-01-15 20:47:25 RegL_00. 00:00 02:01 0A:F6 0B:A4 0C:B2 15:FF 18:00
2019-01-15 20:47:26 RegL_01. 00:00 08:00 09:00 0A:00 0B:00 0C:AA 0D:00 0E:AA 0F:05 10:00 30:06 56:00 57:24
2019-01-28 14:48:58 deviceMsg off (to RM_HmUART_EG)
2019-01-28 14:48:58 level 0
2019-01-28 14:48:58 motor stop:off
2019-01-28 14:48:58 pct 0
2019-01-13 18:05:55 powerOn 2019-01-13 18:05:55
2019-01-28 14:48:58 recentStateType info
2019-01-28 14:48:58 state off
2019-01-28 14:48:58 timedOn off
helper:
HM_CMDNR 88
cSnd 11F6A4B25074470201000000,11F6A4B2507447020164
dlvlCmd ++A011F6A4B2507447020164
mId 006A
regLst ,0,1,3p
rxType 1
supp_Pair_Rep 0
dir:
cur stop
rct up
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +507447,00,00,00
nextSend 1548683338.87975
prefIO
rxt 0
vccu
p:
507447
00
00
00
mRssi:
mNo 58
io:
RM_HmUART_EG:
-56
-56
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
prs 1
rpt:
IO RM_HmUART_EG
flg A
ts 1548683338.63799
ack:
HASH(0x55bce9085a00)
588002F6A4B250744700
rssi:
RM_HmUART_EG:
avg -65
cnt 3
lst -64
max -64
min -67
at_RM_HmUART_EG:
avg -59.8461538461538
cnt 13
lst -60
max -57
min -63
Attributes:
IODev RM_HmUART_EG
alias Kuechenjalousie
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.8
ghomeName Kuechenjalousie
group Jalousien
model HM-LC-Bl1PBU-FM
mqttPublish level|state|pct:topic={"/SmartHome/$device/$name"}
mqttSubscribe pct:stopic=/SmartHome/Kueche_Jalousie/pct/Set
param levelInverse
peerIDs 00000000,
room GoogleAssistant,Homematic,Kueche
serialNr NEQ1601634
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
Hat das auch jemand gehabt? Gibt es eine Lösung?
Danke.
Gruß
Hermann
Hi,
der Fehler, dass FHEM nicht erreichbar ist, kommt wenn keine Rückmeldung an Google geschickt wird da es irgendwo crashed. Werde das noch anpassen, damit zumindest ein passenderer Fehler gemeldet wird.
Ich habe gerade die Fehlerkonsole angesehen und sehe da paar Meldungen bei AbsoluteBrightness, was für Rollos verwendet wird. Ich schau mir das im Laufe der Woche mal an.
Supi, Danke.
Ein Neustart und ein neues Hinzufügen des Gerätes hat auch keine Besserung gebracht.
Ansonsten läuft das Modul wunderbar.
Eine Frage noch: Ist das Attribut ghomename für das Modul verwendbar? Welches Attribut hat dann denn Vorrang? Alias oder ghomename.
Gruß
Hermann
In der letzten Version wird folgendes verwendet...
1. gassistantName
2. assistantName
3. alias
4. NAME
ghomeName ist noch aus einer alten Version und kann gelöscht werden.
Ich habe gerade ein paar Sachen gefixt, folgendes sollte nun wieder funktionieren:
- Jalousie (bitte auch ohne homebridgeMapping probieren)
- Scene
- StartStop (Xiaomi Vacuum)
- Fehlermeldung "I'm sorry, there was an error and I'm unable to control your home device" wenn im Code in Fehler passiert. Bitte solche Fehler melden.
Update ist nicht notwendig, da diese Logik im Firebase Projekt liegt.
justme1968 hat gerade das Modul für gassistant-fhem fertiggestellt. Großes Danke dafür! :)
Ihr findet das Modul zum Testen hier:
https://forum.fhem.de/index.php/topic,96696.0.html
Bitte um Feedback ob alles funktioniert. Die Installation des Clients habe ich nun auch komplett über npm realisiert. Man muss also nicht mehr mein github Repository clonen.
Wie ist denn dein Plan für ghome-fhem? Wird es da auch noch Updates geben?
Falls du die "eigene" Installation meinst, dann nein.
Ich werde den gesamten Sourcecode (aus dem Firebase Projekt) ebenfalls publizieren. Wenn also jemand weiterhin eine eigenständige Lösung haben will, so kann das in einem eigenen Firebase Projekt angelegt werden.
Guten Abend,
Die Google Home/Assistant Integration hat wunderbar funktioniert. Ich kann nun mit meinen Handy per Sprache FHEM steuern.
Jetzt habe ich folgendes Problem. Weiter Familienmitglieder sollen ebenfalls per Handy Sprachbefehle an FHEM senden können. Jeder Teilnehmer hat seine eigene Emailadresse xxx@gmail.
Unter https://console.cloud.google.com/iam-admin/ kann ich nun diese Emaildressen ergänzen, aber mit Berechtigung ,,Bearbeiter, .." aber nicht als Inhaber.
Aber scheinbar muss man ,,Inhaber" sein um den FHEMconnector nutzen zu können.
Genauer:
Wenn ich unter https://console.cloud.google.com/iam-admin eine Emailadresse mit Rolle ,,Inhaber" ergänze wird eine Einladung an den Teilnehmer gesendet. Trotz Annahme der Einladung bleibt der Status bei ,,Annahme ausstehend" stehen.
Ändere ich die Rolle auf ,,Bearbeiter, Sucher, ..." verschwindet der Hinweis ,,Annahme ausstehend".
Egal was ich tue, im Google Home Menü ,,App einrichten" erscheint niemals [TEST] FHEMconnector.
Kennt jemand eine Lösung dafür?
Nutzt du den Test Action "[test] FHEM Connector Beta" oder wirklich die private Variante die hier im Thread (1. Post) beschrieben wurde?
Du kannst Nutzer einfach in der Home App in dein Zuhause einladen, dann koennen die auch alles nutzen.
In Deiner Homeapp weitere Familienmitglieder einladen.
Weitere Mitglieder in Google Home einladen hat geklappt! :)
Vielen Dank euch Beiden!
Ich möchte meine, bereits in FHEM eingebundenen Rollläden, ebenfalls mit ghome steuern.
Aber welcher devicetype kann ich dafür benutzen?
,,Switch" geht nur mit ON OFF. Nicht für UP DOWN STOP SHADE
attr Rolladen1 genericDeviceType ?????
attr publishSet Rolladen1 UP DOWN STOP SHADE cmd/jarolift/shutter/1
Hallo zusammen,
ich verzweifel gerade etwas mit der korrekten Konfiguration des reverse proxys...
Mein Setup:
- Fritzbox, welche Port 443 extern auf 443 intern zum raspberry pi leitet
- raspberry pi hat Apache2 mit Reverse Proxy am laufen - funktioniert auch mit fhem super (inkl. websockets, etc.)
- Ich habe für fhem und für googlehome zwei einzelne DynDNS
- Meine googlehome apache2-conf lautet wie folgt:
<IfModule mod_ssl.c>
<VirtualHost *.80>
ServerName SECRET.ddnss.de
Redirect / https://SECRET.ddnss.de
</VirtualHost>
<VirtualHost *:443>
ServerName SECRET.ddnss.de
ServerAdmin SECRET.ddnss.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/SECRET.ddnss.de.error.log
CustomLog ${APACHE_LOG_DIR}/SECRET.ddnss.de.access.log combined
SSLCertificateFile /etc/letsencrypt/live/SECRET.ddnss.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/SECRET.ddnss.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
ProxyTimeout 60
ProxyErrorOverride On
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
<Directory />
RedirectPermanent / /
</Directory>
</VirtualHost>
</IfModule>
Wenn ich dann die Domain https://SECRET.ddnss.de/ im Browser öffne, kommt:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.
Reason: Error reading from remote server
Apache/2.4.25 (Raspbian) Server at n5pxj8zh.ddnss.de Port 443
Wenn ich direkt die raspberry pi-IP inkl. Port 3000 im Heimnetz öffne, kommt:
Cannot GET /
Bzw. im Protokoll des ghome-service steht:
Mar 23 19:47:22 raspberrypi ghome[1271]: GET / 404 30.156 ms - 139
Mar 23 19:47:22 raspberrypi ghome[1271]: GET /favicon.ico 404 8.822 ms - 150
Apache2 error-log:
[Sat Mar 23 19:57:21.295316 2019] [proxy_http:error] [pid 1988:tid 1932518448] (20014)Internal error (specific information not available): [client CLIENTIP:52700] AH01102: error reading status line from remote server localhost:3000
[Sat Mar 23 19:57:21.295482 2019] [proxy:error] [pid 1988:tid 1932518448] [client CLIENTIP:52700] AH00898: Error reading from remote server returned by /
[Sat Mar 23 19:57:21.361773 2019] [proxy_http:error] [pid 1988:tid 1924125744] (20014)Internal error (specific information not available): [client CLIENTIP:52700] AH01102: error reading status line from remote server localhost:3000, referer: https://SECRET.ddnss.de/
[Sat Mar 23 19:57:21.381395 2019] [proxy_http:error] [pid 1989:tid 1940911152] (20014)Internal error (specific information not available): [client CLIENTIP:52701] AH01102: error reading status line from remote server localhost:3000, referer: https://SECRET.ddnss.de/
[Sat Mar 23 19:57:21.381555 2019] [proxy:error] [pid 1989:tid 1940911152] [client CLIENTIP:52701] AH00898: Error reading from remote server returned by /favicon.ico, referer: https://SECRET.ddnss.de/
Meine Schlussfolgerung:
- DynDNS funktioniert
- Port-forward Fritzbox funktioniert
- Apache2 conf falsch oder der service antwortet nicht korrekt
Kann mir wer weiterhelfen?
Zitat von: hkspks am 23 März 2019, 19:51:57
Kann mir wer weiterhelfen?
ja, alles nichtt mehr nötig. Hier gehts weiter
https://forum.fhem.de/index.php/topic,96696.0.html
Zur Info, die in diesem Thread beschriebene Anleitung wird von mir nicht weiter unterstuetzt. Natuerlich kannst du diese selbststaendig einrichten und weiter nutzen, neue Entwicklungen werde ich aber nicht mehr integrieren.
Daher empfehle ich auf das offizielle Modul umzusteigen:
https://wiki.fhem.de/wiki/Google_Assistant_FHEM_Connect
Da benoetigst du dann auch keinen offenen Port mehr.
Hallo Dominik,
habe den GoogleAssitant schon längere Zeit in Betrieb und habe jetzt auf die neue Version im Wiki umgestellt.
Habe eine farbige Aldi-Tint im Einsatz, die ich über fhem einwandfrei steuern kann. Leider habe ich es noch nicht geschafft, egal bei welcher Version von GoogleAssistant, Helligkeit oder Farbe über die Sprachsteuerung zu ändren. Es funktioniert nur Ein- und Ausschalten.
Hier die Definition der Lampe.
defmod Strahler MQTT2_DEVICE zigbee_0x00158d0003248906
attr Strahler userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr Strahler IODev mqtt2
attr Strahler alexaName strahler
attr Strahler alexaRoom elena
attr Strahler alias Strahler
attr Strahler devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr Strahler genericDeviceType light
attr Strahler icon hue_filled_white_and_color_e27_b22
attr Strahler model L_02b_zigbee2mqtt_colorbulbWithoutColorTemp
attr Strahler readingList zigbee2mqtt/0x00158d0003248906:.* { json2nameValue($EVENT) }\
zigbee2mqtt2/0x00158d0003248906:.* { json2nameValue($EVENT) }
attr Strahler room GoogleAssistant,MQTT2_DEVICE,alexa
attr Strahler setList on:noArg zigbee2mqtt2/0x00158d0003248906/set {"state":"ON"}\
off:noArg zigbee2mqtt2/0x00158d0003248906/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,15,255 zigbee2mqtt2/0x00158d0003248906/set {"state":"on","$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 zigbee2mqtt2/0x00158d0003248906/set {"state":"on","$EVTPART0":"$EVTPART1"}\
color:colorpicker,RGB {"zigbee2mqtt2/0x00158d0003248906/set ".zigbee2mqtt_RGB2JSON($EVTPART1)}
attr Strahler stateFormat {lc ReadingsVal("$name","state",0)}
attr Strahler webCmd toggle:on:off:brightness:color:color_temp
setstate Strahler off
setstate Strahler 2019-02-25 17:59:45 associatedWith MQTT2_zigbee_hb
setstate Strahler 2019-03-24 22:31:35 brightness 120
setstate Strahler 2019-03-24 22:31:35 color_hue 46.7
setstate Strahler 2019-03-24 22:31:35 color_mode 2
setstate Strahler 2019-03-24 22:31:35 color_saturation 46.5
setstate Strahler 2019-03-24 22:31:35 color_temp 250
setstate Strahler 2019-03-24 22:31:35 color_x 0.382
setstate Strahler 2019-03-24 22:31:35 color_y 0.38
setstate Strahler 2019-03-24 22:31:35 linkquality 44
setstate Strahler 2019-03-24 22:31:35 state OFF
Fehlen mir noch irgendwelche Einstellungen oder funktioniert das noch nicht.
Gruß rippi
Guten Tag rippi46,
ansich funktioniert es schon, Leuchmittel die z.B. über eine Philips Hue Bridge und Fhem betrieben werden funktionieren ohne Probleme. Du verwendest allerdings Zigbee2MQTT, das Ganze ist im Moment einfach noch nicht implementiert worden also es liegt nicht an deinen Einstellungen oder sowas. Ich hatte es mir auch schon gewünscht, irgendwo auf einer Liste hat Dominik das sicherlich auch vermerkt aber es sind halt noch genug andere Dinge die er im Moment bearbeitet und da die Verwendung von Zigbee2MQTT nicht so hoch zu sein scheint ist es halt noch auf seiner Wunschliste etwas weiter unten. Ich denke aber zu lange wird es nicht mehr dauern und dann gehen die Leuchtmittel auch irgendwann in Verbindung mit dem Google Assistant Modul. Ich hoffe das hat deine Frage soweit beantwortet ;D
LG Richard
Hallo Richard,
danke für die schnelle Antwort.
Dann muß ich vielleicht einfach noch warten bis es integriert ist.
Vermutlich ist der Programmieraufwand doch zu groß, als dass man das unterstützen könnte?
Gruß rippi
Hey rippi,
ZitatVermutlich ist der Programmieraufwand doch zu groß, als dass man das unterstützen könnte?
Das kann nur Dominik einschätzen, aber er ist wirklich schon schnell bei dem was er macht, ich denke mal ein wenig Zeit braucht es noch, aber es wird kommen (;
Ich will ihm da auch keinen Druck machen, weil wie gesagt klar sind es bis jetzt nur wenige die Zigbee2MQTT nutzen und außerdem bin ich so schon wirklich extrem dankbar für seine ganze Arbeit und Mühe an dem Modul, es macht wirklich spaß das Ganze nun so fertig benutzen zu können ;D
LG Richard
Nutz jemand die Abläufe in GHome?
Ich habe seit neustem das Problem, dass wenn ich über einen Ablauf meine Geräte steure, das Google sagt "Es tut mir leid, ich kann die Lampe XXX im Moment nicht erreichen". Das seltsame ist, dass die Lampe trotzdem geschaltet wird und wenn ich die Lampe direkt anspreche kommt dieser Fehler nicht
Jup,
Ist bekannt und wurde im Gassistant Threat auch schon angesprochen. Der Fehler wird wohl auch in anderen Foren angesprochen und ist eher bei Google anzusiedeln.
Bis denn
SouzA
@rippi46
Gestern haben wir noch über Zigbee2MQTT Leuchtmittel geschrieben und gestern Abend ist Dominik dem Wunsch schon nachgekommen, noch ist es nicht ganz fertig und es fehlt und noch ein Reading mit dem er rausbekommt ob color oder color_temp aktiv ist aber sieht schonmal gut aus. Falls du das Ganze verfolgen möchtest usw. kannst du das auch in dem etwas aktuellerem Threat tun: https://forum.fhem.de/index.php/topic,96696.570.html
LG Richard
Ich hab neuerdings ein Problem mit meiner Heizungsteuerung und ghome. Hat bisher immer problemlos funktioniert, aber momentan werden alle Sprachbefehle zur Heizung einfach abgelehnt.
Wenn ich sage
"Hey Google, stelle Heizung auf 20 Grad" kommt als Antwort "Tut mir leid, diesen Modus gibt es auf der Heizung nicht".
Ebenso bei Anfragen wie "Hey Google, wie warm ist Heizung?" kommt "Ich kann die Heizung aktuell nicht erreichen. Bitte versuche es später nochmal".
In der Google-Home-App auf dem Android-Handy funktioniert alles wunderbar. Die Heizung wird angezeigt mit korrekten Werten und kann dort auch gesteuert werden.
Das Synchronisieren sieht so aus (mMn ok):
**** Start handling : "Heizung",
**** End handling device: : {"id":"CUL_HM_<gelöscht>","deviceInfo":{"manufacturer":"FHEM_CUL_HM","model":"HM-CC-RT-DN"},"name":{"name":"Heizung"},"traits":["action.devices.traits.TemperatureSetting"],"attributes":{"thermostatTemperatureUnit":"C","availableThermostatModes":"off,heat,on"},"customData":{"device":"bd_hmRtClima"},"willReportState":true,"roomHint":"Bad","type":"action.devices.types.THERMOSTAT"},
Bei den fehlschlagenden Sprachbefehlen kommen bei FHEM (bzw. ghome-fhem) überhaupt keine Anfragen an.
Das Ganze hat angefangen nachdem neulich der ganze Skill nicht mehr funktionierte und ich im Google Web-Dashboard das Testing erneut aktivieren musste. Mindestens seit dem besteht das Problem.
Hat jemand eine Idee evtl.? Oder kann jemand sagen, dass die Heizungsteuerung bei ihm weiterhin funktioniert (um ein Problem auf Google-Seite auszuschließen)?
Probier es mal mit
Hey Google, stelle DIE Heizung auf 20 Grad
Ich kann mir vorstellen, dass das mit der neuen Modes Implementierung von Google zusammen haengt.
Ok, danke für den Tipp. Leider selbes Ergebnis. "Tut mir leid. Diesen Modus gibt es auf der Heizung nicht". :-[
Funktioniert es mit FHEM Connect? Wenn ja, dann bitte um die Liste der Funktionen die du darin noch vermisst ;)
Hallo zusammen und ein gutes neues Jahr!
Bei mir klappt es bei HomeMatic und HM-CC-RT-DN bestens mit "Stelle die Temperatur [im Wohnzimmer] auf xx Grad"
Die Abfrage nach der aktuellen Einstellung mache ich mit "Wie warm ist es [im Wohnzimmer]"
Viele Grüße
Ferdinand
Hallo,
bei mir lief alles perfekt bis heute plötzlich die Geräte nicht mehr funktionierten.
Beim Aufruf von Google Home waren plötzlich alle FHEM-Geräte nicht mehr den Räumen zugeordnet. Das ließ sich natürlich in der Google Home App schnell erledigen.
Die Heizkörperthermostate lassen sich jedoch nicht mehr ansteuern oder verschieben. Sobald ich einen Thermostaten anklicke stürzt die Google Home App ab.
Gruß,
Mathias
Bitte FHEM Connect (https://forum.fhem.de/index.php/topic,96696.0.html) nutzen, die "alte Integration" wird von mir nicht mehr weiter entwickelt.
Hallo,
ich habe beim FHEM mehrere Shelly RGBWs mit Tasmota über MQTT2 intgriert.
FHEM erkennt diese sauber und kann diese steuren.
Bei Google bekomme ich aktuell nur ein / ausschalten und die Helligkeit hin.
Die Farbe kann ich nicht setzen.
Ich habe bereits mehrere MQTT2 Templates ausprobiert (tasmota_rgbw_controller, tasmota_rgbw_controller)
Was muss ich machen, damit ich die Farbe setzen kann?
Eigentlich sollte google das ja selbst erkennen.
VIele Grüße, Nils
Moin,
ich weiß das FHEM Connect verbindet FHEM mit dem Google Assistant, dadurch kann man die Geräte von Fhem aus Google Assistant steuern lassen!
nun ist mein Frage: geht das auch Rückwärts ? bzw. kann ich auch Geräte (Smart BLUB color Lampen) die kein zigbee sind aber Durch GoogleAssistant steuerbar sind auch in Fhem steuern ?
Danke!
Hi,
nein das ist nicht möglich.
Bis denn
SouzA