hallo zusammen,
chi-tai hat mich vorhin darauf aufmerksam gemacht das es inzwischen eine deconz beta version mit offiziellem push api gibt. darauf hin habe ich schnell eine test version der hue module zusammenkopiert die dieses websocket api unterstützt und er hat es nach ein paar bug fixes schon erfolgreich mit einer lampe getestet.
um das ganze auch mit sensoren und tastern zum laufen zu bekommen wäre es gut noch ein paar beta tester zu haben. vor allem da ich selber die deconz hardware zur zeit nicht aufgebaut habe :) und auch keine sensoren und taster habe.
sobald die version so weit ist poste ich sie hier im thread.
gruss
andre
anbei die aktualisierte version der hue module mit denen sich das deconz push api nutzen lässt.
chi-tai wird hier noch etwas zu dieser deconz version schreiben.
viel spass beim testen...
edit 2017-12-29: die module sind inzwischen eingecheckt.
Hallo Zusammen,
zuerstmal Danke an Andre für die Arbeit!
Die Module laufen zusammen mit deconz bei mir mit dem USB-Stick von deconz bisher ohne Probleme.
Für den Umstieg würde ich empfehlen vorher eine Sicherung der Konfiguration durchzuführen. Die deconz-config befindet sich im Nutzerverzeichnis unter dem deconz läuft, also:
~/.local/share/data/dresden-elektronik
Die Konfiguration meiner Push-Implementierung ist in "/usr/share/deCONZ". Dort die 2 oder 3 Dateien, die mit rest_ anfangen.
Die Websocket-API ist momentan nur in den Beta-Versionen verfügbar. Diese sind hier zu finden:
RPi: https://www.dresden-elektronik.de/rpi/deconz/beta/
Ubuntu: https://www.dresden-elektronik.de/deconz/ubuntu/beta/
Die Websocket-API ist in der aktuellsten Version von deconz verfügbar:
RPi: https://www.dresden-elektronik.de/rpi/deconz/deconz-latest.deb
Ubuntu: https://www.dresden-elektronik.de/funktechnik/products/software/pc/deconz/?eID=dam_frontend_push&docID=5343
Man braucht nur die entsprechende .deb zu installieren, z.B. per ssh auf den RPi und dann
> wget https://www.dresden-elektronik.de/rpi/deconz/deconz-latest.deb
> sudo dpkg -i deconz-latest.deb
> sudo apt install -f
( wie bei de beschrieben: https://github.com/dresden-elektronik/deconz-rest-plugin )
Die Installation erzeugt auch einen systemd-Eintrag mit dem man deconz beim Booten automatisch starten kann. Hier sollte man darauf achten, dass ein geeigneter Nutzer für deconz verwendet wird.
> sudo nano /etc/systemd/system/deconz.service
Dort steht standardmäßig "User=pi"
Tragt dort den Nutzer ein, welcher vorher für deconz verwendet wurde, damit die deconz-Konfiguration übernommen wird.
Der Dienst läuft auch automatisch "headless", d.h. es wird kein X-Server mehr benötigt.
Dort kann man auch mit "--http-port=80" den Port für deconz anpassen.
Falls man einen bestimmten websocketport haben möchte, dann "--ws-port=8888".
Und falls man upnp in deconz deaktivieren möchte, dann "--upnp=0"
Falls man Änderungen durchgeführt haben sollte, dann muss folgendes noch durchgeführt werden:
> sudo systemctl daemon-reload
Um deconz automatisch zu starten:
> sudo systemctl enable deconz
> sudo systemctl start deconz
Danach die Module von Andre in FHEM neuladen und die Websocket-API sollte automatisch Änderungen der Taster/Bewegungsmelder/Lichter/etc.. als Events an FHEM liefern und die Readings aktualisieren.
Falls jemand die Taster-Events aus meiner bisherigen Implementierung genutzt hat, dann gibt es hier ein paar kleine Änderungen:
Events zeichnen sich im "state" anstatt den bisherigen Readings ab.
Für Dim-Switches wird ein 4-stelliger code mit folgender Bedeutung gepushed:
1000 - On
2000 - dim up
3000 - dim down
4000 - Off
xxx1 - press hold
xxx3 - press hold released
xxx2 - press released
Für Tap-Switches entspricht die Bedeutung der Zahl im state der bisherigen Bedeutung.
Ich hoffe mal, dass ich nichts vergessen habe ;D
Aufgrund meiner bisherigen Erfahrung empfehle ich die Nutzung der neuen Module. Die bisherige Push-Implementierung von mir werde ich nicht mehr weiterpflegen.
Update: Aktuelle Beta von deconz 2.04.99.
Update: Die Betas sind mit Vorsicht zu "genießen" und "hängen" gelegentlich.
Gruss,
Chi-Tai
gibt es schon irgendwelche erkenntnisse ?
Hmmm, gerade habe ich meine 3 Testsysteme auf eins eingedampft :)
Und schon gäbe es wieder was zu testen/ausprobieren ;)
Mal sehen, ob ich Zeit finde...
...PIs hätte ich ja jetzt wieder "über" ;)
Gruß, Joachim
Also die HUE-Module laufen bei mir seit ein paar Tagen ohne Probleme mit der aktuellsten Beta von deconz. Die Websocket-Verbindung wird zwar hin und wieder neu aufgebaut, aber das könnte am Beta-Status von deconz liegen. Bisher also nichts katastrophales :-)
Gruss,
Chi-Tai
deCONZ ist übrigens seit 2.04.97 aus der Beta raus und auch als deconz-latest.deb (https://www.dresden-elektronik.de/rpi/deconz/deconz-latest.deb) auf der Dowloadseite. Aktuell ist 2.04.99.
Da ich momentan eh Ärger mit meinem Lightify Gateway habe, werde ich meinen RaspBee mal wieder aktivieren.
Guten Morgen,
aktuell gelingt es mir noch nicht Sensoren ins FHEM zu holen. Es geht um:
- Xiaomi Aqara Temperatur/Luftfeuchtigkeit
- Philips Hue Bewegungsmelder
Beide Geräte sind in der Phoscan App zu sehen und liefern auch entsprechende Werte. In FHEM wird das deCONZ-Device als Connected angezeigt, siehe Screenshots.
Die beiden neuen Modulen vom 14.12.2017 wurden ins Modulverzeichnis von FHEM abgelegt und anschließend FHEM neugestartet.
Aktuell wird lediglich die "alle Lichtergruppe" aus deCONZ in FHEM angelegt.
Hat jemand eine zündende Idee?
Der Raspberry Pi3 läuft mit Stretch Lite.
sensor devices werden nicht per autocreate angelegt. d.h. du musst sie von hand anlegen:
- get <bridge> sensors
- deffine <name> HUEDevice S <id>
siehe wiki.
Danke für die rasche Antwort, auf den Befehl get Interface.ZigBee sensors
erhalte ich lediglich ein leeres Fenster.
Im FHEM-Log steht, dass der Verbindungsversuch fehlschlägt:
2017.12.20 11:51:47 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/sensors: Select timeout/error:
2017.12.20 11:51:47 3: HUEBridge_Call: failed, retrying
2017.12.20 11:51:51 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/sensors: Select timeout/error:
2017.12.20 11:51:51 3: HUEBridge_Call: failed, retrying
2017.12.20 11:51:51 3: HUEBridge_Call: failed
2017.12.20 11:52:10 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/sensors: Select timeout/error:
2017.12.20 11:52:10 3: HUEBridge_Call: failed, retrying
2017.12.20 11:52:14 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/sensors: Select timeout/error:
2017.12.20 11:52:14 3: HUEBridge_Call: failed, retrying
2017.12.20 11:52:14 3: HUEBridge_Call: failed
2017.12.20 11:52:20 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/lights: Select timeout/error:
2017.12.20 11:52:20 3: HUEBridge_Call: failed, retrying
2017.12.20 11:52:24 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/ff3237fc0f99d671****/lights: Select timeout/error:
2017.12.20 11:52:24 3: HUEBridge_Call: failed, retrying
2017.12.20 11:52:24 3: HUEBridge_Call: failed
Über den Port 80 ist jedoch die Anwendung erreichbar. Muss noch irgendwo ein Passwort hinterlegt werden oder ähnliches?
Hi LordVoodoo,
nach dem letzten Update der deConz Software hatte ich bei mir ein ähnliches Problem.
Bei mir wurde anscheinend der API Key beim Update in deConz verworfen.
Kannst du testen in dem du mal den http request in deinem Browser eingibst. Bei mir kam an dieser Stelle dann "Permission denied".
Gelöst habe ich das in dem ich den api gelöscht habe. und im deconz das Gateway einmal auf Unlock gestellt habe.
Anschließend purzelten bei mir alle Geräte rein die vorher nicht da waren.
Mfg
Zitat von: mahowi am 20 Dezember 2017, 08:06:47
deCONZ ist übrigens seit 2.04.97 aus der Beta raus und auch als deconz-latest.deb (https://www.dresden-elektronik.de/rpi/deconz/deconz-latest.deb) auf der Dowloadseite. Aktuell ist 2.04.99.
Danke für den Hinweis! Hab gleich mal die Links im Post aktualisiert.
Hallo zusammen,
nach einem Löschen des Attributes von "key" habe ich das Gateway nochmal für 60 Sekunden "unlocked" geschalten und kurze Zeit später stand ein neuer Key in den Attributen, aber nach wie vor sagt das Log, dass ein Zugriff auf das Device nicht möglich ist.
Nach wie vor:
2017.12.20 18:22:42 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/3693a8c1e2e13da5e7***/config: Select timeout/error:
2017.12.20 18:22:42 3: HUEBridge_Call: failed, retrying
2017.12.20 18:22:46 1: HUEBridge_HTTP_Request http://127.0.0.1:80/api/3693a8c1e2e13da5e7***/config: Select timeout/error:
2017.12.20 18:22:46 3: HUEBridge_Call: failed, retrying
2017.12.20 18:22:46 3: HUEBridge_Call: failed
2017.12.20 18:22:46 2: HUEBridge_OpenDev: got empty config
Übernehme ich die Request-URL in den Browser, dann erhalte ich:
[{"error":{"address":"api/3693a8c1e2e13da5e7***/sensors","description":"unauthorized user","type":1}}]
Ich habe keine Möglichkeit gesehen, einen User anzugeben.
Zitat von: LordVoodoo am 20 Dezember 2017, 18:27:22
Übernehme ich die Request-URL in den Browser, dann erhalte ich:
[{"error":{"address":"api/3693a8c1e2e13da5e7***/sensors","description":"unauthorized user","type":1}}]
Ich habe keine Möglichkeit gesehen, einen User anzugeben.
Das Problem hatte ich auch mal und zuerst dachte ich es wäre der auth-key. Bei mir war es die Installation von dem .deb, welches anscheinend auch die Systemd-config ersetzt
/etc/systemd/system/deconz.service
und somit wieder der user "pi" und die Konfiguration im Home-Verzeichnis von "pi" verwendet.
deconz läuft bei mir allerdings mit einem anderen Nutzer, sodass die "richtige" Konfiguration nicht verwendet wird und somit auch der auth-key nicht gültig war.
Anscheinend muss man aktuell die systemd-config immer vorher sichern und nach der Installation wieder zurücksichern.
Allerdings kann ich mir auch nicht erklären, warum bei dir mit dem neuen auth-key auch kein connect zustande kommt.
Evtl. nochmal öffnen und "pairen"?
Um sicher zu gehen, dass es "sauber" ist: von der Webapp und/oder Phoscon vorher ausloggen und wieder neu einloggen.
Gruss,
Chi-Tai
Hallo zusammen,
inzwischen ist eine Verbindung geglückt, nötig war:
attr Interface.ZigBee httpUtils 1
Nach anschließendem Löschen des API Keys aus FHEM und neu verbinden, funktionieren die Gerät und deren Erkennung. Die Geräteerstellung funktionierte dann via:
define Device.Bad.Sensor.Temperatur HUEDevice sensor 7 1 IODev=Interface.ZigBee
define Device.Bad.Sensor.Feuchtigkeit HUEDevice sensor 8 1 IODev=Interface.ZigBee
define Device.Bad.Sensor.Druck HUEDevice sensor 9 1 IODev=Interface.ZigBee
Die zugehörigen Nummern konnten über get Interface.ZigBee sensors
ermittelt werden.
Allerdings wird noch kein Luftdruck ausgegeben. Sieht da jemand Werte?
wenn du das push api verwendest sollte es nicht nötig sein jede sekunde zu pollen.
zeig mal ein list vom luftdruck sensor und die ausgabe von http://<ip>/api/<key>/sensors/9
Dieses Ergebnis bekomme ich beim Aufruf des Gerätes im Browser:
{"config":{"on":true,"reachable":true},"ep":1,"etag":"861f098190b82ac6d46024243cfc64d8","manufacturername":"LUMI","modelid":"lumi.weather","name":"Device.Sensor.Bad.Luft","state":{"lastupdated":"2017-12-21T10:29:07","pressure":1013},"type":"ZHAPressure","uniqueid":"00:15:8d:00:02:01:b6:f8-01-0403"}
Wie führe ich ein List vom Sensor durch?
Ferner zeigt sich noch ein Unterschied zur bisherigen XIAOMI-Gateway-Einbindung: Das Attribut stateFormat wird nicht dauerhaft übernommen. Sobald ich es setze, z.B. "attr Device.Bad.Sensor.Feuchtigkeit stateFormat humidity" steht im Browser der gewünschte Wert, aber kurze Zeit später taucht wieder das unschöne Fragezeichen auf.
der druck wird im nächsten update mit angezeigt. wenn du nicht waren magst kannst du in 31_HUEDevice nach zeile 1251 noch die folgende zeile einfügen:$readings{pressure} = $state->{pressure} if( defined($state->{pressure}) );
ein list bekommst du mit dem list kommando.
das modul schreibt unknown nach STATE wenn es einen lese fehler vom gateway gibt. schau mal im log ob d etwas siehst. beim nächsten erfolgreichen lesen sollte wieder der korrekte wert dort stehen.
undef taucht auch kurz auf wenn du httpUtils auf 2 gesetzt hast.
So.. endlich den HUE Motion Sensor zum laufen gebracht. (hoffe ich)
Problem war... hin und wieder kamen Daten rein, aber nicht zuverlässig.
Bin dann wieder von 2.04.99 auf 2.04.97 runter.
Was ich noch nicht ganz verstehe.
Bisher den Autostart über
> sudo systemctl enable deconz
ausgeführt.
Webinterface und Rest Api liefen.
für was ist dann
sudo systemctl start deconz
weiteres Problem.
wenn ich über vnc die GUI starte ist diese dann nicht mit dem Raspbee verbunden.
Muss dann jedes mal erst
> sudo systemctl disable deconz
reboote nund dann findet die gui das Modul
Hallo Teamdrachen,
Zitat von: Teamdrachen am 22 Dezember 2017, 19:58:21
Bisher den Autostart über
> sudo systemctl enable deconz
ausgeführt.
Webinterface und Rest Api liefen.
Mit diesem Kommando sorgst du dafür, dass deconz beim Booten als Dienst startet.
Zitat von: Teamdrachen am 22 Dezember 2017, 19:58:21
für was ist dann
sudo systemctl start deconz
Damit startest du den Dienst manuell.
Zitat von: Teamdrachen am 22 Dezember 2017, 19:58:21
weiteres Problem.
wenn ich über vnc die GUI starte ist diese dann nicht mit dem Raspbee verbunden.
Muss dann jedes mal erst
> sudo systemctl disable deconz
reboote nund dann findet die gui das Modul
Ich bin mir nicht sicher, ob ich dein Problem richtig verstanden habe.
Der Dienst startet standardmäßig ohne GUI. (Nur WebApp u. Phoscon als UI)
Wenn du dann deconz in einer X-Session startest, dann ist das Modul vermutlich schon belegt durch den Dienst der beim Booten gestartet wird.
Wenn du die GUI auf einer X-Session benötigst, dann darf der Dienst nicht laufen und du kannst deconz in dieser X-Session starten.
Du musst übrigens nicht neu booten nach einem
> sudo systemctl stop deconz
Danach sollte das Modul wieder verfügbar für eine X-Session sein.
Also lag ich doch richtig mit meiner Vermutung
sudo systemctl stop deconz
Keine Ahnung wieso es jetzt funktioniert... hatte es x mal versucht und jedes mal war das Modul schon belegt.
Analog zum HUE Motion Sensor ... nach dem 27 Versuch lüppte der erst.
Irgendwie hat mein Raspi wohl ein Eigenleben....
Gleich mal raspibackup anwerfen
Zitat von: Teamdrachen am 22 Dezember 2017, 22:38:38Irgendwie hat mein Raspi wohl ein Eigenleben....
Gleich mal raspibackup anwerfen
Mit einer der Beta-Versionen hat sich deconz bei mir mal aufgehängt und konnte nicht beendet werden, selbst mit einem kill oder den "Brachialmethoden" nicht.
Normalerweise sollte aber ein "sudo systemctl stop deconz" deconz auch stoppen.
du kannst das danach überprüfen mit
> ps aux | grep deconz
Grüße,
Chi-Tai
Lag wohl an der 99 Beta. Der konnte selbst ein "Kill" nix anhaben , hatt sich dann einfach wieder neu gestartet
Mit der 2.04.97 scheint es stabil zu laufen. Lightify, HUE, Tradfri alle vertragen sich miteinander.
Der HUE Motion Sensor liefert auch alle 3 Werte Temp, Lux, Motion nahezu Verzögerungsfrei und die Phoscon Rules laufen.
GUI wird eigentlich erst so richtig interessant wenn die OTA Files verfügbar sind. Ein paar sollen es ja mit Tradfri schon geschafft haben.
Jetzt noch ein paar GU10 RGBW zu vernünftigen Preisen und irgendwann mal eine Zigbee Version vom ESP8266 ;D
Bis die Xiaomi Motion und Temperatur Sensoren eintreffen kann ich mich ja erst mal um den KaminFeuer Effekt kümmern
Zitat von: Teamdrachen am 23 Dezember 2017, 10:48:00
Lag wohl an der 99 Beta. Der konnte selbst ein "Kill" nix anhaben , hatt sich dann einfach wieder neu gestartet
Eventuell wurde "nur" im Startscript was geändert, also eine Überprüfung mit autom. Neustart...
Gruß, Joachim
wenn keine einwände kommen werde ich die module demnächst mit diesem stand einchecken.
Keine Einwände hier.
Mittlerweile konnte ich auch eine neue Steckdose ins ZigBee-Netzwerk einbinden und konnte kein "added"-Event in den Logs sehen. Vielleicht kann jemand anders hier noch beitragen.
Falls das "added"-Event für etwas anderes verwendet wird (statt ein neu hinzugefügtes Gerät zu signalisieren), dann wäre es evtl. sicherer die Behandlung des Events mit autocreate vorerst auszukommentieren.
Grüße,
Chi-Tai
ich habe die module mal so wie sie sind eingecheckt.
Zitat von: justme1968 am 29 Dezember 2017, 19:58:49
ich habe die module mal so wie sie sind eingecheckt.
Mist! ;)
Hab sie eben noch runter geladen...
Hab ja über Weihnachten meine Testsysteme etwas konsolidiert und daher ein paar PIs "über"...
Einen davon hab ich eben zu einer (weiteren) HUE-Bridge mittels RaspBee und deCONZ inkl. push hochgezogen...
...werde jetzt dann mal auf meinem fhem Testsystem die Module in Betrieb nehmen (kopiert sind sie ja schon ;) )...
Erst mal mit einer Osram Lightify die ich noch "rumliegen" habe...
Und dann muss ich mal schauen wie ich meine HUEs von der "alten" Bridge (deCONZ 2.04.35) auf die neue "umziehe" und dann wie ich das dann wieder generell in meinem Hauptsystem zum Laufen kriege (wie es jetzt ist)...
Aber vorher muss ich noch weitere Funktionen von der alten Bridge auf die neue "umziehen" (z.B. meinen CO2)...
...aber so ohne XServer etc. gefällt mir das jetzt schon deutlich besser!
Vielen Dank!
Gruß, Joachim
So Module aus dem Post eingespielt, reload und nun funktioniert meine "alte" Bridge nicht mehr mit fhem!
Folgendes ist im Log zu finden:
2017.12.29 20:22:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:23:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:24:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:25:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:26:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:27:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347: malformed or unsupported URL
2017.12.29 20:28:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:29:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:30:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:31:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:32:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:33:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347: malformed or unsupported URL
2017.12.29 20:34:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:35:26 1: Perfmon: possible freeze starting at 20:35:25, delay is 1.212
2017.12.29 20:35:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:36:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:37:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:38:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:39:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347: malformed or unsupported URL
2017.12.29 20:40:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:41:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:42:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:43:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:44:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:45:26 1: Perfmon: possible freeze starting at 20:45:25, delay is 1.189
2017.12.29 20:45:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347: malformed or unsupported URL
2017.12.29 20:46:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:47:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:48:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:49:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
2017.12.29 20:50:34 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights: malformed or unsupported URL
Mit verbose=5 bei HueBridge und HueDevice sagt auch nicht mehr...
2017.12.29 20:57:07 4: using HttpUtils_NonblockingGet: PUT lights/3/state
2017.12.29 20:57:07 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights/3/state: malformed or unsupported URL
2017.12.29 20:57:11 4: using HttpUtils_NonblockingGet: PUT lights/3/state
2017.12.29 20:57:11 2: RaspBee: http request failed: http:///api/9ecbe4bb352c6668589cc6e22b48a347/lights/3/state: malformed or unsupported URL
EDIT: ziehe (erst mal) zurück! Nach einem shutdown restart geht es offenbar (doch)... Sorry!!
Gruß, Joachim
Hallo Joachim,
Zitat von: MadMax-FHEM am 29 Dezember 2017, 20:13:46
Und dann muss ich mal schauen wie ich meine HUEs von der "alten" Bridge (deCONZ 2.04.35) auf die neue "umziehe" und dann wie ich das dann wieder generell in meinem Hauptsystem zum Laufen kriege (wie es jetzt ist)...
Aber vorher muss ich noch weitere Funktionen von der alten Bridge auf die neue "umziehen" (z.B. meinen CO2)...
...aber so ohne XServer etc. gefällt mir das jetzt schon deutlich besser!
ich bin mir nicht sicher, ob es dir hilft. Zum Umziehen reichte es bei mir lediglich die alte deconz-config-files "wiederzuverwenden". Also in deinem Fall sollten es alle Dateien in folgendem Ordner sein:
~/.local/share/data/dresden-elektronik
(je nachdem unter welchem Nutzer deconz vorher bei dir lief bzw. laufen wird).
Ich hatte bei mir den ConBee-USB-Stick verwendet bzw. wiederverwendet. Evtl. funktioniert es nicht, wenn ich einen anderen ConBee-Stick verwendet hätte.
Grüße,
Chi-Tai
Hallo Chi-Tai,
vielen Dank!
Allerdings hab ich auch ein neues RaspBee Modul inkl. neuem PI und nun statt Jessie auch Stretch (also alles parallel neu ;) ), was "merkt" sich denn die HUE-Lampe bzw. was "sagt" ihr, dass das "ihre" Bridge ist?
Steht das auch in den Config-Dateien?
Die "neue HUEBridge" muss ich dann neu in fhem einbinden?
Oder steht der "Verbindungs-Key" auch in den Config-Dateien?
Oder ich schau einfach mal rein was drin steht ;)
Allerdings so viele Lampen habe ich ja (noch) nicht, da kann ich auch von vorne anfangen... ;)
Habe ich wieder ein "sauberes" System... :)
Gruß, Joachim
Hallo Joachim,
Zitat von: MadMax-FHEM am 29 Dezember 2017, 21:56:50
was "merkt" sich denn die HUE-Lampe bzw. was "sagt" ihr, dass das "ihre" Bridge ist?
Steht das auch in den Config-Dateien?
Die Config-Dateien enthalten die Konfiguration des gesamten ZigBee Netzwerkes inkl. Gerätekonfig in deconz. Allerdings identifizieren sich die Geräte mit MAC-Adressen und dein neues RaspBee könnte aufgrund der neuen MAC-Adresse nicht mehr Teil des Netzwerkes sein..
Wäre allerdings hilfreich zu wissen ob bzw. dass es nicht funktioniert...
(Vielleicht "rekonfiguriert" deconz das Netzwerk von selbst, da ja offensichtlich das Gateway zum Netzwerk anders ist...)
Zitat von: MadMax-FHEM am 29 Dezember 2017, 21:56:50
Die "neue HUEBridge" muss ich dann neu in fhem einbinden?
Oder steht der "Verbindungs-Key" auch in den Config-Dateien?
Der ist auch Teil der Konfiguration.
Zitat von: MadMax-FHEM am 29 Dezember 2017, 21:56:50Oder ich schau einfach mal rein was drin steht ;)
Das kann haarig werden hehe.. die zcl ist binär aber auch ganz aufschlussreich..
Grüße,
Chi-Tai
ich glaube beim umstellen auf eine neue bridge ist es immer das beste vorher zu versuchen die neue bridge ins alte netz zu bekommen. zumindest bei der hue bridge geht das ziemlich gut mit einer living colors fernbedienung. und danach die alte bridge einfach zurück zu setzen. dadurch musst du die ganzen birnen nicht neu anlernen.
ach ja, ganz wichtig. Die Dateiberechtigungen anpassen, sonst mag deconz nicht.
sudo chown -R newuser ~/.local/share/data/dresden-elektronik
sudo chmod -R u+rwx ~/.local/share/data/dresden-elektronik
Hi Chi-Tai, Andre,
vielen Dank!
Jetzt werde ich erst mal die neue "deCONZ-Bridge" ins Testsystem aufnehmen und da dann mal die Lightify integrieren, die noch "über" ist...
...und dann den "neuen" deCONZ-PI auf den Stand bringen, damit dann alle Funktionen die der "alte" deCONZ-PI hat auch zur Verfügung stehen...
Und dann werde ich sehen wie ich das nächstes Jahr dann mache ;)
Gruß, Joachim
Hi,
bin relativ neu hier und habe inzwischen eine Tradfri Lampe und Schalter in deconz eingebunden. Die Lampe lässt sich auch per fhem schalten, aber der Tradfri-Taster läuft nicht. Egal ob mit oder ohne Intervall, ich bekomme keine Rückmeldungen vom Taster. Bei state steht initialized. Ich habe fhem geupdated, reicht das um die deconz push api zu nutzen?
Grüße
Sascha
Zitat von: MadMax-FHEM am 29 Dezember 2017, 23:49:19
Hi Chi-Tai, Andre,
vielen Dank!
Jetzt werde ich erst mal die neue "deCONZ-Bridge" ins Testsystem aufnehmen und da dann mal die Lightify integrieren, die noch "über" ist...
...und dann den "neuen" deCONZ-PI auf den Stand bringen, damit dann alle Funktionen die der "alte" deCONZ-PI hat auch zur Verfügung stehen...
Und dann werde ich sehen wie ich das nächstes Jahr dann mache ;)
Gruß, Joachim
So ich hab den Test jetzt abgekürzt ;)
Ich hab einfach mal die HUE-Iris (da das momentan die einzige HUE ist, die ich echt nutze) von der bestehenden RaspBee-Hue-Bridge (deCONZ 2.04.35) "abgelernt" (Touchlink) -> funktioniert.
Dann an neue Bridge (deCONZ 2.04.99) angelernt und entsprechend benamst -> funktioniert.
Dann auf dem Testsystem die alte Bridge, Groups und Devices "gelöscht" (gut nur auskommentiert, sicher ist mal sicher)...
Neue Bridge angelegt laut Wiki (https://wiki.fhem.de/wiki/Hue):
define RaspBee HUEBridge 192.168.1.90
Dann "den Knopf gedrückt", also: "Unlock Gateway", damit ging das Modul dann von pairing auf paired...
...und ich dachte: passt. Also "save config" und
set RaspBee autocreate
Dann wurden zwar Devices angelegt aber irgendwie "eigenartig":
Zu Beginn die "No route to host" war als ich meine alte Bridge "abgedreht" hatte, ist also "ok" ;)
2018.01.02 11:50:19 2: RaspBee: http request failed: 192.168.1.93: No route to host
2018.01.02 11:50:19 2: RaspBee: http request failed: 192.168.1.93: No route to host
2018.01.02 11:50:19 2: RaspBee: http request failed: 192.168.1.93: No route to host
...
2018.01.02 12:13:16 1: HUEBridge_HTTP_Request http://192.168.1.90/api: Select timeout/error:
2018.01.02 12:13:16 3: HUEBridge_Call: failed, retrying
2018.01.02 12:13:20 1: HUEBridge_HTTP_Request http://192.168.1.90/api: Select timeout/error:
2018.01.02 12:13:20 3: HUEBridge_Call: failed, retrying
2018.01.02 12:13:20 3: HUEBridge_Call: failed
2018.01.02 12:13:24 1: HUEBridge_HTTP_Request http://192.168.1.90/api/328bae7616f3065c1901cfef2fe41bd8/config: Select timeout/error:
2018.01.02 12:13:24 3: HUEBridge_Call: failed, retrying
2018.01.02 12:13:28 1: HUEBridge_HTTP_Request http://192.168.1.90/api/328bae7616f3065c1901cfef2fe41bd8/config: Select timeout/error:
2018.01.02 12:13:28 3: HUEBridge_Call: failed, retrying
2018.01.02 12:13:28 3: HUEBridge_Call: failed
2018.01.02 12:13:28 2: HUEBridge_OpenDev: got empty config
2018.01.02 12:13:28 1: Perfmon: possible freeze starting at 12:13:13, delay is 15.537
2018.01.02 12:13:28 2: HarmonyHub: disconnect
2018.01.02 12:13:30 3: HarmonyHub: connected
2018.01.02 12:13:32 3: HarmonyHub: new config
2018.01.02 12:14:09 3: RaspBee_HUEDeviceerror: I/O device is RaspBee
2018.01.02 12:14:09 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/30_HUEBridge.pm line 1094.
2018.01.02 12:14:09 3: RaspBee_HUEGroup0: I/O device is RaspBee
2018.01.02 12:14:10 3: RaspBee_HUEGrouperror: I/O device is RaspBee
2018.01.02 12:14:10 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/30_HUEBridge.pm line 1126.
2018.01.02 12:14:10 2: RaspBee: autocreated 3 devices
2018.01.02 12:14:10 3: unauthorized user
2018.01.02 12:14:10 2: RaspBee: message for unknow type received: lights/Gerror
2018.01.02 12:14:10 3: unauthorized user
2018.01.02 12:14:10 2: RaspBee_HUEGroup0: got wrong status message for RaspBee_HUEGroup0: $VAR1 = [
{
'error' => {
'description' => 'unauthorized user',
'address' => 'api/328bae7616f3065c1901cfef2fe41bd8/groups/0',
'type' => 1
}
}
];
2018.01.02 12:14:10 3: unauthorized user
2018.01.02 12:14:10 2: RaspBee: message for unknow type received: lights/error
2018.01.02 12:16:46 0: Server shutdown
Dann dachte ich ich starte mal neu...
2018.01.02 12:17:00 3: RaspBee_HUEDeviceerror: I/O device is RaspBee
2018.01.02 12:17:00 3: RaspBee_HUEGroup0: I/O device is RaspBee
2018.01.02 12:17:00 3: RaspBee_HUEGrouperror: I/O device is RaspBee
...
2018.01.02 12:17:10 3: unauthorized user
2018.01.02 12:17:10 2: RaspBee: message for unknow type received: lights/error
2018.01.02 12:17:10 3: unauthorized user
2018.01.02 12:17:10 2: RaspBee_HUEGroup0: got wrong status message for RaspBee_HUEGroup0: $VAR1 = [
{
'error' => {
'type' => 1,
'description' => 'unauthorized user',
'address' => 'api/328bae7616f3065c1901cfef2fe41bd8/groups/0'
}
}
];
2018.01.02 12:17:10 3: unauthorized user
2018.01.02 12:17:10 2: RaspBee: message for unknow type received: lights/Gerror
2018.01.02 12:18:10 0: Server shutdown
Hat aber auch nichts geändert...
(ach ja ein key-Attribut war vorhanden und gesetzt [und nat. gespeichert])
Dann hab ich irgendwann das Attribut gelöscht und von vorne (bin mir nicht sicher, ob [genau] der Logteil dazu gehört) und dann ging es...
2018.01.02 12:18:24 3: TestWebAPI: port 8088 opened
2018.01.02 12:18:24 3: RaspBee_HUEDeviceerror: I/O device is RaspBee
2018.01.02 12:18:24 3: RaspBee_HUEGroup0: I/O device is RaspBee
2018.01.02 12:18:24 3: RaspBee_HUEGrouperror: I/O device is RaspBee
2018.01.02 12:18:24 1: Including ./log/fhem.save
...
2018.01.02 12:18:24 3: TestWebAPI: port 8088 opened
2018.01.02 12:18:24 3: RaspBee_HUEDeviceerror: I/O device is RaspBee
2018.01.02 12:18:24 3: RaspBee_HUEGroup0: I/O device is RaspBee
2018.01.02 12:18:24 3: RaspBee_HUEGrouperror: I/O device is RaspBee
2018.01.02 12:18:24 1: Including ./log/fhem.save
...
2018.01.02 12:18:35 3: unauthorized user
2018.01.02 12:18:35 2: RaspBee: message for unknow type received: lights/error
2018.01.02 12:18:35 3: unauthorized user
2018.01.02 12:18:35 2: RaspBee_HUEGroup0: got wrong status message for RaspBee_HUEGroup0: $VAR1 = [
{
'error' => {
'description' => 'unauthorized user',
'type' => 1,
'address' => 'api/328bae7616f3065c1901cfef2fe41bd8/groups/0'
}
}
];
2018.01.02 12:18:35 3: unauthorized user
2018.01.02 12:18:35 2: RaspBee: message for unknow type received: lights/Gerror
2018.01.02 12:19:06 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 12:19:06 2: RaspBee: message for unknow group received: RaspBee-G1
2018.01.02 12:19:06 2: RaspBee: message for unknow device received: RaspBee-1
2018.01.02 12:19:06 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 11:19:06 GMT
2018.01.02 12:19:06 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 12:20:06 2: RaspBee: message for unknow device received: RaspBee-1
2018.01.02 12:21:06 2: RaspBee: message for unknow device received: RaspBee-1
2018.01.02 12:21:06 3: HUEDevice1: I/O device is RaspBee
2018.01.02 12:21:07 3: HUEGroup0: I/O device is RaspBee
2018.01.02 12:21:07 3: HUEGroup1: I/O device is RaspBee
2018.01.02 12:21:07 2: RaspBee: autocreated 3 devices
2018.01.02 12:25:06 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 12:25:06 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 11:25:06 GMT
2018.01.02 12:25:06 3: RaspBee: websocket: Switching Protocols ok
...
2018.01.02 12:33:37 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 12:33:37 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 11:33:37 GMT
2018.01.02 12:33:37 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 12:33:53 0: Server shutdown
2018.01.02 12:33:56 2: Perfmon: ready to watch out for delays greater than one second
2018.01.02 12:33:56 1: Including fhem.cfg
2018.01.02 12:33:56 3: telnetPort: port 7072 opened
2018.01.02 12:33:56 3: WEB: port 8083 opened
2018.01.02 12:33:56 2: eventTypes: loaded 1982 events from ./log/eventTypes.txt
2018.01.02 12:33:56 3: HM_UART device closed
2018.01.02 12:33:56 3: Opening HM_UART device /dev/ttyAMA0
2018.01.02 12:33:56 3: Setting HM_UART serial parameters to 115200,8,N,1
2018.01.02 12:33:56 3: HM_UART device opened
2018.01.02 12:33:57 3: HUEGroup0: I/O device is RaspBee
2018.01.02 12:33:57 3: HUEGroup1: I/O device is RaspBee
2018.01.02 12:33:58 3: HUEDevice1: I/O device is RaspBee
Allerdings hab ich immer noch solche Dinge im Log:
2018.01.02 13:10:08 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 13:10:08 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 12:10:08 GMT
2018.01.02 13:10:08 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 13:14:11 1: Perfmon: possible freeze starting at 13:14:10, delay is 1.166
2018.01.02 13:16:08 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 13:16:08 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 12:16:08 GMT
2018.01.02 13:16:08 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 13:22:08 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 13:22:08 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 12:22:08 GMT
2018.01.02 13:22:08 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 13:28:08 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 13:28:08 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 12:28:08 GMT
2018.01.02 13:28:08 3: RaspBee: websocket: Switching Protocols ok
2018.01.02 13:34:08 3: RaspBee: websocket opened to 192.168.1.90:443
2018.01.02 13:34:08 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: krQ31zzlyuQB1Z4qJzOnW34A2IY=
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Tue, 02 Jan 2018 12:34:08 GMT
2018.01.02 13:34:08 3: RaspBee: websocket: Switching Protocols ok
Beim Define hatte ich keinen Port angegeben (wie im Wiki)...
Letztes Mal (alte Bridge) hatte ich beim Define einen Port 80 mitgegeben...
define RaspBee HUEBridge 192.168.1.93:80
Sollte ich einen Port angeben?
Ist das (trotzdem) ok so?
Oder was muss/müsste ich für https tun?
EDIT: also ich hab jetzt mal den Port auch hier gesetzt... Kamen mir zu oft die Meldungen...Aber auf jeden Fall läuft es und die Rückmeldung, selbst wenn ich über Wireless-Light-Control schalte kommt sofort...
...gut ich habe jetzt keinen Vergleich zu vorher...
Das nur als Rückmeldung!
Ansosten wie immer: vielen Dank!
Läuft (bislang) prima mit der neuen Bridge!Auf dem Hauptsystem war es ähnlich, nicht ganz so hakelig, da ich ja schon wusste, dass was zu tun ist.
Aber auch da klappte es (gefühlt) erst als ich das key-Attribut gelöscht neu gestartet habe und parallel (gleichzeitig) den "Unlock Gateway" gedrückt hatte...Gruß, Joachim
Die 6 minütigen Logs hab ich trotz ''Port und Verbose 1 auch
2018.01.03 09:24:32 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: =
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Wed, 03 Jan 2018 08:24:32 GMT
2018.01.03 09:30:32 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: =
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Wed, 03 Jan 2018 08:30:32 GMT
2018.01.03 09:36:32 1: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: =
Server: deconz
Access-Control-Allow-Credentials: false
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Origin: *
Date: Wed, 03 Jan 2018 08:36:32 GMT
Ansonsten läuft das System mit 2.04.97 recht stabil
Stimmt, Porteintrag hat bei mir auch nicht geholfen...
Ansonsten: läuft...
Gruß, Joachim
da sind noch zwei log nachrichten übrig geblieben. die sollten ab morgen weg sein.
Hi Andre,
vielen Dank!
Trotzdem kurz (noch mal gefragt): Port angeben oder nicht oder egal?
EDIT: weiß grad nicht mehr warum ich bei meiner "alten" Definition den Port mit drin hatte... Hat sich da was im Wiki geändert? Mache es einfach wie beschrieben und nehm den Port wieder raus... ;)
Gruß, Joachim
den port mit anzugeben geht. ist aber nicht nötig wenn es eine standard installation auf port 80 ist.
Hallo Sascha,
Zitat von: sash583 am 01 Januar 2018, 14:28:52
Ich habe fhem geupdated, reicht das um die deconz push api zu nutzen?
Sind die Bedingungen, die in den ersten Posts genannt wurden, bei dir erfüllt?
Welche deconz-version wird verwendet?
Auf was für einem System läuft deconz (RPi, Ubuntu, Debian, Windows)?
Was sagen die Logs der Bridge in fhem (am besten mit verbose 5)?
Ein paar Angaben mehr und mögliche Hilfestellung wäre wesentlich leichter.
Grüße,
ct
Zitat von: sash583 am 01 Januar 2018, 14:28:52
aber der Tradfri-Taster läuft nicht. Egal ob mit oder ohne Intervall, ich bekomme keine Rückmeldungen vom Taster. Bei state steht initialized.
Also der Tradfri Schalter läuft im Prinzip bei mir. In deconz wird der ja als Gruppe eingebunden und in FHEM dann ebenfalls so angelegt. Aber dann kann man den als sensor anlegen, es wird dann im state ein 4-stelliger code wie unten beschrieben angezeigt (etwas anders als auf Seite 1).
Problem beim Tradfri Schalter: Er hat ja keine On und Off Taste sondern eine Toggle Taste, damit gibt es niemals einen off state (400x). Er bleibt eigentlich immer auf 1002 stehen oder eben auf einem dim code.
Für Dim-Switches wird ein 4-stelliger code mit folgender Bedeutung gepushed:
1000 - Toggle
2000 - dim up
3000 - dim down
4000 - Left
5000 - Right
xxx1 - press hold
xxx3 - press hold released
xxx2 - press released
Left und Right haben aber direkt anscheinend keine Funktion mehr. Über FHEM und ein notify kann man den Tasten aber ja eine Funktion geben. Damit ist der Tradfri Taster ja eine wirklich günstige Lösung.
Hallo zusammen,
kürzlich habe ich gesehen, dass es auch Stromzwischenstecker gibt, die eine Strommessung erlauben und ZigBee-Standard sind, aufgefallen sind mir:
- Heiman Zwischenstecker für 99 PLN (ca. 25 Euro) - https://smarthome24.pl/wtyczki-inteligentne/27-wtyczka-inteligentna-z-pomiarem-energii-5906874919019.html (https://smarthome24.pl/wtyczki-inteligentne/27-wtyczka-inteligentna-z-pomiarem-energii-5906874919019.html)
- Gewiss GWA1526 (Veröffentlichung im März zur "Light+Building"-Messe, sehr schlanker Stecker) - https://www.gewiss.com/ww/de/products/experience-catalogue/catalogs/series/product/power/90-am-range-modular-accessories/GWA1526 (https://www.gewiss.com/ww/de/products/experience-catalogue/catalogs/series/product/power/90-am-range-modular-accessories/GWA1526)
- Develco Smart Cable (ein Anschlussstecker, der sich in Stromkabel einbauen lässt) - https://www.develcoproducts.com/products/smart-relays/smart-cable/ (https://www.develcoproducts.com/products/smart-relays/smart-cable/)
Vor allem der schlanke GWA1526 und das Smart Cable haben es mir angetan, habe häufig das Problem, dass die Zwischenstecker benachbarte Stromplätze sperren oder Schraänke etwas zuweit im Raum stehen.
Sind schon Erfahrungen bekannt mit dem Auslesen des Stromverbrauches via DeConz / Philips Hue Bridge?
Viele Grüße.
Keines der drei Geräte ist jetzt auf Anhieb im Verkauf zu finden und es findet sich auch auf GitHub nix im Zusammenhang mit DeConz.
1. Kaufen
2. Einstecken und schauen was DeConz erkennt
3. Notfalls eine Anfrage an dresden elektronik auf GitHub stellen.
FHEM hängt erst ganz hinten dran und wertet einfach nur die Sensoren aus die über die REST-API geliefert werden.
Ob das HUE Modul Smart Energy Meter überhaupt unterstützt, wäre eher ein Fall für den HUE Thread.
Hab gerade Mal den Xiaomi Aqara Temperatur Sensor in Betrieb genommen. Für ca. 8 Euro bekommt man da einen schicken kleinen Sensor für Temperatur, Feuchte und Luftdruck. Allerdings bekommt man in Fhem für einen Hardware Sensor drei Devices die dann ein entsprechendes Reading haben, aber kein state (kann man dann natürlich mit stateformat anzeigen lassen). Schöner wäre da natürlich ein Device mit den drei Readings.
https://www.gearbest.com/access-control/pp_626702.html
Den Doppel Taster hab ich allerdings bisher nicht in Gang bekommen. Da warte ich Mal auf das nächste Update, da sollen ja ein paar Xiaomi Sachen besser laufen. Der Taster ist eine gute Lösung wenn man an einigen Stellen eine einfache Ein/Aus Lösung haben will.
https://www.gearbest.com/alarm-systems/pp_610095.html
die sensoren werden über das api als drei einzelne geräte gemeldet. im modul gibt es keine möglichkeit rauszufinden das sie zusammen gehören.
man könnte zwar überlegen das irgendwo noch von hand einzugeben, das wäre aber ein größerer umbau ohne wirklich erkennbaren vorteil. wer das wirklich braucht kann das auch per notify zusammen kopieren.
state kannst du dir mit einem userReading erzeigen.
Bei ESPEasy gibt es ja sowas wie combineDevices aber wenn es zuviel Aufwand ist dann ist es auch nicht dramatisch.
Die Anzeige des Wertes ist ja mit stateformat da, state brauche ich dann nicht unbedingt nochmal extra, ich kann ja die vorhandenen Readings nutzen. Die Tradfri Taster hatten halt beim Anlegen des Sensors automatisch ein state angelegt.
Seit heute gibt es ein Update auf Version 2.05.01
Der Xiaomi Aqara Taster läuft jetzt auch, es wird 1002 auf Taste 1 und 2002 auf Taste 2 ausgegeben. Allerdings ist er nur über das Rest API sichtbar, nicht in Deconz oder Phoscon, damit kann man "nur" über FHEM nutzen. Sonst auf jeden Fall eine optisch interessante Alternative wenn man nicht einen Hue oder Tradfri Taster an die Wand kleben will.
Wenn man beide drückt gibt es 3002 falls das jemand noch interessiert :)
Noch etwas anderes: Bei mir läuft eigentlich soweit alles ganz gut, habe jetzt aber zum ersten mal auch Lampen mit dem conbee verbunden und die Änderungen an denen werde nicht gepushed, muss ich hierfür noch etwas anpassen?
Guter Hinweis, die 3002 hatte ich noch nicht berücksichtigt.
Ansonsten ist der Status der Lampen in Fhem eigentlich immer sofort da, wenn ich z.B. über eine App einschalte.
Hm, muss ich wohl nochmal schauen woran das liegen könnte.
Habe Bewegungsmelder, Taster, Temperatursensoren etc. Die werden problemlos gepushed. Also alles was als Sensor definiert ist.
Lampenstatus bekomme ich nicht gepushed.
Update: Nochmal alles neu gestartet, nun bekomme ich bei Lampen on/off und pct Werte gepushed. Jetzt suche ich eine Lösung, dem Taster einen Doppelklick beizubringen. Die gefundenen DoIF Beispiele gehen irgendwie alle nicht. Per Sequenz wäre möglich, aber dann würde beim ersten Klick nicht direkt was passieren.
Hab gerade mal createGroupReadings getestet, im Gegensatz zu Hue Gruppen funktioniert das mit deCONZ Gruppen nicht besonders gut.
- die Attribute createActionReadings und createGroupReadings müssen in jeder Gruppe nochmal extra auf 1 gesetzt werden damit überhaupt Readings erzeugt werden, es reicht nicht das in der Bridge zu setzen
- es wird kein state Reading erzeugt
- schalten der Gruppe aus FHEM geht, über die deCONZ Weboberfläche geschaltet ändern sich die Readings allerdings nicht, nur all_on und any_on
@arallon: du must bei der sequence triggerPartial aktivieren
@sinus61: createGroupReadings und createActionReadings sind für deCONZ nicht getestet.
das verhalten von createGroupReadings das du beschreibst kann ich mir aber gerade nicht erklären.
zeig mal bitte ein list einer deCONZ gruppe.
createActionReadings ist eigentlich niemals sinnvoll. und funktioniert auch bei hue nicht so wie man das erwarten würde. am besten niemals benutzen.
Internals:
CHANGED
DEF group 1 IODev=HUEd
ID G1
INTERVAL
IODev HUEd
NAME HUEd_HUEGroup1
NR 616
STATE unknown
TYPE HUEDevice
class Other
desired 0
lights 4
name Test
type LightGroup
READINGS:
2018-02-11 12:57:08 all_on true
2018-02-11 12:57:08 any_on true
2018-02-11 12:13:24 bri 127
2018-02-11 12:13:24 colormode hs
2018-02-11 12:13:24 ct 0
2018-02-11 12:13:24 effect none
2018-02-11 12:13:24 hue 0
2018-02-11 12:15:52 onoff 0
2018-02-11 12:15:52 pct 0
2018-02-11 12:13:24 sat 127
2018-02-11 12:13:24 xy 0,0
helper:
bri 127
colormode hs
ct 0
devtype G
effect none
hue 0
onoff 0
pct 0
sat 127
update_timeout 1
xy 0,0
Attributes:
IODev HUEd
alias Test
color-icons 2
createGroupReadings 1
delayedUpdate 1
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
group HUEGroup
room HUEDevice
userattr createActionReadings:1,0 createGroupReadings:1,0
Zitat von: arallon am 10 Februar 2018, 19:42:03
Per Sequenz wäre möglich, aber dann würde beim ersten Klick nicht direkt was passieren.
Mit triggerPartial geht das, aber gerade mal getestet und richtig zuverlässig ist das nicht. Der einfache Klick wird so ohne Probleme ausgewertet, aber den Doppelklick richtig auszulösen muss man ganz schön trainieren. WAF = 0
Ergänzung zu der Sache mit den Gruppen:
Wenn ich die Gruppe in FHEM schalte steht im Internal lights die zugehörige Lampe, wenn ich in deCONZ die Gruppe schalte ist danach das Internal lights in FHEM leer.
was genau geht an triggerPartial nicht?
wenn deCONZ die lichter der gruppe nicht immer mitliefert ist das vermutlich das problem.
schalter mal verbose auf 5 und schau ob in den antworten lights leer ist oder überhaupt nicht vorkommt.
dann kannst du mal in 31_HUEDevice.pm die zeile 1113 if( $result->{lights} ) {
durch1113 if( defined($result->{lights}) ) {
ersetzen. wenn das noch nicht reicht lösch mal die zeile 1116 $hash->{lights} = '';
Also das mit dem partial habe ich ja angeschaut, aber das habe ich so verstanden, dass es wenn nach z.b 1 sekunde nichts mehr gedrückt wurde, dann wird partial_1 ausgegeben, einen direkten 2ten klick kann man dann gar nicht mehr auswerten.
Auch wenn es heir Off-Topic ist, Hintergrund ist, dass ich beim ersten Drücken ein kleineres Licht einschalten möchte und beim nochmaligen drücken innerhalb x Sekunden ein weiteres helleres Licht einschalten (zusätzlich) will. Für mich habe ich das nun so gelöst, dass ich eine Routine habe, die via notify für alle Taster Events aufgerufen wird (für alle Taster). Dort wird auf das notify ein Reading gepackt für das Device + Event, das wird nach x Sekunden wieder auf "off" gesetzt. Wird jetzt nochmal gedrückt, dann kann ich das prüfen und etwas anderes starten.
Zitat von: arallon am 12 Februar 2018, 00:10:35
wenn nach z.b 1 sekunde nichts mehr gedrückt wurde, dann wird partial_1 ausgegeben, einen direkten 2ten klick kann man dann gar nicht mehr auswerten.
Also bei meinem Versuch gab es wohl partial_1 nach dem ersten Klick und trigger nach dem Doppelklick. Ich hatte aber auch 0.5 sek eingestellt und es hat selten funktioniert, möglicherweise kann die Push API oder der Taster das in der Zeit nicht immer korrekt an FHEM liefern.
Zitat von: justme1968 am 11 Februar 2018, 22:04:39
dann kannst du mal in 31_HUEDevice.pm die
Ich habe zwar jetzt alle Readings, aber wirklich aktualisiert werden die nicht. Nach einem FHEM Neustart sind die wohl aktualisiert worden, aber bei weiteren Änderungen dann nicht mehr.
Unter lights werden schon immer die zugehörigen Lampen zurückgeliefert, das schalten funktioniert ja auch.
bisher wurden die gruppen readings nur für gepollte daten aktualisiert. nicht für die websocket push daten.
das habe ich eben behoben.
Also es kommen jetzt alle Readings, schalten der Gruppe über FHEM funktioniert auch. Wenn ich aber über deCONZ direkt schalte oder z.B. über einen Tradfri Schalter der eine Gruppe bedient geht es nur beim einschalten. Ausschalten der Gruppe geht zwar, es dann ändern sich die Readings in FHEM nicht.
Hallo zusammen,
möchte eigentlich gern den Aqara Flood Sensor nutzen.
Nach Installation der Beta 2.5.0.7 wird in der Phoscon App beim Join kurz ,,Sensor bereit" mit grüner Erfolgsmeldung angezeigt, allerdings kein Gerät angezeigt.
In FHEM sehe ich den Flood Sensor mittels ,,get <Interface> sensors". Anlegen funktioniert ebenfalls, nur kommen noch keine Events oder Readings an.
Ist jemand schon weiter?
Viele Grüße, Matthias.
Zitat von: justme1968 am 04 Februar 2018, 12:32:22
die sensoren werden über das api als drei einzelne geräte gemeldet. im modul gibt es keine möglichkeit rauszufinden das sie zusammen gehören.
man könnte zwar überlegen das irgendwo noch von hand einzugeben, das wäre aber ein größerer umbau ohne wirklich erkennbaren vorteil. wer das wirklich braucht kann das auch per notify zusammen kopieren.
state kannst du dir mit einem userReading erzeigen.
Hallo justme1968, erstmal klasse, was hier möglich ist. Ich bin gerade dabei auch von dem Gateway zum Conbee Stick umzusteigen und test es gerade. Ich habe gerade bemerkt das die Zuordnung der Sensoren zum Device über die uniqueid geht. Bis zum ersten Bindestrich gleichen sich die Werte je Device. Die hinteren sind dann je nach Reading unterschiedlich. Vielleicht ist es eine Überlegung wert, denn ggf. kommen noch weitere Werte hinzu, bspw. Battery.
Grüße
Hab gerade Mal den Xiaomi Aqara Motionsensor in Betrieb genommen. Die Meldung bei Bewegung funktioniert gut. Bei der Helligkeit gibt es ein dark und ein daylight Reading, state soll wohl einen Wert liefern. Aktuell habe ich da 16021 wenn Phoscon 39 Lux liefert. Jemand eine Idee wie man das umrechnen kann?
Internals:
CFGFN
DEF sensor 10 60 IODev=HUEd
ID S10
INTERVAL 60
IODev HUEd
NAME wz_hue_lightlevel
NR 501662
STATE 16021
TYPE HUEDevice
lastupdated 2018-03-05 17:59:54
manufacturername LUMI
modelid lumi.sensor_motion.aq2
name LightLevel 10
on 1
reachable 1
type ZHALightLevel
uniqueid 00:15:8d:00:01:e5:13:b2-01-0400
READINGS:
2018-03-05 17:59:54 dark 0
2018-03-05 17:59:54 daylight 0
2018-03-05 17:48:59 reachable true
2018-03-05 17:59:54 state 16021
helper:
devtype S
reachable 0
update_timeout 1
setList:
Attributes:
IODev HUEd
room HUEDevice
Hallo. Also es fehlt das LUX Reading. Das State Reading ist das Lightlevel reading. Wie das umgerechnet wird, weiß ich nicht.
Übrigens seit der neuen Beta (gestern) habe ich zusätzlich Battery. bei steht aber überall 100. Daher wohl noch ein Platzhalter.
Interessanterweise hat er bei mir das temperature Reading erstellt. liegt aber an deconz, es war auch dort zu finden...
Bisher läuft das ganz gut...
"manufacturername": "LUMI",
"modelid": "lumi.sensor_motion.aq2",
"name": "Motion Sensor (2)",
"state": {
"dark": false,
"daylight": true,
"lastupdated": "2018-03-05T23:03:29",
"lightlevel": 21431,
"lux": 139
},
"type": "ZHALightLevel",
READINGS:
2018-03-06 00:03:29 .lastupdated 2018-03-06 00:03:29
2018-03-05 23:55:26 battery 100
2018-03-06 00:03:29 dark 0
2018-03-06 00:03:29 daylight 1
2018-03-05 23:55:26 reachable 1
2018-03-06 00:03:29 state 21431
2018-03-05 22:43:31 temperature 28
ab morgen gibt es lux und lightlevel als readings.
Danke, funktioniert.
Super. Perfekt. Vielen Dank.
Ich nutze seit heute noch Power Plug Geräte. Die On / Off Funktion funktioniert bereits out of the box sehr gut. Es gibt Zigbee Werte, die allerdings nicht übernommen werden. Ist es möglich, diese Readings (consumption, power, voltage, current) auch zu übernehmen?
"21": {
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"manufacturername": "Heiman",
"modelid": "SmartPlug",
"name": "Consumption 21",
"state": {
"consumption": 60,
"lastupdated": "2018-03-07T22:00:26"
},
"type": "ZHAConsumption",
},
"22": {
"config": {
"on": true,
"reachable": true
},
"ep": 1,
"manufacturername": "Heiman",
"modelid": "SmartPlug",
"name": "Power 22",
"state": {
"current": 0,
"lastupdated": "2018-03-07T22:12:01",
"power": 0,
"voltage": 229
},
"type": "ZHAPower",
ab morgen im update
Vielen Dank im Voraus... :)
@basty2: bist du mit dem Heiman Plug zufrieden? Meldet der Zustandsänderungen auch zeitnah? Da Xiaomi keine EU Plugs hat wäre das eine Alternative.
Benutze einen zurzeit einen als Repeater. Zu anderen Plugs (Osram) funktioniert das schon mal. Ob es auch zu Endkomponenten geht, muss ich noch ausprobieren. Zur Reichweite kann ich noch nicht viel sagen, bisher ist diese vergleichbar mit den Osram Plug.
Also die Reaktionszeit ist nicht gut. Habe es mit einer LED Kette gerade probiert. Dauer liegt zwischen 25 und 90 Sekunden bis er die Änderung registriert. wenn ich bei deconz den read button drücke, erscheinen die Änderungen bereits 10 Sekunden nach der Änderung. Da man aber m.E. kein Interval einstellen kann, bleibt es aktuell bei der großen Spanne.
Ist zur genauen Steuerung nicht geeignet. ggf. ändert sich das noch.
Was mich etwas stört ist das fiepen. Aber es ist weniger als beim Osram und bitron plug (das ist das schlimmste).
Grüße
Update: Also bei mir gibt es das Problem, dass sich die Steckdosen nicht mit meinen Sensoren verbinden. Ich habe mal im github nachgefragt. Momentan kann ich diese nicht empfehlen.
Ok, dann ist der für meine Zwecke auch nichts, die Reaktionszeit ist mir zu langsam. Mal sehen was sonst noch so demnächst auf den Markt kommt, von Innr und Ikea soll es ja auch demnächst Plugs geben.
Hallo zusammen,
ich hab mir mal den conbee besorgt, weil ich überlege mein hue gateway abzulösen.
Den stick hab ich eingesteckt und die deconz software installiert.
Software läuft auch:
deCONZ 13417 pi 8u IPv4 38487 0t0 TCP *:http (LISTEN)
deCONZ 13417 pi 12u IPv4 38491 0t0 TCP *:https (LISTEN)
Und nun? Hab sowas probiert:
define conbee HUEBridge 127.0.0.1
Aber da bekomme ich im Log:
2018.04.20 11:07:09 1: HUEBridge_HTTP_Request http://127.0.0.1/api/54e08015439b8c4eafa0d888bf135b3e/config: Select timeout/error:
2018.04.20 11:07:09 3: HUEBridge_Call: failed, retrying
2018.04.20 11:07:13 1: HUEBridge_HTTP_Request http://127.0.0.1/api/54e08015439b8c4eafa0d888bf135b3e/config: Select timeout/error:
2018.04.20 11:07:13 3: HUEBridge_Call: failed, retrying
2018.04.20 11:07:13 3: HUEBridge_Call: failed
2018.04.20 11:07:13 2: HUEBridge_OpenDev: got empty config
Okay komisch. Ich muss erstmal httpUtils 1 setzen und dann einmal inactive und wieder active.
Die älteren Philips Living Color Lampen kann man mit dem Teil nicht steuern oder?
Mit älter meine ich nicht die erste Generation mit den ovalen Fernbedienungen, sondern die zweite mit den runden. An der normalen Hue Bridge sollen sich ja auch die älteren anlernen lassen. Mir wäre so ein multifunktionales Gateway lieber als die Phillips Bridge mit einer einzigen Funktion.
Ich kann leider nur die E27 Birnen und Bloom testen. Die funktionieren bestens bisher
Hallo,
ich habe gestern Abend eine Philips Iris mit einem Conbee verbunden.
Während ich nach Lampen gesucht habe, habe ich mit der Runden Iris-Fernbedienung die Iris Lampe zurückgesetzt (Fernbedienung nah an die Iris halten und Ein+Szene1 gedrückt halten).
Kurze Frage noch in die Runde: Hat jemand es geschafft, den Xiaomi Aqara Flood Sensor ins System zu heben?
Also ich nicht. Deconz erkennt das Device aber nicht die Werte...
Ich kämpfe gerade mit den Aqara Fenstersensoren.
Anlegen hat alles soweit funktioniert, bekomme aber keine Statusänderungen angezeigt. Der state bleibt immer auf open stehen.
Was müssen denn da für readings angelegt werden damit ich den aktuellen Status angezeigt bekomme?
Zitat von: LordVoodoo am 01 März 2018, 13:48:15
Hallo zusammen,
möchte eigentlich gern den Aqara Flood Sensor nutzen.
Nach Installation der Beta 2.5.0.7 wird in der Phoscon App beim Join kurz ,,Sensor bereit" mit grüner Erfolgsmeldung angezeigt, allerdings kein Gerät angezeigt.
In FHEM sehe ich den Flood Sensor mittels ,,get <Interface> sensors". Anlegen funktioniert ebenfalls, nur kommen noch keine Events oder Readings an.
Ist jemand schon weiter?
Viele Grüße, Matthias.
Hallo,
ich habe das gleiche Problem. hat schon jmd eine Lösung gefunden ?
Gruss Ole
update:
Eigentlich fehlt mir "nur" das richtige Reading:
Im FHEM sehe ich die Readings:
battery 98 2018-08-27 10:46:18
reachable false 2018-08-27 10:46:18
Über die WebApi bekomme ich auch "tampered":false,"water":false zurück.
Zitat von: Murph am 21 Juni 2018, 18:23:37
Ich kämpfe gerade mit den Aqara Fenstersensoren.
Anlegen hat alles soweit funktioniert, bekomme aber keine Statusänderungen angezeigt. Der state bleibt immer auf open stehen.
Was müssen denn da für readings angelegt werden damit ich den aktuellen Status angezeigt bekomme?
Guten Morgen,
ich schließe mich der Frage mal an. In der Phoscon App ist der Sensor hinterlegt und erkennt auch die States open/close.
Nur in FHEM findet keine Änderung des States statt. Hat da in der Zwischenzeit schon jemand eine Lösung gefunden?
Gruß
Jörg
bei mir funktionieren die Sensoren, hatte aber das selbe Problem: ein Neustart hat geholfen. Sowohl von deCONZ (Raspi) als auch von FHEM.
lg
Hi,
hab die Honeywell Smoke Sensoren mit deCONZ ohne Probleme verbinden können, sie werden zwar nicht in der Phoscon APP angezeigt aber wenn man die MAC weiß kann man sie über die URL aufrufen. In der API werden sie auch angezeigt und in FHEM kann man sie als Sensor auch anlegen.
Nur das Problem ist das die Readings nicht klappen nur "reachable" wird angezeigt.
Hatte dafür auch einen eigenen Eintrag gemacht.
https://forum.fhem.de/index.php/topic,88411.0.html
Aber leider keine Antwort bekommen.
Wäre Super wenn ich keinen Workaround schreiben müsste damit sie Unterstützt werden.
Folgendes Problem:
Deconz läuft im docker container mit gemappten ports
80 ist erreichbar von port 8095
443 erreichbar von 4430
wenn ich die huebridge anlege in fhem findert er auch was aber nicht alles .. iwas scheint da nicht zu laufen wie es sollte
Internals:
CFGFN
DEF 192.168.178.26:8095
INTERVAL 60
NAME huebridge
NOTIFYDEV global
NR 1806
NTFY_ORDER 50-huebridge
STATE initialized
TYPE HUEBridge
host 192.168.178.26:8095
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2012
Helper:
DBLOG:
state:
logdb:
TIME 1538076898.44742
VALUE initialized
READINGS:
2018-09-27 21:34:58 state initialized
helper:
count 4
last_config_timestamp 0
Attributes:
key cb1550f3f77d4acd9115d9567c219410
Fhem log:
2018-09-27 21:41:23 Global global ATTR huebridge verbose 5
2018-09-27 21:41:38 HUEBridge huebridge active
2018.09.27 21:41:38 5 : HUEBridge_OpenDev: got description: <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <URLBase>http://192.168.178.26:8095/</URLBase> <device> <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType> <friendlyName>Philips hue (192.168.178.26) compatible Wireless Light Control Gateway</friendlyName> <manufacturer>Royal Philips Electronics</manufacturer> <manufacturerURL>http://www.dresden-elektronik.de</manufacturerURL> <modelDescription>dresden elektronik Wireless Light Control</modelDescription> <modelName>Philips hue bridge 2012</modelName> <modelNumber>929000226503</modelNumber> <modelURL>http://www.dresden-elektronik.de</modelURL> <serialNumber>00212EFFFF027B6B</serialNumber> <UDN>uuid:bdf863e4-1325-49f5-9e4d-200e0cf4a41b</UDN> <gatewayName>Phoscon-GW</gatewayName> <presentationURL>index.html</presentationURL> <iconList> <icon> <mimetype>image/png</mimetype> <height>48</height> <width>48</width> <depth>24</depth> <url>hue_logo_0.png</url> </icon> <icon> <mimetype>image/png</mimetype> <height>120</height> <width>120</width> <depth>24</depth> <url>hue_logo_3.png</url> </icon> </iconList> </device> </root>
2018.09.27 21:41:38 4 : using HUEBridge_HTTP_Request: GET config
2018.09.27 21:41:42 1 : HUEBridge_HTTP_Request http://192.168.178.26:8095/api/cb1550f3f77d4acd9115d9567c219410/config: Select timeout/error:
2018.09.27 21:41:42 3 : HUEBridge_Call: failed, retrying
2018.09.27 21:41:42 4 : using HUEBridge_HTTP_Request: GET config
2018.09.27 21:41:46 1 : HUEBridge_HTTP_Request http://192.168.178.26:8095/api/cb1550f3f77d4acd9115d9567c219410/config: Select timeout/error:
2018.09.27 21:41:46 3 : HUEBridge_Call: failed, retrying
2018.09.27 21:41:46 3 : HUEBridge_Call: failed
2018.09.27 21:41:46 2 : HUEBridge_OpenDev: got empty config
api outpout von http://192.168.178.26:8095/api/cb1550f3f77d4acd9115d9567c219410/config im browser
{"apiversion":"1.0.9","bridgeid":"00212EFFFF027B6B","datastoreversion":"60","devicename":"ConBee","factorynew":false,"mac":"ac:1f:6b:19:d2:3e","modelid":"deCONZ","name":"Phoscon-GW","replacesbridgeid":null,"starterkitid":"","swversion":"2.5.39"}
Zitat von: LordVoodoo am 11 Mai 2018, 09:36:17
Kurze Frage noch in die Runde: Hat jemand es geschafft, den Xiaomi Aqara Flood Sensor ins System zu heben?
Hatte dasselbe Problem. DeConz erkennt den Sensor, zeigt ihn in der Phoscon App aber nicht an. In FHEM kann man den Sensor erzeugen, aber es wird nur battery und reachable angezeigt und aktualisiert.
Problem ist die fehlende Unterstützung in der Datei "FHEM/31_HUEDevice.pm". An der Stelle wo die ganzen Readings erzeugt werden (einfach mal z.B. nach "pressure" suchen) muss man folgende Zeile hinzufügen:
$readings{water} = $state->{water} if( defined($state->{water}) );
Danach gibt es ein Reading "water" das zwischen 0 und 1 wechselt (trocken/nass).
Hi, ich habe noch nicht ganz verstanden welche Module push unterstützen.
Ich bin auf deconz Version 2.05.39 und neuste FHEM version.
Wie kann ich z.B. push updates von meinen Xiaomi Aqara Schaltern bekommen? Ich frage diese im Moment jede Sekunde ab, was mich ziemlich stört.
Gruß und danke schonmal :)
Hi,
ich habe diese Anleitung benutzt : http://coldcorner.de/2018/04/02/deconz-hue-bridge-auf-dem-raspberry-pi-emulieren/
Danach die eine Zeile die hier schon besprochen wurde hinzufügen, dann sollte der Sensor funktionieren
Moin Leute,
mal eine Frage bezüglich des Intervalls bei der Definition neuer Devices: Sollte man die Zeitangabe hier nicht eigentlich weglassen können? Ich meine, wenn bei neuen Events doch eh gepusht wird, wäre das nicht überflüssig oder übersehe ich da etwas?
Hi@All,
mir ist die Tage ein Problem mit den HUEGroups in Verbindung mit Raspee/Phoscon aufgefallen und da ich im Forum keine Lösung gefunden habe poste ich mein Problem mal hier:
Bei meinen in Phoscon erstellen Gruppen werden in FHEM keine State Readings angezeigt. Der STATE steht immer auf UNKNOWN was vermutlich zur Folge hat, dass
set HUEGROUPX toggle
nicht oder nur in eine Richtung funktioniert. Ist die Gruppe an funktioniert Toggle und sie werden ausgeschaltet aber wenn sie aus sind werden sie nicht eingeschaltet.
Hier mal ein List einer Beispielgruppe:
ternals:
CHANGED
DEF group 3 IODev=Raspbee
ID G3
INTERVAL
IODev Raspbee
NAME HUEGroup3
NR 128
STATE unknown
TYPE HUEDevice
class Other
lights 1,2
name Lights_Bedroom_Ambient
type LightGroup
READINGS:
2018-10-27 13:19:41 all_on 0
2018-10-27 13:19:41 any_on 0
helper:
devtype G
update_timeout 1
Attributes:
IODev Raspbee
alias Lights_Bedroom_Ambient
color-icons 2
delayedUpdate 1
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
group LIGHTS&PLUGS
icon hue_filled_storylight
room Bedroom
userattr createActionReadings:1,0 createGroupReadings:1,0
Allgemein kann man wohl sagen, dass nicht viele Infos der Gruppe wie z.B. Helligkeit ankommen.
Funktioniert das bei jemanden und wenn ja, eine Idee warum es bei mir nicht klappe?
FHEM und PHOSCON sind jeweils auf aktuellem Stand.
EDIT: Ich sollte noch erwähnen, dass on und off aus FHEM heraus einwandfrei funktionieren, nur toggle nicht. Auch die Readings "all_on" und "any_on" werden korrekt aktualisiert.
EDIT2: Ich habe jetzt in einem anderen Post gelesen, dass Gruppen nie ein State haben. Das habe ich mit Stateformat korrigiert. Trotzdem funktioniert toggle nicht, was ich jetzt aber auch über notify behoben habe
Hallo zusammen,
hab´s leider auch noch nicht verstanden, wie die offizielle Push API genutzt werden kann.
Mein Conbee ist mittels HUEBridge Modul angebunden und dort ist, soweit ich sehe, nur Polling möglich.
Auch die Doku von DE erwähnt nur Polling für die REST API.
Testweise habe ich es noch mit myDeconz1 probiert, aber auch mit wenig Erfolg und daher wieder entfernt.
Das ist echt schade, weil ich mittlerweile mehrere OneButton Schalter von Aqara habe, die natürlich nur ein State zeigen können, weshalb ich auf jegliche Änderung per Notify reagieren wollte.
Ist natürlich doof, wenn man Polling nutzt :-) Dann reagiert die Lampe dahinter natürlich nach jedem Intervall.
@hukatoni
Ich habe die Anleitung auf coldcorner.de benutzt und ich bin der Meinung, daß eine Push Verbindung besteht. Meine Sensoren ändern sofort die Statusmeldung bei Bewegung.
Eine andere Frage hab ich noch. Der Aqara Motion Sensor hat in der Phoscon App eine Temperatur hinterlegt. Ist es möglich, diese abzufragen oder liefert die deconz API nicht diesen Wert?
Die Api liefert den Wert, aber das Modul legt kein Reading dafür an. Brauchbar ist der Wert aber eh nicht.
Zitat von: DazDavid am 27 Oktober 2018, 13:25:12
Hi@All,
mir ist die Tage ein Problem mit den HUEGroups in Verbindung mit Raspee/Phoscon aufgefallen und da ich im Forum keine Lösung gefunden habe poste ich mein Problem mal hier:
Bei meinen in Phoscon erstellen Gruppen werden in FHEM keine State Readings angezeigt. Der STATE steht immer auf UNKNOWN was vermutlich zur Folge hat, dass
set HUEGROUPX toggle
nicht oder nur in eine Richtung funktioniert. Ist die Gruppe an funktioniert Toggle und sie werden ausgeschaltet aber wenn sie aus sind werden sie nicht eingeschaltet.
Hier mal ein List einer Beispielgruppe:
ternals:
CHANGED
DEF group 3 IODev=Raspbee
ID G3
INTERVAL
IODev Raspbee
NAME HUEGroup3
NR 128
STATE unknown
TYPE HUEDevice
class Other
lights 1,2
name Lights_Bedroom_Ambient
type LightGroup
READINGS:
2018-10-27 13:19:41 all_on 0
2018-10-27 13:19:41 any_on 0
helper:
devtype G
update_timeout 1
Attributes:
IODev Raspbee
alias Lights_Bedroom_Ambient
color-icons 2
delayedUpdate 1
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
group LIGHTS&PLUGS
icon hue_filled_storylight
room Bedroom
userattr createActionReadings:1,0 createGroupReadings:1,0
Allgemein kann man wohl sagen, dass nicht viele Infos der Gruppe wie z.B. Helligkeit ankommen.
Funktioniert das bei jemanden und wenn ja, eine Idee warum es bei mir nicht klappe?
FHEM und PHOSCON sind jeweils auf aktuellem Stand.
EDIT: Ich sollte noch erwähnen, dass on und off aus FHEM heraus einwandfrei funktionieren, nur toggle nicht. Auch die Readings "all_on" und "any_on" werden korrekt aktualisiert.
EDIT2: Ich habe jetzt in einem anderen Post gelesen, dass Gruppen nie ein State haben. Das habe ich mit Stateformat korrigiert. Trotzdem funktioniert toggle nicht, was ich jetzt aber auch über notify behoben habe
Die Lösung ist, wenn du beim Gruppendevice das attribut "createActionReadings 1" setzt. Dann geht es auch mit dem toggle.
hue gruppen und auch createActionReadings macht meist/oft nicht das was man erwartet:
- gruppen haben keinen zustand, eigentlich sind nur die all_on und any_on readings unterstützt und korrekt
- mit createActionReadings wird zwar die antwort der bridge ausgewertet, diese umfasst aber nur werte die
sich mit diesem kommando aus sicht der bridge geändert haben. das ist oft unvollständig. z.b. wenn man
nicht über die gruppe oder bridge schaltet.
besser ist es mit createGroupReadings zu arbeiten. hier erzeugt fhem die fehlenden readings in dem es selber die einzelnen beteiligten lampen untersucht. es fehlen zwar noch einige readings, es sollte aber die beste lösung sein. und sie funktioniert auch wenn innerhalb einer gruppe einzelne lampen auch noch von hand geschaltet werden.
justme du hast recht. Deine Lösung ist besser.
Also nachdem ich auf dem Bridgedevice das attribut createReadingGroup gesetzt habe ists akurat :).
Danke für den Hinweis!
ich bin gerade dabei mich mit dem magic cube von xioami zu beschäftigen.
in der Phoscon app sehe ich auch den drehwinkel. mir ist es nicht gelungen den winkel in fhem zu bekommen.
die anderen daten bekomm ich.
kann mir jemand auf die sprünge helfen?
lg nussa
Zitat von: nussa am 10 November 2018, 10:49:14
ich bin gerade dabei mich mit dem magic cube von xioami zu beschäftigen.
in der Phoscon app sehe ich auch den drehwinkel. mir ist es nicht gelungen den winkel in fhem zu bekommen.
die anderen daten bekomm ich.
kann mir jemand auf die sprünge helfen?
lg nussa
Ist der Cube denn richtig gepaart? Bei mir werden 3 Devices/Sensoren für FHEM angelegt.
In Phoscon ist der Cube aber nur als ein Device sichtbar.
22: Cube (1) XiaomiCube1.1 ZHASwitch
23: Cube (1) XiaomiCube1.2 ZHASwitch
27: Cube (1) XiaomiCube1.3 ZHASwitch
Danke!! nach dem dritten mal paaren habe ich jetzt ein drittes device.
lg nussa
Zitat von: justme1968 am 03 Januar 2018, 11:26:57
da sind noch zwei log nachrichten übrig geblieben. die sollten ab morgen weg sein.
Hallo Andre, Hallo Chi-Tai
habe mir für mein FHEM das jetzt ca seit 2013 in Betrieb ist und stetig wächst einen conBee zu Weihnachten geschenkt.
(Gestern bekommen und eingebunden, warte noch auf meine RGB Lampen)
Bisher nutze ich CUL für IT, früher noch einen CUL für HM mittlerweile ersetzt durch das aktuelle EQ3 HM Gateway für Homatic
sowie diverse Module wie Fritzbox SIP Wetter usw.
FHEM ist folgende Version aus fheminfo:
[/b]
OS: linux
Perl: 5.20.2
fhem.pl:17731/2018-11-11 perl:5.020002 os:linux
Featurelevel: 5.9[/b]
Hersteller dresden elektronik
Produkt ConBee
Version 2.05.47 / 13.11.2018
Firmware 262F0500Den Con Bee habe ich zuerst auf meinem Raspberry eingerichtet (auf dem auch mein Haupt FHEM und die Homebridge läuft)
Hatte etwas Probleme dieses Webfrontend Phoscon vom Stick zum laufen zu bekommen,
was daran lag das ich kein Desktop mit dem Start vom Raspberry starte.
Habe dann das Kommando zum start ohne X server verwendet.
Danach wie im WIKI die HUE Bridge eingerichtet, und im Anschluss mit Phoscon in der Web App verbunden.
Mit folgendem Attribut : httpUtils 1
Nun zu meinen 3 Fragen
1) benötige ich das httpUtils 1 überhaupt wenn die pushAPI implementiert ist?
2) ist diese push API in dem aktuellen Modul das man über Update bekommt drinnen (habe heute noch keine Lampen/Schalter dran)?
Habe das Modul nach der WIKI Beschreibung angelegt.
CFGFN
DEF 192.168.2.23
FD 5
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 907
NTFY_ORDER 50-deCONZ
PORT 40238
STATE connected
TYPE HUEBridge
apiversion 1.16.0
host 192.168.2.23
mac b8:27:eb:xx:xx:xx
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
modelid deCONZ
name Phoscon-GW
swversion 2.5.47
updatestate 0
websocket 1
websocketport 443
zigbeechannel 15
Jetzt mein Hauptanliegen:
3) folgende Einträge hab ich alle 6 Minuten im Log.
Da meine Hue Lampen noch nicht da sind und momentan also nur das Gateway läuft,
die frage ob es nur ein Status ist oder irgendwo ein Fehler in meiner Config:
2018.11.14 20:08:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:08:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:14:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:14:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:20:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:20:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:26:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:26:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:32:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:32:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:38:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:38:46 3: deCONZ: websocket: Switching Protocols ok
4) (Zusatzfrage) :-) ist es egal ob man auf dem lokalen Pi die von außen erreichbare IP (bei mir 192.168.2.23) verwendet oder ist die 127.0.0.1 die bessere Alternative?
Danke schon mal für Eure Antworten
Zitat von: HRE_7390_pi am 14 November 2018, 21:45:30
Hallo Andre, Hallo Chi-Tai
habe mir für mein FHEM das jetzt ca seit 2013 in Betrieb ist und stetig wächst einen conBee zu Weihnachten geschenkt.
(Gestern bekommen und eingebunden, warte noch auf meine RGB Lampen)
Bisher nutze ich CUL für IT, früher noch einen CUL für HM mittlerweile ersetzt durch das aktuelle EQ3 HM Gateway für Homatic
sowie diverse Module wie Fritzbox SIP Wetter usw.
FHEM ist folgende Version aus fheminfo:
[/b]
OS: linux
Perl: 5.20.2
fhem.pl:17731/2018-11-11 perl:5.020002 os:linux
Featurelevel: 5.9[/b]
Hersteller dresden elektronik
Produkt ConBee
Version 2.05.47 / 13.11.2018
Firmware 262F0500
Den Con Bee habe ich zuerst auf meinem Raspberry eingerichtet (auf dem auch mein Haupt FHEM und die Homebridge läuft)
Hatte etwas Probleme dieses Webfrontend Phoscon vom Stick zum laufen zu bekommen,
was daran lag das ich kein Desktop mit dem Start vom Raspberry starte.
Habe dann das Kommando zum start ohne X server verwendet.
Danach wie im WIKI die HUE Bridge eingerichtet, und im Anschluss mit Phoscon in der Web App verbunden.
Mit folgendem Attribut : httpUtils 1
Nun zu meinen 3 Fragen
1) benötige ich das httpUtils 1 überhaupt wenn die pushAPI implementiert ist?
2) ist diese push API in dem aktuellen Modul das man über Update bekommt drinnen (habe heute noch keine Lampen/Schalter dran)?
Habe das Modul nach der WIKI Beschreibung angelegt.
CFGFN
DEF 192.168.2.23
FD 5
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 907
NTFY_ORDER 50-deCONZ
PORT 40238
STATE connected
TYPE HUEBridge
apiversion 1.16.0
host 192.168.2.23
mac b8:27:eb:xx:xx:xx
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
modelid deCONZ
name Phoscon-GW
swversion 2.5.47
updatestate 0
websocket 1
websocketport 443
zigbeechannel 15
Jetzt mein Hauptanliegen:
3) folgende Einträge hab ich alle 6 Minuten im Log.
Da meine Hue Lampen noch nicht da sind und momentan also nur das Gateway läuft,
die frage ob es nur ein Status ist oder irgendwo ein Fehler in meiner Config:
2018.11.14 20:08:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:08:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:14:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:14:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:20:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:20:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:26:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:26:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:32:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:32:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:38:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:38:46 3: deCONZ: websocket: Switching Protocols ok
4) (Zusatzfrage) :-) ist es egal ob man auf dem lokalen Pi die von außen erreichbare IP (bei mir 192.168.2.23) verwendet oder ist die 127.0.0.1 die bessere Alternative?
Danke schon mal für Eure Antworten
Moin HRE_7390_pi,
ich habe diese Woche auch meinen ConBee Adapter in fhem eingepflegt, allerdings mit Version .39 da es danach wohl Probleme mit den Aqara-Sensoren gab.
Habe aber das gleiche "Logproblem" wie du, auch schon einmal alles zurück gesetzt, neu eingebunden, Ports gewechselt etc. - nichts zu machen!
Da aber alles ohne Probleme funktioniert überlege ich gerade ob ich diese Logeinträge einfach entfernen/unterbinden soll.
Moin,
Ich bin vor ein paar Wochen auch auf RaspBee vom Dresden electronics umgestiegen, vor allem um meine busch jäger zll Schalter in fhem nutzen zu können. Theoretisch funktioniert es auch ganz gut mit der push api. Allerdings dauert es bei mir manchmal bis zu 5s bevor die Lichter auf einen Tastendruck reagieren. Das ist für den WAF nicht hilfreich.
Anbei ein List vom RaspBee:
Internals:
DEF 1.2.3.4
FD 5
INTERVAL 60
NAME RaspBee
NOTIFYDEV global
NR 70
NTFY_ORDER 50-RaspBee
PORT 41284
STATE connected
TYPE HUEBridge
apiversion 1.0.9
buf
host 1.2.3.4
mac aa:bb:cc:dd:ee:ff
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2012
modelid deCONZ
name Hue Network
swversion 2.5.40
updatestate 0
websocket 1
websocketport 443
zigbeechannel 25
READINGS:
2018-11-19 21:25:59 lastError resource, /lights/23, not available
2018-11-22 20:52:55 state connected
helper:
apiversion 65545
count 0
last_config_timestamp 1542916373
offsetUTC 3600
updatestate 0
Attributes:
createGroupReadings 1
httpUtils 1
icon hue_bridge
key <abcdeffff>
noshutdown 1
queryAfterSet 1
room Administration
verbose 1
Drücke ich einen Schalter (bj zll oder auch hue tap) ändert sich in der Rest api vom RaspBee sofort der state. Im fhem bleibt aber manchmal der alte für wenige Sekunden drinne bevor der neue da steht. Meistens klappt es innerhalb von einer Sekunde, aber die Ausreißer stören ein wenig.
Ist meine Konfiguration korrekt? Muss ich für die push api noch etwas machen? Hat jemand anderes auch das Problem und ggf eine Idee?
Ich habe auf die Status Änderungen pro Schalter einen notify, der entsprechend des Status Codes fhem lightscenes schaltet. Aber diese verzögern eigentlich nicht, der state in fhem wird einfach nicht 'in nahezu Echtzeit' aktualisiert.
Ich habe deconz in Version 2.5.40 mit Firmware 26260500.
Viele Grüße
dwi
Moin,
ich benutze auch den Conbee Stick, wenn ich es nicht falsch verstanden habe, werden neue Devices automatisch angelegt?
Wenn ich autocreate ausführe, wird mir immer Create 0 Devices angezeigt, auch wenn neue vorhanden sind. Ist jetzt nicht problematisch, da ich die bisher von Hand angelegt habe.
Allerdings habe ich Probleme mit dem Aquara Bewegungsmelder, den habe ich angelegt State steht aber immer auf unreachable, es gibt kein Motion Reading, Bewegungen werden aber in der Phoscon App angezeigt?
List Device:
Internals:
CFGFN
DEF 13 IODev=deCONZ
ID 13
INTERVAL
IODev deCONZ
NAME Bewegungsmelder_01
NR 62274
STATE Initialized
TYPE HUEDevice
desired 1
manufacturername LUMI
modelid lumi.sensor_motion.aq2
name Bewegungsmelder_01
type ZHAPresence
uniqueid 00:15:8d:00:02:b5:d1:76-01-0406
READINGS:
2018-12-19 22:05:58 pct 100
2018-12-19 21:21:52 state unreachable
helper:
alert
bri -1
colormode
ct -1
devtype
effect
hue -1
on -1
pct -1
reachable 0
rgb
sat -1
update_timeout 1
xy
Attributes:
DbLogExclude .*
IODev deCONZ
devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
event-on-change-reading .*
icon motion_detector@blue
model lumi.sensor_motion.aq2
room HUEDevice
timestamp-on-change-reading state
Hm hat sich erledigt. Der Bewegungsmelder war falsch angelegt. Jetzt funktioniert es.
Ich nochmal, stehe heute irgendwie auf dem Schlauch.
Muß ich für das LUX Reading des Bewegungsmelders ein zweites Device anlegen, oder bekomme ich das Reading irgendwie mit zum Bewegungsmelder?
Das hat eine andere Sensor ID, also ein zweites Device. Kann man dann bei Bedarf mit Userreadings zusammenfassen.
Ok danke
Zitat von: Starsurfer am 20 Dezember 2018, 08:22:32
Hm hat sich erledigt. Der Bewegungsmelder war falsch angelegt. Jetzt funktioniert es.
hab momentan das gleiche Problem, wie wird er denn richtig angelegt?
Mit get DEINDECONZ sensors nach ZHAPresence suchen. Dort sollte motion oder nomotion ausgegeben werden.
Hier mal das Beispiel:
defmod Bewegungsmelder_Kueche HUEDevice sensor 12 IODev=deCONZ
attr Bewegungsmelder_Kueche DbLogExclude .*
attr Bewegungsmelder_Kueche IODev deCONZ
attr Bewegungsmelder_Kueche event-on-change-reading .*
attr Bewegungsmelder_Kueche room HUEDevice
attr Bewegungsmelder_Kueche timestamp-on-change-reading state
Danke für deine Info.
ich habe mich von dem deutschen "Bewegungsmelder" irritieren lassen ::) Richtig ist natürlich Presence 3 zu nehmen.
ID NAME FHEM TYPE
1: Daylight Daylight
2: Bewegungsmelder ZHALightLevel
3: Presence 3 ZHAPresence
Weiss doch jeder, dass ein Bewegungsmelder nur die Helligkeit messen kann 8)
EDIT: Hat sich erledigt, nach mehrfachem Neustart und Update läuft die Kommunikation jetzt über Websocket
Falls sich noch jemand fragen sollte, wie man das auf einen Blick prüfen kann:
HueBridge (deConz) auswählen, Internals, websocket = 1. Dieser Eintrag fehlte bei mir bis dato völlig.
Viele Grüße!
Hier mein ursprüngliches Problem:
Hallo zusammen,
sorry, falls ich etwas offensichtliches übersehen sollte. Ich stehe mit FHEM noch ganz am Anfang.
Ich habe jetzt diesen Thread und die Anleitung auf coldcorner komplett durchgearbeitet und schaffe es irgendwie trotzdem nicht eine Push-Verbindung herzustellen.
Mein aktuelles Setup sieht wie folgt aus:
- deConz mit ConBee und FHEM auf einem Raspberry Pi
- Einige Hue-Lampen und Aqara-Sensoren erfolgreich in der Phoscon App gebunden
- Verbindung zu deConz als HueBridge erfolgreich hergestellt anhand der Anleitung auf coldcorner
- Hue-Lampen wurden automatisch gefunden und hinzugefuegt
- Xiaomi-Sensoren manuell hinzugefuegt wie auf coldcorner. Werte werden bereitgestellt und sind plausibel
- Attribut httpUtils 1 für deconz gesetzt
Was hier augenscheinlich nicht passiert, ist eine Push-Kommunikation über Websocket. Zustandsänderungen (z.B. der Hue-Lampen) kommen erst mit dem nächsten Periodischen Update (1/min) in FHEM an.
Wie kann ich sicherstellen, dass FHEM das Push-Api von deCONZ nutzt?
Vielen Dank!
Edit:
das deConz-Websocket-API funktioniert einwandfrei, es sieht für mich wirklich so aus, als würde sich FHEM nicht auf das WebSocket-API verbinden, sondern auf das standard REST-API
Zitat von: Ullulaki am 15 November 2018, 08:32:39
Moin HRE_7390_pi,
ich habe diese Woche auch meinen ConBee Adapter in fhem eingepflegt, allerdings mit Version .39 da es danach wohl Probleme mit den Aqara-Sensoren gab.
Habe aber das gleiche "Logproblem" wie du, auch schon einmal alles zurück gesetzt, neu eingebunden, Ports gewechselt etc. - nichts zu machen!
Da aber alles ohne Probleme funktioniert überlege ich gerade ob ich diese Logeinträge einfach entfernen/unterbinden soll.
Ich habe auch gerade einen ConBee Adapter neu gekauft und eingerichtet. Die Log-Einträge hatte ich auch, habe Sie aber mit verbose = 2 unterbinden können. Ab verbose = 3 erscheinen sie wieder. Ich denke nicht, dass es Fehlermeldungen sind.
Hi justme1968,
ich habe gerade mein deCONZ mit einem RaspBee eingerichtet, um meine Philips Bewegungsmelder und Remote ohne HueBridge verwenden zu können. Ich hatte die Hoffnung, dass ich über die Websocketverbindung alle Buttonevents bekommen würde (1000 -> 1002), ich bekomme aber nur 1000, manchmal auch 1002 dazu.
Dann hab ich im Logfile gesehen, dass per Websocket alle events reinkommen, die aber im HUEDevice.pm ignoriert werden.
In 31_HUEDevice.pm, Zeile 1291 spring er raus, wenn
return undef if( $hash->{lastupdated} && $hash->{lastupdated} eq $lastupdated);
Dies verhindert, dass die Events durchgereicht werden, da sie meistens den selben 'lastupdated'-Wert haben.
Ich hab' mir jetzt mal auf die Schnelle geholfen, in dem ich ein AttrVal hinzugefügt habe, welches ich in den relevanten Devices auf 0 gesetzt hab:
return undef if( $hash->{lastupdated} && $hash->{lastupdated} eq $lastupdated && AttrVal( $name, 'skipImmediateEvents', 1 ));
Grundsätzlich wär' ich eher der Meinung, das 'return undef' nicht zu machen, wenn sich die 'events' unterscheiden, allerdings hat die Zeile vermutlich einen Hintergrund und es ist sicher nicht trivial, herauszufinden, ob die 'events' sich unterscheiden.
Gibt es einen besseren Weg alle events durchzulassen? Wenn das Attribut Deiner Meinung nach was brauchbares ist, kann ich auch gerne einen vollständigen Patch machen, mit Doku und so.
+++ EDIT 1 +++
Nachdem ich es jetzt mal eine Zeit so laufen hatte, hab' ich festgestellt, dass jetzt auch regelmässige Updates, die kein event sind, zum Schalten führen, das war nicht meine Absicht :(.
Hab' es darum jetzt mal bei mir umgebaut, so dass er den state noch mit überprüft, so geht es jetzt erstmal besser, aber es ist halt *nur* der state, die anderen Readings werden nicht überprüft.
@@ -1286,9 +1286,21 @@ HUEDevice_Parse($$)
$lastupdated_local = $lastupdated;
}
+ $readings{state} = $state->{status} if( defined($state->{status}) );
+ $readings{state} = $state->{flag}?'1':'0' if( defined($state->{flag}) );
+ $readings{state} = $state->{open}?'open':'closed' if( defined($state->{open}) );
+ $readings{state} = $state->{lightlevel} if( defined($state->{lightlevel}) && !defined($state->{lux}) );
+ $readings{state} = $state->{buttonevent} if( defined($state->{buttonevent}) );
+ $readings{state} = $state->{presence}?'motion':'nomotion' if( defined($state->{presence}) );
+ $readings{state} = $state->{fire}?'fire':'nofire' if( defined($state->{fire}) );
+
$hash->{lastupdated} = ReadingsVal( $name, '.lastupdated', undef ) if( !$hash->{lastupdated} );
$hash->{lastupdated_local} = ReadingsVal( $name, '.lastupdated_local', undef ) if( !$hash->{lastupdated_local} );
- return undef if( $hash->{lastupdated} && $hash->{lastupdated} eq $lastupdated );
+ if( $hash->{lastupdated} && $hash->{lastupdated} eq $lastupdated ) {
+ return undef if ( AttrVal( $name, 'skipImmediateEvents', 1 ) );
+ my $curState = ReadingsVal( $name, "state", undef );
+ return undef unless ( defined($curState) && defined($readings{state}) && $curState ne $readings{state} )
+ }
Log3 $name, 4, "$name: lastupdated: $lastupdated, hash->{lastupdated}: $hash->{lastupdated}, lastupdated_local: $lastupdated_local, offsetUTC: $offset";
Log3 $name, 5, "$name: ". Dumper $result if($HUEDevice_hasDataDumper);
@@ -1296,14 +1308,6 @@ HUEDevice_Parse($$)
$hash->{lastupdated} = $lastupdated;
$hash->{lastupdated_local} = $lastupdated_local;
- $readings{state} = $state->{status} if( defined($state->{status}) );
- $readings{state} = $state->{flag}?'1':'0' if( defined($state->{flag}) );
- $readings{state} = $state->{open}?'open':'closed' if( defined($state->{open}) );
- $readings{state} = $state->{lightlevel} if( defined($state->{lightlevel}) && !defined($state->{lux}) );
- $readings{state} = $state->{buttonevent} if( defined($state->{buttonevent}) );
- $readings{state} = $state->{presence}?'motion':'nomotion' if( defined($state->{presence}) );
- $readings{state} = $state->{fire}?'fire':'nofire' if( defined($state->{fire}) );
-
$readings{dark} = $state->{dark}?'1':'0' if( defined($state->{dark}) );
$readings{humidity} = $state->{humidity} * 0.01 if( defined($state->{humidity}) );
$readings{daylight} = $state->{daylight}?'1':'0' if( defined($state->{daylight}) );
+++ EDIT 2 +++
justme1968 hat einen 'fix' dafür eingecheckt. Es funktioniert jetzt einwandfrei :)
LG
Christian
Zitat von: HRE_7390_pi am 14 November 2018, 21:45:30
...
Jetzt mein Hauptanliegen:
3) folgende Einträge hab ich alle 6 Minuten im Log.
Da meine Hue Lampen noch nicht da sind und momentan also nur das Gateway läuft,
die frage ob es nur ein Status ist oder irgendwo ein Fehler in meiner Config:
2018.11.14 20:08:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:08:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:14:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:14:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:20:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:20:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:26:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:26:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:32:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:32:46 3: deCONZ: websocket: Switching Protocols ok
2018.11.14 20:38:46 3: deCONZ: websocket opened to 192.168.2.23:443
2018.11.14 20:38:46 3: deCONZ: websocket: Switching Protocols ok
Habe das selbe Problem, konntest du schon herausfinden, weshalb die Meldung auftaucht?
Gruß
Mathze
Hallo,
auch ich komme mit dem Push nicht klar, habe folgende Installation:
Raspi ConBeeII und fertigem SD-card-image: https://phoscon.de/en/conbee2/sdcard, dort "Raspbian Buster Headless", 2.05.69
Mittels Phoscon eine Tradfri und AQARA double wall switch eingebunden (und 2-3 andere)
In FHEM deCONZ und Sensor AQARA1 angelegt
Ich bekomme aber kein Push vom Schalter :(
DEF phoscon
FD 42
FUUID 5daaf21b-f33f-e163-ef96-14645526ade95371
FVERSION 30_HUEBridge.pm:0.198540/2019-07-19
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 926
NTFY_ORDER 50-deCONZ
PORT 52772
STATE connected
TYPE HUEBridge
apiversion 1.16.0
buf
host phoscon
mac b8:27:eb:21:08:e9
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
modelid deCONZ
name ConBeeII
swversion 2.5.69
updatestate 0
websocket 1
websocketport 443
zigbeechannel 15
READINGS:
2019-10-24 22:29:37 lastError resource, /lights/SAQARA_TH1, not available
2019-10-24 22:24:31 state connected
helper:
apiversion 69632
count 3
last_config_timestamp 1571948671
offsetUTC 7200
updatestate 0
groups:
1:
etag 8c655b3aee64bb903b35dc70e1925326
id 1
name Group 1
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
1
scenes:
state:
13617:
etag 5fcc109754557421085c7a1b482ca9e1
id 13617
name TRADFRI remote control 3
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
3
lights:
scenes:
state:
31106:
etag c13120cb8295419d05e6bff7da3f13fb
id 31106
name TRADFRI remote control 4
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
4
lights:
scenes:
state:
62567:
etag 8c655b3aee64bb903b35dc70e1925326
id 62567
name Group 62567
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
1
scenes:
state:
63113:
etag ecc3f9d1989a118995f879ae7a0ba15c
id 63113
name Group_Leo
type LightGroup
action:
bri 127
colormode ct
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
2
scenes:
state:
lights:
1:
ctmax 454
ctmin 250
etag 0f785e73d44ddef0b027c60a24efac4a
manufacturername IKEA of Sweden
modelid TRADFRI bulb E27 WS opal 980lm
name IKEA1
swversion 1.2.217
type Color temperature light
uniqueid 00:0b:57:ff:fe:da:e5:20-01
state:
alert none
bri 254
colormode ct
ct 454
2:
ctmax 454
ctmin 250
etag ecc3f9d1989a118995f879ae7a0ba15c
manufacturername IKEA of Sweden
modelid FLOALT panel WS 60x60
name IKEA_LEO
swversion 1.2.217
type Color temperature light
uniqueid 90:fd:9f:ff:fe:04:d2:d2-01
state:
alert none
bri 72
colormode ct
ct 454
scenes:
Attributes:
httpUtils 1
key 7ECE674A24
room TECH->HUE
verbose 5
DEF sensor AQARA1 60 IODev=deCONZ
FUUID 5daaf351-f33f-e163-dc90-8b85c1986a31eb63
FVERSION 31_HUEDevice.pm:0.203190/2019-10-06
ID SAQARA1
INTERVAL 60
IODev deCONZ
NAME AQARA1
NR 932
STATE Initialized
TYPE HUEDevice
helper:
devtype S
reachable 0
update_timeout 1
configList:
setList:
Attributes:
IODev deCONZ
color-icons 2
eventMap 1001:LeftLongPress
1002:LeftShortPress
1004:LeftDoublePress
2001:RightLongPress
2002:RightShortPress
2004:RightDoublePress
3001:DoubleLongPress
3002:DoubleShortPress
3004:DoubleDoublePress
icon taster
room TECH->HUE
verbose 1
im Log steht hin und wieder
resource, /lights/SAQARA1, not available
2019.10.24 19:44:36 2: deCONZ: message for unknown type received: lights/SAQARA1
Wie bekomme ich denn die Button-Events als Push?
VG Holger
noch mal komprimiert:
Hat die Standard-deCONZ-Installation mit FHEM HUEBridge schon die Push-Funktionalität,
oder muss man die noch mit Woodoo-Kniffen aktivieren?
VG Holger
Nach meinem Verständnis kann bei HUE-Geräten über DeConz in der Definition die Abfragezeit weggelassen werden. Diese Geräte erhalten ihre Informationen dann im Push-Verfahren.
Falls ich mich irre, bitte korrigieren.
Hallo,
ich habe mal zum testen einen Conbee 2 installiert und deconz im headless Mode, neueste Fimrware und neueste deconz Version.
2 Tradfri Lampen anglernt und eine Tradfri Remote.
Dann über ein HueBridge an fhem angebunden, er erkennt die Lampen und ich kann sie schalten.
Aber er erkennt nicht wenn ich eine Taste an der Tradfri Remote drücke, ich habe auch mal mit defmod Test HUEDevice S 2 IODev=ZigBee
das ganze angelegt, weil get Zigbee sensors mir sagt das die Tradfri Remote die ID 2 hat, aber auch das bringt nix.
Was mache ich noch falsch?
Grüße
Swen
Sowas habe ich noch in der log gefunden
Zitat
2019.11.05 18:03:02.668 2: ZigBee: message for unknown device received: ZigBee-2
2019.11.05 18:02:05.799 2: ZigBee: message for unknown type received: lights/S
2019.11.05 18:02:02.667 2: ZigBee: message for unknown device received: ZigBee-2
Habs rausgefunden musste defmod Test HUEDevice sensor 2 IODev=ZigBee heißen, damit hat es geklappt.
Ist es möglich die Nummer der aktuellen "scene" einer Gruppe als Readings ins HUEDevice zu bekommen?
Meine Bewegungsmelder sollen je nach aktuell gewählter scene Aktionen auslösen oder eben auch nicht.
Hier ein Auszug wie die Daten in einem REST Clienten aussehen.
{"action":{"bri":127,"colormode":"hs","ct":0,"effect":"none","hue":0,"on":true,"sat":127,"scene":"1","xy":[0,0]},"devicemembership":[],"etag":"e94d1b2383458caf3b4b31e0b62a7b26","id":"30","lights":["1","14","31","38"],"name":"Bad","scenes":[{"id":"1","lightcount":4,"name":"aus","transitiontime":0},{"id":"2","lightcount":4,"name":"decke","transitiontime":0},{"id":"3","lightcount":4,"name":"spiegelschrank","transitiontime":0},{"id":"4","lightcount":4,"name":"nachtlicht","transitiontime":0}],"state":{"all_on":false,"any_on":false},"type":"LightGroup"}
stimmt der wert denn auch noch wenn du eine der beteiligten lampen verstellst?
ps: ist das die antwort auf das setzen einer szene? oder siehst du dieses event auch wenn du dir szene über einen anderen weg aktivierst?
Hallo ich habe seit kurzem einen Conbee2 auf einem cubietruck laufen. Phoscon läuft in der Version 2.05.67. Der cubietruck läuft noch mit Jessie.
Ich wollte das umstellen auf eine neue Linuxversion noch etwas hinauszögern, da ich dann etwas mehr umstellen werde.
Deconz hat alle Geräte eingebunden und funktioniert soweit ohne Probleme. Leider wird mir in fhem bei allen Lampen ein falsches state angezeigt. Auch nach vielem lesen hier im Forum bin ich nicht weitergekommen. Im Alltag stört das nicht allzusehr, da es funktioniert. Habe aber auch drei Heiman Rauchmelder im zigbee-Netz, wo ich über ein DOIF das Licht einschalte und nach einer Zeit wieder auf den vorherigen Status zurück schalte. Ist dieser falsch, funktioniert das leider nicht wie gewünscht.
Ein list meiner bridge:
Internals:
.FhemMetaInternals 1
.triggerUsed 1
DEF 192.168.0.162:8090
FD 14
FUUID 5dc7c12a-f33f-70d2-8342-9fb7b4b58cf3b0e2
FVERSION 30_HUEBridge.pm:0.207430/2019-12-14
INTERVAL 60
NAME deCONZ
NOTIFYDEV global
NR 933
NTFY_ORDER 50-deCONZ
PORT 57164
STATE connected
TYPE HUEBridge
apiversion 1.16.0
host 192.168.0.162:8090
mac 02:03:04:01:d1:d0
manufacturer Royal Philips Electronics
modelName Philips hue bridge 2015
modelid deCONZ
name Phoscon-GW
swversion 2.5.67
updatestate 0
websocket 1
websocketport 8088
zigbeechannel 15
.attraggr:
.attrminint:
READINGS:
2019-12-19 08:06:09 lastError resource, /sensors/2, not available
2019-12-19 11:28:27 state connected
helper:
apiversion 69632
count 0
last_config_timestamp 1576751307
offsetUTC 3600
updatestate 0
groups:
1:
etag 42df2bcb50a77e73d880869ded6e4331
id 1
name TRADFRI on/off switch
type LightGroup
uniqueid 14:b4:57:ff:fe:91:9e:dd
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
3
lights:
scenes:
state:
3:
etag 1dd5b87093f010041931c4d5bf82d90b
id 3
name kueche
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
lights:
3
5
scenes:
state:
4:
etag a8d9d21cb8de8be7efb0797453127cac
id 4
name arbeitszimmer
type LightGroup
action:
bri 1
colormode hs
ct 0
effect none
hue 0
sat 0
scene
xy:
0
0
devicemembership:
lights:
1
scenes:
state:
5:
etag 1dd5b87093f010041931c4d5bf82d90b
id 5
name TRADFRI on/off switch
type LightGroup
uniqueid 14:b4:57:ff:fe:d4:bb:1b
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
21
lights:
3
5
scenes:
state:
58043:
etag 87ed004260a77a456c0ada50da275390
id 58043
name TRADFRI remote control 8
type LightGroup
action:
bri 127
colormode hs
ct 0
effect none
hue 0
sat 127
scene
xy:
0
0
devicemembership:
8
lights:
scenes:
state:
6:
etag 1240f73ce301404a90e2ad4ae5d6337f
id 6
name altan
type LightGroup
action:
bri 128
colormode hs
ct 0
effect none
hue 0
sat 128
scene
xy:
0
0
devicemembership:
lights:
4
scenes:
state:
lights:
1:
etag a8d9d21cb8de8be7efb0797453127cac
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Light 1
swversion 1.2.214
type Dimmable light
uniqueid 00:0b:3c:ff:fe:f6:f3:fc-01
state:
alert none
bri 254
2:
etag f0cb88a77310c8bf57a7c36560eef5ac
manufacturername IKEA of Sweden
modelid TRADFRI bulb E27 WW 806lm
name Light 2
swversion 2.1.022
type Dimmable light
uniqueid 14:b4:57:ff:fe:42:e9:c8-01
state:
alert none
bri 24
3:
etag f0cb88a77310c8bf57a7c36560eef5ac
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Light 3
swversion 1.2.214
type Dimmable light
uniqueid 00:0b:3c:ff:fe:f2:1d:a3-01
state:
alert none
bri 22
4:
etag 1240f73ce301404a90e2ad4ae5d6337f
manufacturername IKEA of Sweden
modelid TRADFRI bulb E27 WW 806lm
name Light 4
swversion 2.1.022
type Dimmable light
uniqueid cc:cc:cc:ff:fe:3b:3e:96-01
state:
alert none
bri 254
5:
etag 1dd5b87093f010041931c4d5bf82d90b
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Light 5
swversion 1.2.214
type Dimmable light
uniqueid 08:6b:d7:ff:fe:5c:84:48-01
state:
alert none
bri 22
6:
etag f637d42b5daa8a9f447bae7fb44891aa
manufacturername IKEA of Sweden
modelid TRADFRI bulb E27 WW 806lm
name Light 6
swversion 2.1.022
type Dimmable light
uniqueid 14:b4:57:ff:fe:45:e3:d1-01
state:
alert none
bri 0
7:
etag f637d42b5daa8a9f447bae7fb44891aa
manufacturername IKEA of Sweden
modelid TRADFRI bulb E27 WW 806lm
name Light 7
swversion 2.1.022
type Dimmable light
uniqueid 14:b4:57:ff:fe:51:ad:71-01
state:
alert none
bri 0
scenes:
Attributes:
comment https://forum.fhem.de/index.php/topic,101199.0.html
createGroupReadings 1
httpUtils 1
key DB0C5D2AED
noshutdown 1
pollDevices 2
queryAfterSet 1
room HUEDevice
Ein list einer Lampe, die in dem Moment ausgeschalten (aber am Netz) ist
Internals:
.FhemMetaInternals 1
CHANGED
DEF 1 IODev=deCONZ
FUUID 5dcedc8a-f33f-70d2-5142-9c6341e821546cc5
FVERSION 31_HUEDevice.pm:0.206950/2019-12-09
ID 1
INTERVAL
IODev deCONZ
NAME HUEDevice1
NR 934
STATE on
TYPE HUEDevice
desired 0
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Light 1
swversion 1.2.214
type Dimmable light
uniqueid 00:0b:3c:ff:fe:f6:f3:fc-01
.attraggr:
.attrminint:
READINGS:
2019-12-19 08:06:10 alert none
2019-12-19 08:06:10 bri 254
2019-12-17 22:04:18 last_state off
2019-12-19 11:30:26 onoff 1
2019-12-19 11:30:26 pct 100
2019-12-19 08:21:08 reachable 1
2019-12-19 11:30:26 state on
helper:
alert none
battery -1
bri 254
colormode
ct -1
devtype
effect
hue -1
pct 100
reachable 1
rgb
sat -1
update_timeout 1
xy
helper:
json:
etag 41e9515a079ca0b64061739a8a54e5d3
manufacturername IKEA of Sweden
modelid TRADFRI bulb E14 W op/ch 400lm
name Light 1
swversion 1.2.214
type Dimmable light
uniqueid 00:0b:3c:ff:fe:f6:f3:fc-01
state:
alert none
bri 254
Attributes:
IODev deCONZ
alias ZBArbeitszimmer
color-icons 2
comment {(HUEDevice_devStateIcon($name),"toggle")}
delayedUpdate 1
devStateIcon on:light_light_dim_100@red:off off:light_light_dim_00@green:on.*\b\d{1}(?!\d):dim06%@orange:off .*1\d.*:dim12%@orange:off .*2\d.*:dim25%@orange:off .*3\d.*:dim37%@orange:off .*4\d.*:dim43%@orange:off .*5\d.*:dim50%@red:off .*6\d.*:dim68%@red:off .*7\d.*:dim75%@red:off .*8\d.*:dim87%@red:off .*9\d.*:dim100%@red:of
fp_Allgemein 1850,29,2,Arbeitszimmer,
model TRADFRI bulb E14 W op/ch 400lm
room HUEDevice
subType dimmer
webCmd pct:toggle:on:off
Eventuell hat noch jemand einen Tip oder selbiges Problem.
Dank erst einmal.
Steffen
wie hast du die lampe geschaltet? ist es nach einem statusRequest richtig?
Die Lampe wurde mit einer tradfri Fernbedienung geschalten, die direkt mit der Lampe in Phoscon "verbunden" ist.
Auch nach einem statusRequest sind alle Lampen an, obwohl diese aus sind.
Kann es sein, das der conbee2 falsche Werte an fhem liefert?
wenn du lampen direkt mit einer fb schaltest bekommt zumindest die hue bridge das erst nach einiger zeit mit.
wie schaut es denn in phoscon aus?
hast du mal etwas gewartet?
Wenn ich an einer Fernbedienung schalte, bekommt das fhem relaitv schnell mit. Und das reading stimmt auch. Aber nach einer gewissen Zeit (konnte noch nicht genau messen, wie lange) werden die Lampen nur in Phoscon auf "ein" angezeigt (teilweise der vorherige wert, teilweise für mich nicht nachvollziehbar) und fhem bekommt die readings, obwohl die Lampen aus sind/nicht leuchten.
Sieht für mich eher nach Phoscon-problem aus, da ich in fhem nichts schalte.
Ich habe jetzt den conbee2 an einen eigenen Raspberry gesteckt, wo das deconz 2.05.72 alleine drauf läuft. Mal schauen ob es damit besser wird.
Gibt es eine Möglichkeit sowas wieder in einem Device zusammen zufassen? Sodas man am ende nur ein Gerät hat?
define Sensor4.Temperatur HUEDevice sensor 7
define .Sensor4.Feuchtigkeit HUEDevice sensor 8
define Sensor4.Luftdruck HUEDevice sensor 9
nein. im api sind das getrennte devices.
ZitatGibt es eine Möglichkeit sowas wieder in einem Device zusammen zufassen? Sodas man am ende nur ein Gerät hat?
Code: [Auswählen]
define Sensor4.Temperatur HUEDevice sensor 7
define .Sensor4.Feuchtigkeit HUEDevice sensor 8
define Sensor4.Luftdruck HUEDevice sensor 9
Über userReadings und dann stateFormat kam man es dann in einem Device zusammen fassen.Man muss aber erst alle drei Sensoren anlegen,dann kann man es in einem zusammen fassen.
Beste Grüße
Falkes
user readings sind nur für die eigenen daten eines device. nicht um aktuelle werte device übergreifend zu verarbeiten.
dazu muss man notify oder ähnliches verwenden.
Hier ein list vom device:
ZitatInternals:
DEF sensor 8 IODev=deConzSensors
FUUID 5dca7d13-f33f-178a-a3e1-c2b6f2baecc25d05
FVERSION 31_HUEDevice.pm:0.213650/2020-03-06
ID S8
INTERVAL
IODev deConzSensors
NAME Bad.Sensor.Temp
NR 221
STATE T: 19.0 H: 47.1 P: 968 BAT: 95 %
TYPE HUEDevice
lastupdated 2020-03-28 13:13:36
lastupdated_local 2020-03-28 14:13:36
manufacturername LUMI
modelid lumi.weather
name Multisensor Bad
on 1
reachable 1
swversion 20161129
type ZHATemperature
uniqueid 00:15:8d:00:03:23:17:13-01-0402
READINGS:
2020-03-28 13:36:41 battery 95
2020-03-28 14:13:36 humidity 47.14
2020-03-28 14:13:36 pressure 968
2020-03-28 13:36:41 reachable 1
2020-03-28 14:13:36 temperature 18.99
helper:
devtype S
reachable 0
update_timeout 1
configList:
json:
ep 1
etag 3ef33064bc6ac586c543447d394c1891
manufacturername LUMI
modelid lumi.weather
name Multisensor Bad
swversion 20161129
type ZHATemperature
uniqueid 00:15:8d:00:03:23:17:13-01-0402
config:
battery 95
offset 0
state:
lastupdated 2020-03-28T13:13:36
temperature 1899
setList:
Attributes:
IODev deConzSensors
group DeConz_Sensor
icon xiaomi_multi
model lumi.weather
room DeConz_Sensors
stateFormat {sprintf("T: %.1f H: %.1f P: %.i BAT: %.i %%",ReadingsVal($name,"temperature",0),ReadingsVal($name,"humidity",0),ReadingsVal($name,"pressure",0),ReadingsVal($name,"battery",0))}
userReadings temperature {ReadingsVal("Bad.Sensor.Temp","temperature",0)}, humidity {ReadingsVal("Bad.Sensor.Hum","humidity",0)-3.5 },pressure {ReadingsVal("Bad.Sensor.Baro","pressure",0)}
Für mich vollkommen ausreichend als Anzeige der Sensoren zusammen gefasst.
das geht aber nur mehr oder weniger zufällig weil im api die daten für alle devices vermutlich auf ein mal aktualisiert werden und abhängig von der reihenfolge. vermutlich hast du so immer noch den vorherigen und nicht den aktuellen wert. wenn sich z.b. nur Bad.Sensor.Hum ändert wird Bad.Sensor.Temp nicht aktualisiert.
es ist besser die werte jeweils über ein notify zu kopieren.
ps: die diversen ReadingsVal in stateFormat sind eigentlich nicht nötig. du kannst die hier: https://fhem.de/commandref.html#set (https://fhem.de/commandref.html#set) beschriebenen suffixe zum runden auch in stateFormat verwenden. das würde dann etwa so aussehen: T: temperature:r1 P: pressure:i .... ich denke das ist übersichtlicher.
Hallo zusammen,
mittlerweile werden von deconz über die push-api auch die Werte lastseen und lastannounced übergeben. Siehe hier:
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2590 (https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2590)
Besteht die Möglichkeit, in einem kommenden Update der Module HUEBridge und/oder HUEDevice diese Wete in einem HUEDevice als Reading einzufügen? Momentan löse ich das so, dass ich per HTTPMOD lastseen und lastannounced von deconz (2.05.79, RaspBee auf einem RasPi 3B) auslese (alle 60 Sekunden), und diese dann per notify in das entsprechende Device schreibe. Schicker wäre es natürlich (und dann durch push auch immer aktuell), wenn die Werte direkt als Reading kommen würden.
Hier mal ein list von einer Lampe, die schon mehr als zwei Minuten vom Strom getrennt ist, aber dennoch als "on" angezeigt wird:
Internals:
DEF 15 IODev=HUEBridge2
FUUID 5edd3534-f33f-c0d6-9d07-2f6a2f752a8ed571
FVERSION 31_HUEDevice.pm:0.218370/2020-05-02
ID 15
INTERVAL
IODev HUEBridge2
NAME HUEBridge2_HUEDevice15
NR 387
STATE on
TYPE HUEDevice
desired 1
manufacturername Philips
modelid LWB010
name diei_lmpw_Deckenleuchte
swversion 1.50.2_r30933
type Dimmable light
uniqueid 00:17:88:01:04:cb:bb:8c-0b
READINGS:
2020-08-21 20:52:19 alert none
2020-08-21 20:52:19 bri 254
2020-08-23 21:14:30 onoff 1
2020-08-23 21:14:30 pct 100
2020-08-30 18:18:31 reachable 1
2020-08-30 18:18:31 state on
helper:
alert none
battery -1
bri 254
colormode
ct -1
devtype
effect
hue -1
mode
pct 100
reachable 1
rgb
sat -1
update_timeout -1
xy
json:
etag 606dfe3917c59363cabc3dc42ecc4669
lastannounced 2020-08-30T16:18:31Z
lastseen 2020-08-30T16:19:10Z
manufacturername Philips
modelid LWB010
name diei_lmpw_Deckenleuchte
swversion 1.50.2_r30933
type Dimmable light
uniqueid 00:17:88:01:04:cb:bb:8c-0b
state:
alert none
bri 254
Attributes:
IODev HUEBridge2
alias diei_lmpw_Deckenleuchte
color-icons 2
devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
fp_Grundriss 601,602,0,HUEBridge2_HUEDevice15,
group HUEDevice
icon hue_filled_white_e27_b22
model LWB010
room 1_DieleEingang,HUEDevice
subType dimmer
webCmd pct::toggle:on:off
Hintergrund: Leider gibt es bei mir in der Wohnung (Mietwohnung, daher kurzfristig nicht änderbar) noch ein paar Lampen, die direkt über den Netzschalter ausgeschaltet werden. Da in deconz (und dann auch in fhem) diese Lampen teilweise erst nach vielen Minuten als "unreachable" markiert werden, sind diese Lampen im Floorplan noch lange "on", obwohl sie mangels Strom eigentlich "off" bzw. "unreachable" sind. Ich würde jetzt gerne mit doif oder notify eine Formel basteln, die in Abhängigkeit von lastseen die Lampen in fhem einfach ausschaltet wenn davon auszugehen ist, dass diese vom Strom getrennt wurden (z. B. lastseen ist älter als 120 Sekunden). Dafür sollten lastseen und lastannounced aber nach Möglichkeit immer aktuell sein.
Oder hat von euch schon jemand eine ähnliche Überlegung gehabt und auch schon eine praktikabele Lösung parat?
Gruß
Thomas
siehe: https://forum.fhem.de/index.php/topic,95288.msg1090054.html#msg1090054 (https://forum.fhem.de/index.php/topic,95288.msg1090054.html#msg1090054)
Hallo zusammen.
Ich habe mir jerzt den ConBee 2 Stick gekauf. Habe diesen auch in FHEM integriert. Läuft !
Jetzt zu meinem Problem.
Ich habe die SW deconz auf einem Win10 rechner installiert. Der Stcik läuft an einem Raspi.
Wie kann ich deconz dazu bringen, dass der stick auf dem raspi gefunden wird? mir geht es hauptsächlich um die Anzeige von dem Netzwerk.
Oder gibt es eine Möglichkeit dies auch in FHEm anzeigen zu lassen ?
Gruß und Danke
Sascha
Moin,
du kannst dir das Netzwerk auf dem Raspi per VNC Viewer Anzeigen lassen, bin mir nur nicht sicher ob dafür ein Desktop auf dem Raspi installiert sein muss.
https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1989
Gibt es da keine andere Möglichkeit?
Neee...leider nicht.
Hallo zusammen
ich bräuchte mal Unterstützung bei der Integration einens neuen Sensors.
Ich habe mir eine "Tuya Zigbee Smart Sirene mit Temperatur- und Feuchtigkeitsmessung" gekauft.
Deconz hat das Gerät auch erkannt und in FHEM sehe ich jetzt 3 Sensoren vom Typ Humidity, Temperature und Alarm.
So weit - so gut.
Die Sensoren für Humidity und Temperature liefern in ihren Readings auch brav ihre Werte.
Der Alarm-Sensor ist da bei den Readings aber etwas schweigsamer und beschränkt sich auf IOdev - hier mal ein list für das Device:
Internals:
DEF sensor 11 IODev=deCONZ
FUUID 61940d13-f33f-9e1b-2077-c456123bb851db26
FVERSION 31_HUEDevice.pm:0.239120/2021-03-08
ID S11
INTERVAL
IODev deCONZ
NAME HUESensor11
NR 925
STATE ???
TYPE HUEDevice
lastannounced 2021-11-19T17:59:12Z
lastupdated
lastupdated_local
manufacturername _TZE200_d0yu2xgi
modelid TS0601
name Alarm 11
on 1
reachable 1
type ZHAAlarm
uniqueid 5c:02:72:ff:fe:ce:bb:a0-01-0500
READINGS:
2021-11-19 19:12:51 IODev deCONZ
helper:
devtype S
reachable 0
update_timeout 1
configList:
json:
e changed
id 11
r sensors
t event
uniqueid 5c:02:72:ff:fe:ce:bb:a0-01-0500
attr:
id 11
lastannounced 2021-11-19T17:59:12Z
lastseen 2021-11-20T19:06Z
manufacturername _TZE200_d0yu2xgi
modelid TS0601
name Alarm 11
productid NAS-AB02B0 Siren
swversion
type ZHAAlarm
uniqueid 5c:02:72:ff:fe:ce:bb:a0-01-0500
setList:
Attributes:
IODev deCONZ
alias Alarm 11
group HUESensor
model TS0601
room HUEDevice
Über die Api kann ich sehen, dass als state u. a. der Wert "alarm" verfügbar ist.
{"config":{"enrolled":5,"humiditymaxthreshold":null,"humidityminthreshold":null,"melody":null,"on":true,"pending":[],"preset":null,"reachable":true,"temperaturemaxthreshold":null,"temperatureminthreshold":null,"volume":null},"ep":1,"etag":"9925f50203e05066ee56c056463c6ad1","lastannounced":"2021-11-19T17:59:12Z","lastseen":"2021-11-20T19:08Z","manufacturername":"_TZE200_d0yu2xgi","modelid":"TS0601","name":"Alarm 11","state":{"alarm":false,"lastupdated":"none"},"type":"ZHAAlarm","uniqueid":"5c:02:72:ff:fe:ce:bb:a0-01-0500"}
Den Wert für Alarm würde ich gerne bei den Readings sehen.
Weiter vorne in diesem Thread habe ich gesehen, dass das grundsätzlich über eine zusätzliche Reading-Definition in der 31_HUEDevice.pm möglich ist.
Also habe ich dort folgende Zeile ergänzt und fhem neu gestartet:
$readings{alarm} = $state->{alarm}?'true':'false' if( defined($state->{alarm}) );
Leider hat sich bei den Readings nichts verändert.
Ich frage mich jetzt, ob ich da auf dem richtigen Weg bin oder irgednwo einen Denkfehler habe oder etas übersehen habe.
Kann mich da bitte jemand in die richtige Richtung schubsen?
LG
Eddi
Hallo Eddi,
Versuche mal
$readings{alarm} = $state->{alarm} if ( defined($state->{alarm}) );
Grüße
Hallo CoolTux
Danke für den Tipp.
Ich glaube die Variante hatte ich auch schon mal probiert.
Habs jetzt aber so wie von dir vorgeschlagen eingetragen - leider ohne Erfolg.
Muss ich außer FHEM restarten sonst noch irgendwas machen oder müsste die Änderung dann sofort ziehen?
Eddi
Nur neustarten. Musst aber auf die Zeilen achten. Aktuell wäre der Eintrag gut so ab Zeile 1629 auf gehoben
$readings{water} = $state->{water} if( defined($state->{water}) );
$readings{fire} = $state->{fire} if( defined($state->{fire}) );
$readings{tampered} = $state->{tampered} if( defined($state->{tampered}) );
$readings{battery} = $state->{battery} if( defined($state->{battery}) );
$readings{batteryPercent} = $state->{battery} if( defined($state->{battery}) );
$readings{alarm} = $state->{alarm} if( defined($state->{alarm}) ); <-------------------------------------------------------
Habs jetzt wie vorgeschlagen platziert:
$readings{water} = $state->{water} if( defined($state->{water}) );
$readings{fire} = $state->{fire} if( defined($state->{fire}) );
$readings{tampered} = $state->{tampered} if( defined($state->{tampered}) );
$readings{battery} = $state->{battery} if( defined($state->{battery}) );
$readings{batteryPercent} = $state->{battery} if( defined($state->{battery}) );
$readings{alarm} = $state->{alarm} if ( defined($state->{alarm}) );
$readings{batteryState} = $state->{lowbattery}?'low':'ok' if( defined($state->{lowbattery}) );
Leider ohne Erfolg.
Testweise hab ich es auch unter batteryState geschoben - aber gleiches Ergebnis.
Kann man über einen höheren verbose-Level (dann vermutlich bei der HueBridge?) da irgendwas mitlesen. Welcher Level wäre dann sinnvoll?
ich habe alarm hinzugefügt. ist ab morgen im update.
aber so lange lastupdated auf none steht gibt es noch kein reading und es wird nichts angezeigt. sobald es das erste mal einen alarm gab sollte das reading auch angelegt werden.
Hallo justme
Zitat
ich habe alarm hinzugefügt. ist ab morgen im update.
aber so lange lastupdated auf none steht gibt es noch kein reading und es wird nichts angezeigt. sobald es das erste mal einen alarm gab sollte das reading auch angelegt werden.
Danke für die schnelle Unterstützung und Umsetzung!
Es hat zwar etwas gedauert und ich weiß noch nicht ganz genau welcher Aufruf der API jetzt dazu geführt hat, aber nach mehreren Fehlversuchen war pötzlich das Reading da:
Readings
IODev deCONZ 2021-11-22 18:32:02
alarm 0 2021-11-22 21:26:47
reachable 1 2021-11-22 21:26:48
Ich bin zwar noch nicht so sicher, wie ich jetzt über FHEM einen Alarm auslösen kann (das ist ja am Ende das Ziel), aber damit beschäftige ich mich dann ab morgen.
Eddi
Hallo Community,
hoffe ich bin in diesem Faden richtig mit meinem Problem.
Habe einen Zigbee Rauchmelder Heiman HS3SA auf einem Conbee II mit Phoscon/deconz angelernt. Funktioniert hat das. Allerdings kommt ein Update anscheinend nur, wenn Alarm (bis jetzt nur mit Testknopf drücken) ausgelöst wird. Dann aber verlässlich.
D.h. die Readings werden laut Zeitstempel zwischendurch nicht upgedated und ich kann somit über die readings nicht feststellen, ob das Device noch sendet bzw. den aktuellen Batterielevel auslesen.
Hier mal ein paar Versionsinfos:
Zitat
fhem.pl 26115 2022-06-04 09:50:00Z rudolfkoenig
30_HUEBridge.pm 26204 2022-07-09 18:04:20Z justme1968
Phoscon:
Version 2.17.00 / 07/06/2022
Firmware 26720700
Interessant finde ich, dass wenn ich mir die API in Phoscon anschau, dass lastseen sehr wohl mehrmals pro Tag einen neuen Zeitstempel hat. lastupdate hingegen nicht, wenn nix passiert.
"4": {
"config": {
"battery": 100,
"enrolled": 1,
"on": true,
"pending": [],
"reachable": true
},
"ep": 1,
"etag": "0edc0c11b813d2879ffaef733cd96574",
"lastannounced": null,
"lastseen": "2022-08-18T08:53Z",
"manufacturername": "Heiman",
"modelid": "SmokeSensor-EM",
"name": "Schlafzimmer Smoke Sensor",
"state": {
"fire": false,
"lastupdated": "2022-08-18T07:54:32.982",
"lowbattery": false,
"tampered": false
},
"swversion": "1.1.1",
"type": "ZHAFire",
"uniqueid": "00:0d:6f:00:16:4a:13:b0-01-0500"
}
}
Das lastseen Reading des Devices im fhem zeigt aber das Datum vom lastupdate der API an und nicht von lastseen der API:
Zitat
lastseen 2022-08-18T07:54Z 2022-08-18 09:54:32
Passt hier was nicht zusammen oder hab ich da einen Denkfehler?
Danke!
Hallo zusammen,
ich weis, dieses Thema schläft bereits seit 120 Tage ... aber ich habe das gleiche Problem und steige nicht durch.
Ich habe ebenfalls Heiman SmokeSensor-EF-3.0 im Einsatz und kann in deConz API ein mehrfach aktualisiertes "lastseen" sehen.
Nach fhem wird dieser Wert jedoch nicht übertragen.
Ich meine alles auf aktuellem Stand zu haben und hab einiges gelesen ... ich verstehe trotzdem nicht was ich tun kann bzw. muss.
Wer also das lastseen für dieses Device sieht, kann mir vielleicht weiterhelfen.
Römi
Hi,
ich habe es letztlich mit HTTPMOD gelöst und über die API das lastseen ins fhem geholt.
lg, Matthias
Das mit lastseen ist ja nicht nur bei diesem Smoke Sensor so, bei vielen Sensoren erscheint das der der Wert den die API eigentlich bei lastupdated liefert. Und der ist dann oft ein älterer Timestamp.
Da ist wohl noch Fehler im Modul.
Ich hab gerade mal ins Modul geschaut weil ich das Reading auch aktualisiert für ein paar Sensoren sehen wollte. lastseen wird wohl nur aktualisiert wenn sich im state Teil der json von Deconz etwas ändert, also lastupdated geändert wird. Nur dann wird auch lastseen als Reading geschrieben.
Bei z.B. Temperatursensoren kommt da oft genug etwas, bei Fernbedienungen nur wenn man einen Button betätigt und bei Rauchmeldern eben nur wenn es brennt.
Als Internal kann man es leicht aktuell bekommen, da kann man aber nicht mitloggen oder ein notify drauf setzen.