Push-API (deCONZ)

Begonnen von ct, 29 Dezember 2016, 00:41:22

Vorheriges Thema - Nächstes Thema

ct

Hallo,

für diejenigen, die entweder den ConBee-USB-Stick oder das ZigBee Aufsatzmodul für den Raspberry Pi von Dresden Elektronik besitzen/verwenden, dürfte das hier ganz nützlich sein.

Da es bisher noch keine Push-API für Hue, Lightify, etc. gibt, habe ich das Rest-Plugin von deCONZ etwas erweitert und sowohl eine Push-API als auch eine direkte bzw. schnelle FHEM-Push-Unterstützung eingebaut, damit Änderungen von Schaltern, Lichtern, etc. unmittelbar ohne Verzögerung an FHEM weitergeleitet werden.

Damit kann eine Konfiguration basierend auf HUEBridge/HUEDevice auf Push aufgerüstet werden.
Ich selbst nutze die Erweiterung mit dem ConBee-USB-Stick zusammen mit Hue Lampen, Hue Schalter, Osram Lampen, Osram Schaltsteckdosen.
(Bei Farblampen muss noch ein kleiner Bugfix (3 Zeilen Code) angepasst werden, damit ein "set rgb" funktioniert. Falls erforderlich, dann einfach kurz PM an mich.)

Das ganze findet sich hier https://hcm-lab.de/git/project/deconz-push
(Für FHEM sind die Schritte 3 u. 5 unter https://hcm-lab.de/git/project/deconz-push#usage NICHT notwendig.)

Dadurch können auch die Dimmer Switch oder Hue Tap als günstige Schalter bzw. Buttons in FHEM zum Schalten von allen Aktoren (z.B. Steckdosen, etc.) genutzt werden. Weiterhin kann das Poll-Intervall in FHEM auf einmal die Stunde oder noch länger verändert werden, da ja jede Änderung unmittelbar ohne Verzögerung in FHEM zu sehen sind.

Die FHEM-Push-Unterstützung funktioniert zwar bei mir schon länger stabil, aber es kann durchaus sein, dass der eine oder andere Bug noch drin ist. Beim Ausprobieren sollte daher ein Gerät nach dem anderen "ausprobiert" werden.
(Die andere bisher experimentelle Push-API wird vermutlich mit justme ausgebaut, sofern es die Zeit bei uns zulässt. Kann allerdings dauern, bis das wirklich nutzbar ist.)

Feedback ist herzlich Willkommen bzw. wenn jemand mitentwickeln will, dann einfach Bescheid geben.

Grüße,
  ct

Dave90

Das klingt ja sehr interessant, vielen Dank für die Arbeit :).

Ist mit der Push Api dann auch das Differenzieren der unterschiedlichen Schaltvorgänge an den Dimmschaltern möglich? Also kurz drücken, lange drücken? Die lassen sich ja bisher schwer auseinander halten, auch wenn man im 1 sek. Intervall pollt.

Viele Grüße
David

Hardware:  FHEM-& LMS-Server + NAS: Banana Pi; Hyperion Ambilight Server + anderer Kleinkram: RPI Model B; Lampen: Philips Hue + Milight; Homematic Heizungssteuerung; Entertainment: Harmony Hub
sonstiges: Funksteckdosen

ct

#2
Hallo David,

nichts zu danken. Hat Spaß gemacht  :)
Zur Zeit kann leider nur unterschieden werden, wann welcher Button gedrückt wurde. Es geht aber kein Schaltvorgang verloren egal wie oft und wie schnell ein Button gedrückt wird. Ich habs noch nicht getestet, aber z.B. 3 mal innerhalb einer Sekunde sollte funktionieren. Mit jedem Schaltvorgang wird auch die Sequenznummer für den entsprechenden Button erhöht, z.B. Reading button0, button1, button2, etc...

Um den Dimmer Switch zu unterstützen (dieser ist nicht richtig in deCONZ unterstützt) wird die Funkkommunikation zwischen Bridge und Switch mitgelauscht und bisher konnte ich keine eindeutige Kommunikation ausmachen, aus welcher sich "das Loslassen" eines Buttons ableiten lassen lässt. Vielleicht lässt sich auch erkennen ob mehrere Buttons gleichzeitig gedrückt sind. Ich gehe dem noch nach, wenn es die Zeit zulässt (bzw. falls überhaupt Interesse besteht).
Oder (was besser wäre) mit dem nächsten Release von deCONZ wird die Unterstützung verbessert.

Viele Grüße,
  ct

Tom15

Hallo

Danke erstmal für die Arbeit an der Push-API  :)
Ich versuche derzeit einen Philips Dimmer Switch über einen Raspbee in FHEM zu integrieren. Jedoch ohne Erfolg. Der Switch wird als initialized angezeigt und es können keine Schaltzustände überprüft werden. Auch bei einer Auswertung des Switches mit JSON wird der State (in diesem Fall sollte glaube "buttonevent" mitgesendet werden) nicht angezeigt.
Wie bekomme ich diese Schaltzustände in meine FHEM Readings?

Schöne Grüße
Tom

ct

Hallo Tom,

keine Ursache. DE hat vor ein oder zwei Tagen die Software aktualisiert und ich bin mir nicht sicher ob das Plugin mit der Firmware funktioniert. Es lässt sich zumindest kompilieren, aber ausprobieren möchte ich es erst am Wochenende, wenn ich etwas mehr Zeit habe.

In der bisher untersützten Version, erzeugt das Plugin eigene Readings mit den Namen aus meinem vorherigen Post. Ich habe andere Name gewählt, um möglichen Konflikten aus dem Weg zu gehen und da ich davon ausgehe, dass die JSON-API in naher Zukunft auch für den Dimmer Switch funktioniert.

Kannst du mir sagen, welche Version von deCONZ du verwendest und auf welcher Firmware-Version der Raspbee läuft?
Die Versionen findest du normalerweise in der deCONZ-WebApp.

Und hast du nach dem Installieren der Erweiterung sowohl FHEM als auch die deCONZ-Software neu gestartet?
(Oder den Raspbee rebooten, wenn du auf Nummer sicher gehen willst).

Grüße,
ct

Tom15

Danke für deine Unterstützung :)
deCONZ Version: 2.04.18
Firmware Version: 0x260B0500
Der Raspberry wurde dann neu gestartet. Die Installation des Plugins sollte funktioniert haben da keine Fehlermeldung auftrat.
Am Raspbee wurden die beiden InClusters 0x0006 (ON/OFF) und 0x0008 (dimm) mittels binding mit dem Switch verbunden und sollte somit Kommandos empfangen. 
In FHEM der Switch nur mit dem Status initialized und den Readings battery und reachable angezeigt..

LG
Tom


ct

#6
Hm.. Damit müsste es eigentlich klappen. Bevor wir uns die Debug-Logs ansehen, nur um sicher zu gehen, dass die Ursache nicht etwas einfach lösbares ist...

Ist in deiner FHEM-Installation telnet aktiviert?
also gibt es ein "define telnetPort telnet 7072 global" in deiner fhem.cfg?
Und wird für telnet user/pass bei dir benötigt?
Über telnet spricht das Plugin sozusagen mit FHEM. Das geht einfach am schnellsten.

Grüße,
ct

Tom15

telnet wurde mit define telnetPort telnet 7072 global definiert
Im Everything:
telnet
telnetPort Initialized

Passwort habe ich keines definiert.

Hier meine Definition im config file:
define raspGW HUEBridge 10.0.0.2
attr raspGW key XXXXXXXXXXXXXXXx
attr raspGW verbose 5
setreading raspGW push 1
setreading raspGW pushSocket 1
setreading raspGW fhemtunnel 1
setreading raspGW fhemPort 7072
setreading raspGW pushPort 7073

define DimmerSwitch HUEDevice sensor 14 60

Mir ist aufgefallen, dass wenn die setreadings oben auskommentiert sind, ein zusätzlicher telnetPort online geht:
telnetPort_127.0.0.1_46398 Connected
Habe die bridge und den Switch bereits mehrmals angelernt und wieder entfernt.

LG Tom

ct

#8
Hallo Tom,

ok. Dann schauen wir uns mal die Logs an. Lass die Readings in der raspGW am besten auskommentiert. Insbesondere "pushSocket" wurde bisher nicht sehr gut getestet, da es momentan keine FHEM-Aktivität gibt, die sich mit dem Plugin per socket verbindet. Es ist eher für zukünftige Push-Nutzungen unabhängig von FHEM, z.B. OpenHAB, usw... vorgesehen.

Kannst du folgendes ausführen:
- In dem Verzeichnis, in welchem du deconz-push entpackt/gecloned hast. Folgendes ausführen:
- ./install.sh 1
- Danach deCONZ stoppen und neu starten. (Normalerweise wird deCONZ mit dem Installieren automatisch beendet.)

Damit wird die Debug-Version installiert. (install.sh ohne jegliche argumente installiert wieder die Release-Version.)
Nach dem Starten werden folgende 2 log-Dateien erzeugt:
/tmp/raspBeeBridge.log
/tmp/beeBridge.log

Achtung: Diese Dateien werden seeeehr groß... Daher sollte die Debug-Version nur für log-Zwecke verwendet werden.

Wenn deCONZ das ZigBee-Mesh einigermasen "wiederentdeckt" hat, dann betätige den Dim-Switch mehrmals und am besten alle möglichen Tasten mehrmals.

Danach wieder die Release-Version installieren. Im deconz-push-Verzeichnis:
- ./install.sh
- Danach deCONZ stoppen und neu starten.

Jetzt müsstest du die zwei log-Dateien vom RaspBee kopieren und (am besten als zip gepackt) mir per PM schicken. Hier anhängen würde ich nicht empfehlen, da ich nicht sicher bin, ob und welche sicherheitsrelevanten Daten enthalten sein könnten.

Dateien packen:
- cd /tmp
- tar -cf log.tar raspBeeBridge.log beeBridge.log
- gzip -9 log.tar

Schaue am bestens sicherheitshalber grob durch die Dateien, dass nichts Privates als Name enthalten ist. Falls doch, dann ersetze die Name durch ZZZZ oder so...

Ich kopiere mir die Dateien immer per samba, aber vermutlich ist es am einfachsten, wenn du einen usb-stick als Medium verwendest. Gib Bescheid, wenn du dabei Hilfe brauchst.

Grüße,
ct


ct

UPDATE:

Ich habe gerade die Release-Binary vom git-Repo nochmal getestet und es scheint sich da ein Bug eingeschlichen zu haben. Bin mir allerdings nicht sicher, ob es wirklich daran liegt, weil ich mein System und das Repo bereits auf die neue Version 2.04.35 angepasst habe.
Kannst du die aktuelle Version vom Plugin mal ausprobieren?

Die ist zwar für die neue Version 2.04.35, aber funktioniert auch mit der vorherigen Version von deCONZ.

Also am besten entweder das Zip-Archiv (https://hcm-lab.de/git/project/deconz-push/repository/archive.zip?ref=master) nochmal runterladen oder im geclonten Verzeichnis:
- git pull

und dann:
- install.sh

Wenn sich viel mehr als ca. 15 Readings bei einem Licht/Schalter ändern bzw. hinzugekommen sind, dann sollte das Plugin aktiv sein.

Grüße,
ct

Tom15

Habe zuerst wie du beschrieben hast das git pull update durchgeführt. Jedoch ohne Erfolg. Noch immer keine Readings :(
Anschließend hab ich die Debug Version installiert. Die Log files dazu sende ich dir.

Nochmals vielen Dank für deine Hilfe  :)

LG Tom

ct

Danke für die Logs.

Also laut der config wurden der Dimmer-Switch nicht richtig gefunden. In der /usr/share/deCONZ/rest_push.txt müsste ein Eintrag für DimSW vorhanden sein. Daher sollten die Readings eigentlich nicht aktualisiert werden.

Kannst du folgendes in fhem ausführen (also in das fhem-Eingabefeld):
{deCONZ_build_config()}

Danach sollten in der fhem-log einige Zeilen mit deCONZ_build_config: ... erfolgen.
Kannst du mir diese Zeilen hier posten?

Am besten wäre, wenn du die Datei /opt/fhem/FHEM/99_myDeconz1.pm durch die folgende ersetzt. (Mach dir eine Kopie von der vorherigen, damit du diese wiederherstellen kannst.)
https://hcm-lab.de/cloud/index.php/s/GMKY4ugMUAFojJS
Passwort: 1234

In dieser Datei ist das Loglevel auf 1 gesetzt und es werden mehr Debug-Meldungen erzeugt. Dadurch kann ich u.U. feststellen, wo noch ein Bug sein könnte.

Tom15

Hier nochmal der Inhalt von rest_pust.txt:
2 fport 7072
2 pport 7073
#0 disable
0 disablepush
0 nonodeupdate

Die Readings des Dimmer Switches scheinen jetzt zu funktionieren, das bei Tastendruck der Wert des jeweiligen Buttons hochgezählt wird.
Nach Eingabe von {deCONZ_build_config()} erstellte sich folgender log Eintrag:
2017.02.18 19:07:14 1: deCONZ_build_config: Successfully added 2 device and 1 group mappings.

Mit der aktualisierten Datei ergeben sich folgende log Einträge:
2017.02.19 10:46:04 1: deCONZ_build_config: Bridge found!
2017.02.19 10:46:04 1: deCONZ_build_config: enable_push 1
2017.02.19 10:46:04 1: deCONZ_build_config: enable_fhem 1
2017.02.19 10:46:04 1: deCONZ_build_config: enable_push_socket 0
2017.02.19 10:46:04 1: deCONZ_build_config: enable_nodeupdate 0
2017.02.19 10:46:04 1: deCONZ_build_config: pport 7073
2017.02.19 10:46:04 1: deCONZ_build_config: Device raspbeeGW-G0 -> 23!
2017.02.19 10:46:04 1: deCONZ_build_config: Device raspbeeGW-S1 -> 25!
2017.02.19 10:46:04 1: deCONZ_build_config: Device 23
2017.02.19 10:46:04 1: deCONZ_build_config: Device 23 is missing a uniqueid!
2017.02.19 10:46:04 1: deCONZ_build_config: Group All -> HUEGroup0
2017.02.19 10:46:04 1: deCONZ_build_config: Device 25
2017.02.19 10:46:04 1: deCONZ_build_config: Device DimmerSwitch -> 0x00178801105fa0e4 (6623462615392484)
2017.02.19 10:46:04 1: deCONZ_build_config: Bridge raspbeeGW -> b8:27:eb:6c:c8:cf (202481593010383)
2017.02.19 10:46:04 1: deCONZ_build_config: Group All : HUEGroup0
2017.02.19 10:46:04 1: deCONZ_build_config: Device uid 202481593010383 : raspbeeGW
2017.02.19 10:46:04 1: deCONZ_build_config: Device uid 6623462615392484 : DimmerSwitch
2017.02.19 10:46:04 1: deCONZ_build_config: Successfully added 2 device and 1 group mappings.

LG Tom

ct

#13
Hallo Tom,

Danke für die Logs. Soweit sehen die Logs sehr gut aus und es sollte eigentlich alles funktionieren. Lediglich die fehlenden Einträge in der rest_push.txt machen mich etwas stutzig. Eigentlich sollten Einträge für zwei Geräte (Gateway u. Switch) und eine Gruppe enthalten sein.

Wenn ich richtig verstanden habe, werden die Schaltaktionen des Dimmer-Switch jetzt korrekt als Readings in FHEM abgebildet?

Grüße,
ct

Tom15

Ja die Readings werden jetzt korrekt angezeigt. Danke nochmals dafür :)
Ich werde in den nächsten Tagen mal die Button und PIR Sensoren von Xiaomi damit testen.
Können eigentlich Sensordaten wie z.B Lux Werte vom HUE Motion Sensor auch in die Readings aufgenommen werden?

LG Tom

ct

#15
Keine Ursache. Ich bin nochmal deine Rückmeldungen durchgegangen und habe ganz übersehen, dass du HTTP_Get-Fehler von der HUEBridge gemeldet hast. Da hätte mir eigentlich auffallen müssen, dass die Kommunikation zwischen HUEBridge und dem deCONZ-Gateway nicht ganz in Ordnung ist.
Vermutlich hätte ein "Unlock Gateway" in der deCONZ-WebApp und neu starten von fhem bzw. dem HUEBridge-Modul den Knoten gelöst..

Ich habe übrigens heute das Plugin aktualisiert, sodass Änderungen durch die deCONZ-WebApp auch Notifications in fhem triggern. Die wurden bisher aus Effizienzgründen nicht ausgelöst.
Zum Updaten:
- git pull
- ./install.sh

Bevor du weitere Sensoren wie den HUE Motion Sensor anlernst, solltest du unbedingt deine Konfiguration in der deCONZ-WebApp sichern. Sonst bekommst du die Devices nicht mehr so ohne weiteres wieder entfernt.

Den HUE Motion Sensor habe ich mit der vorherigen deCONZ-Version mal ausprobiert. Die Idee war es durch das Mithören am Gateway eine vorläufige Unterstützung zu realisieren. Im Prinzip kann man dadurch so einiges machen...
Allerdings hat die deCONZ-Software das nicht sehr gut vertragen und ich war froh, dass ich eine Sicherung der Einstellungen hatte...

Wenn ich etwas Zeit finde, dann probiere ich das mit der aktuellen deCONZ-Version mal etwas ausführlicher.
Wäre super, wenn du deine Erfahrungen hier postest.

EDIT: Bei deiner Konfiguration, kannst du fhem etwas entlasten, indem du die Poll-Zyklen reduzierst, z.B. mit einem define raspBee HUEBridge IP 3600
(auf 60 Minuten).

Grüße,
ct

olindner

Hi ct, sehe ich das richtig, dass FHEM und deCONZ auf einem Raspberry Pi laufen muss? Auf rest_push.txt kann ich den Telnet Port angeben, aber nicht die FHEM IP ... mhh! Wenn es doch gehen sollte, würde ich es gern ausprobieren.

Danke und viele Grüße Olaf

ct

#17
Hallo Olaf,

ja das ist richtig. Momentan müssen deCONZ und FHEM auf dem gleichen Raspberry laufen. Macht alles etwas kompakter und flotter.
Dies ließe sich zwar ändern, aber Telnet übers Netz ist etwas... heikel, also unsicher... Telnet lokal ist zwar auch nicht so gut, aber akzeptabel...
Wenn großer Bedarf für so eine Konfiguration besteht, dann kann ich mal schauen was sich machen lässt.

Nur so aus Interesse.. Welchen Vorteil hätte es beides auf unterschiedlichen Systemen zu betreiben?

Grüße,
ct

olindner

Hallo ct, mein Aufsatz RaspBee funkt recht bescheiden  :'( kommt einfach nicht durch die Decke. FHEM am Router u alles im Keller, Licht ist im 1. Stock. FS20 u HMLAN kommen recht gut durch die Decke ... Also habe ich DeConz nach oben verlagert und schalte problemlos. Mach Dir bitte keine Arbeit, ich wollte es mal ausprobieren und die Last im FHEM etwas runterfahren. Aber zz funktioniert ja alles und mit der Latenz kann ich leben.

schönen Abend Dir uvg Olaf

Tom15

Hallo ct

nach einigen Tagen im Test habe ich folgende Erfahrungen:
- bei Neustart des Raspberrys wird oft die Verbindung zum Raspbee und deCONZ nicht richtig hergestellt und FHEM reagiert nicht auf Tastendruck.
- ist die Verbindung einmal erstellt funktioniert der Switch konstant.

Was meinst du mit unbedingt deine Konfiguration in der deCONZ-WebApp sichern?
Habe leider in den letzten paar Tagen wenig Zeit gefunden für etwaige Tests..

LG Tom

ct

Hallo Olaf,

hm.. bei dem Szenario würde das tatsächlich Sinn machen. Ich habe mal angefangen die Kommunikation zwischen deCONZ und FHEM ohne die rest_push.txt umzugestalten, aber es kann schon noch ne Weile dauern bis es stabil und nutzbar ist. Ich gebe Bescheid, wenn es soweit ist.

Danke für die Rückmeldungen Tom!
In der WebApp (also IP:80 oderIP:8080) kannst du unter "Menu/Settings/Show Advanced Settings/Save Configuration" deine Konfiguration als Datei sichern und diese später wieder mit Load Konfiguration einspielen.
Ich habe bei meinen Tests leider keine Möglichkeit gefunden, Geräte wie Bewegungsmelder wieder aus der Konfiguration zu entfernen außer mit der Konfiguration, wobei ich mir nicht 100% sicher bin ob das tatsächlich geklappt hat.

Grüße
ct

ct

#21
Hallo Olaf,

ich habe eine neue Version zum Testen eingecheckt, welche es erlaubt, dass deCONZ auf einem anderen RaspBerry läuft als FHEM. Hierfür solltest du in FHEM einen Telnetport bereitstellen, der sowohl ein Passwort gesetzt hat als auch SSL aktiviert hat. Es ginge zwar auch ohne, aber davon rate ich dringends ab. z.B.:

define telnetPort telnet 7074 global
attr telnetPort SSL 1
attr telnetPort password geheimesPasswort


Um zu testen, ob das Plugin damit umgehen kann, habe ich ein kleines Tool bereit gestellt. Auf dem Raspberry, z.B. im tmp-Verzeichnis:
cd /tmp
git clone https://hcm-lab.de/git/iot/fhem-socket-tools
cd fhem-socket-tools
./build.sh


Danach sollte ein tool mit dem Namen sockssl gebaut worden sein. Jetzt kannst du z.B. mit folgendem Kommando per ssl/pw/telnet ein Kommando an fhem übers Netzwerk absetzen (Parameter anpassen):
./sockssl IP-Addresse Port Passwort "setreading global deconztest 1"

Wenn du danach in FHEM in global das Reading deconztest wiederfindest, dann funktioniert auch das Pushen durch das Plugin zu FHEM, da es den gleichen SSL-Code verwendet. Wenn das nicht funktioniert, dann werden wir wohl den SSL-Aufbauprozess genauer anschauen müssen...

Zum Testen der neuen Version.

1. Auf dem RaspBerry auf dem FHEM läuft:
git clone -b v0.2 --single-branch https://hcm-lab.de/git/project/deconz-push.git
cd deconz-push
./install-fhem.sh


Damit ladest du dir den Branch v0.2 herunter und installierst das FHEM-Hilfsskript.

Danach musst du in der FHEM-Kommandobox das Hilfsskript neuladen:
reload 99_myDeconz1.pm

2. Auf dem RaspBerry auf dem deCONZ läuft:
git clone -b v0.2 --single-branch https://hcm-lab.de/git/project/deconz-push.git
cd deconz-push
./install.sh


Damit ladest du dir den Branch v0.2 herunter und installierst das Plugin.

Danach musst du die Konfigurationsdatei anpassen. Der Pfad dazu:
/usr/share/deCONZ/rest_push.conf
Achtung: Der Dateiname hat sich im vgl. zur vorherigen Version geändert um Konflikte (bei Rückkehr zur vorherigen Version) zu vermeiden.

In der Datei musst du IP/Port/Passwort anpassen, z.B. folgende Änderungen:
# FHEM telnet port
fport 7074
fip 127.0.0.1
ssl
fpass geheimesPasswort


Jetzt noch deCONZ neustarten und danach sollten Änderungen übers Netzwerk gepushed werden. Falls du es ausprobieren solltest, dann wäre Feedback willkommen :)

Viele Grüße,
ct

P.S.:
Du kannst das Plugin wie üblich deinstallieren, falls etwas nicht klappen sollte:
cd deconz-push
./uninstall.sh


olindner

Hallo CT, danke für Deine Arbeit :) ich setze mich mal ran ... Bitte um etwas Geduld, bin nicht so fit, aber er hat sich stets "bemüht"  ;D

sockssl installiert, libssl-dev libssl-dev telnet noch nach installiert.

anlegen: define telnetPortDeConz telnet 7074 global
Internals:
   CONNECTS   9
   DEF        7074 global
   FD         52
   NAME       telnetPortDeConz
   NR         608
   NTFY_ORDER 50-telnetPortDeConz
   PORT       7074
   SSL        1
   STATE      Initialized
   TYPE       telnet
Attributes:
   SSL        1


jetzt der erste Hürde:
pi@raspbee-gw:/tmp/fhem-socket-tools $ ./sockssl 192.168.178.xx 7074 test "setreading global deconztest 1"
Error [ -1 ] in [ BIO_do_connect ]
1996387536:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:757:


Habe folgendes ausprobiert:openssl s_client -connect 192.168.178.xx 7074
ServerCert wird abgefragt und dann das Password abgefragt ...    Start Time: 1488365730
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
▒▒Password: test
▒▒

fhem>
fhem> quit
Bye...
closed


... jetzt komme ich nicht weiter ...

viele Grüße Olaf

hängt wohl an ssl3 ...pi@raspbee-gw:/tmp/fhem-socket-tools $ openssl s_client -connect 192.168.178.xx:7074 -ssl3
CONNECTED(00000003)
1996081248:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1315:SSL alert number 40
1996081248:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1488366243
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---




ct

Hallo Olaf,

hab gar nicht damit gerechnet, dass du es so schnell ausprobierst :-)
Keine Ursache und Danke fürs Ausprobieren!

Da war ich wohl etwas zu strikt mit den SSL-Versionen ... Ich habe beide Repos aktualisiert und nun sollte sslv2 und sslv3 auch funktionieren.
Einfach in den Verzeichnissen nochmal ein:
git pull

Für sockssl dann die Schritte ab "cd fhem-socket-tools" (also ./build.sh ...) weiterführen.
Für den RaspBerry mit deCONZ dann die Schritte ab "cd deconz-push" weiterführen.

Viele Grüße,
ct

olindner

#24
Hallo CT, wenn ich nichts falsch gemacht habe (git pull war erfolgreich und neu gebaut, reload 99_myDeconz1.pm), dann habe ich immer noch den ssl Fehler ... vg Olaf

mit openssl s_client -connect 192.168.178.xx:7074 funktioniert es,

mit openssl s_client -connect 192.168.178.xx:7074 -sslv3 nicht.

CONNECTED(00000003)
1996163168:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1315:SSL alert number 40
1996163168:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1488370022
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---


./sockssl 192.168.178.10 7074 test "setreading dummy 1"
Error [ -1 ] in [ BIO_do_connect ]
1995498704:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:757:


ct

Hallo Olaf,

okay. Anscheinend kommt der Vorgang gar nicht erst zum Handshake. Ich vermute mal, dass die erlaubte cipherlist nicht für tls bei deinem Zertifikat ausreicht. Diese habe ich jetzt mal etwas liberalisiert..

Kannst du nochmal ein "git pull" auf das sockssl-repo machen, dann ein "./build.sh" und danach das Kommando "./sockssl IP ..." absetzen?

Wenn es nicht klappt, dann hänge noch eine 1 an die Kommandozeile also "./sockssl IP ... 1". Damit werden alle Meldungen ausgegeben.
Wenn es klappt, dann aktualisiere ich auch das Plugin.

Grüße,
ct

olindner

Hallo CT, jetzt hat es funktioniert  :) konnte Dummy-Device den state setzen, dennoch noch ein paar Fehler in der Ausgabe ... vg Olaf

./sockssl 192.168.178.xx 7074 test "set test 1" 1
Error [ 0 ] in [ SSL_CTX_load_verify_locations ]
1995900112:error:02001002:system library:fopen:No such file or directory:bss_file.c:175:fopen('certs.pem','r')
1995900112:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:178:
1995900112:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:253:
BIO_new_fp
BIO_do_connect
CertVerifyier: Issuer [ /C=DE/ST=havelland... ]
CertVerifyier: Subject [ /C=DE/ST=havelland... ]
CertVerifyier: Issuer [ /C=DE/ST=havelland... ]
CertVerifyier: Subject [ /C=DE/ST=havelland... ]
BIO_do_handshake
Error [ 0 ] in [ SSL_get_verify_result ]
BIO_read
▒▒Password:
read: [ 1 / 13 ] [ ▒▒Password:  ]
[ set test 1 ]

ct

Hallo Olaf,

sehr gut  :)
Habe das Plugin-Repo jetzt aktualisiert. Du kannst also nach einem "git pull" (auf dem deCONZ-RaspBerry) mit dem "./install.sh" weitermachen.

Die Fehlermeldungen können getrost ignoriert werden. Das Tool wird noch erweitert, damit man mit dem öffentlichen Root-Zertifikat des Server-Zertifikats (in einer Datei certs.pem im gleichen Verzeichnis) eine valide Zertifizierungskette erzwingen kann.
Wenn diese Datei fehlt, dann geht das Tool davon aus, dass letzteres nicht erforderlich ist. Zu Debug-Zwecken können diese Meldungen aber sehr hilfreich sein...

Grüße,
ct



olindner

#28
Hallo CT, habe jetzt auch auf dem deCONZ-RaspBerry deCONZ-Push installiert, Neustart deCONZ-RaspBerry ... gleich mal probiert, sehe leider noch keine Veränderungen, es dauert immer noch bis sich der Status ändert ... Wo kann ich loggen, Wo kann ich was sehen?

nach einem reload 99_myDeconz1.pm sehe ich dies hier im FHEM-Log
2017.03.01 17:31:32 1: deCONZ_get_config: Found 1 bridges.
2017.03.01 17:31:32 1: deCONZ_get_config: Bridge NR 355
2017.03.01 17:31:32 1: deCONZ_get_config: Added 6 devices.


Nehme mich bitte weiter an die Hand ;) Danke uvg Olaf

PS die conf sieht so aus: (Push client socket port auf 7073 ist das richtig?)
# Disable plugin
#disableplugin

# FHEM telnet port
fport 7074

# FHEM telnet IP address
fip 192.168.178.xx

# FHEM telnet enable ssl (mandatory for an IP other than localhost)
ssl

# FHEM telnet password (mandatory for an IP other than localhost)
fpass test

# Push client socket port
pport 7073

# Disable fhem tunnel
#disablefhem

# Disable push listener socket
#disablepushlistener

nonodeupdate


ct

#29
Hallo Olaf,

kein Problem. Nach dem ersten Verbinden von dem Plugin mit FHEM kann es ein paar Sekunden dauern, da das Plugin die Bridge-ID zuerst abfragt. Der cached diese aber in der Datei /usr/share/deCONZ/rest_bridge.conf damit diese beim nächsten Start genutzt werden kann.
Wenn du auf dem deCONZ-Raspberry folgendes ausführst:

cat /usr/share/deCONZ/rest_bridge.conf

sollte deine Bridge-ID 355 enthalten sein.

Um Log-Meldungen in FHEM zu sehen kannst du das loglevel anpassen, wenn du {deCONZ_set_verbose(1)} in die FHEM-Kommandobox eingibst.
{deCONZ_set_verbose(4)} "normalisiert" den loglevel wieder.

Siehst du pushupd1-Meldungen?

Die "pport"-Einstellung ist für fhem-push nicht wichtig. Du kannst aber an diesem Port sehen, ob überhaupt push-events erzeugt werden. Auf einem der RaspBerrys:

telnet IP 7073

SSL wird auf diesem Port noch aufgerüstet.

Grüße,
ct

olindner

#30
Hallo CT, ich muss die Push-Bridge wohl noch aktivieren ... mhhh
Was muss ich noch einstellen? In der rest_bridge.conf steht leider eine NULL  :'(

pi@raspbee-gw:/var/log $ cat /usr/share/deCONZ/rest_bridge.conf
0


... habe ./build.sh vergessen :(  und noch was installieren! sudo apt-get install qt4-qmake libqt4-dev
melde mich wenn später ...

ct

Hallo Olaf,

hm... build.sh bitte nicht ausführen. Der Quellcode ist nicht aktuell.
Falls du es schon gemacht hast, dann bitte nochmal das Repo neu clonen.

Nur um ganz sicher zu gehen. Hast du noch Readings zum Konfigurieren in dem deCONZ-FHEM-device?
Aso die fhemPort, fhemtunnel, etc..?

Die solltest du löschen, da diese die rest_push.conf sozusagen überschreiben. Somit würde das Plugin angewießen nach dem Connect den Telnet auf einem anderen Port neuzustarten.

Grüße,
ct

olindner

#32
dachte ich hatte es übersehen (build ist leider gelaufen) ... so neu git clone geholt, readings sind keine mehr da

nach install.sh kommt nur eine Warnung!
pi@raspbee-gw:~/deconz-push $ ./install.sh
Warning: $FHEM_HOME/FHEM not available!


nach restart immer noch eine Null in rest_bridge.conf ...

Was könnte ich noch tun? vg Olaf

Internals:
   .triggerUsed 1
   CFGFN      fhem-HUEDevice.cfg
   DEF        192.168.178.69
   Host       192.168.178.69
   INTERVAL   60
   NAME       lightlink
   NOTIFYDEV  global
   NR         355
   NTFY_ORDER 50-lightlink
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.0.0
   mac        74:da:38:27:ea:cd
   manufacturer dresden elektronik
   modelName  Philips hue bridge 2012
   modelid
   name       RaspBee-GW
   noshutdown 1
   swversion  20435
   updatestate 0
   zigbeechannel 15
   Readings:
     2017-02-18 18:51:00   lastError       resource, /lights/3, not available
     2017-03-01 20:41:41   state           connected
   Helper:
     apiversion 65536
     count      0
     last_config_timestamp 1488397301
     updatestate 0
Attributes:
   event-on-change-reading .*
   httpUtils  1
   key        bf4b06e277514e50da1292d631580fa8
   pollDevices 2
   room       HUEDevice
   verbose    1

ct

Hallo Olaf,

das kann ich mir leider erst später ansehen, aber du könntest die ID direkt in die Datei eintragen. Die /usr/share/deCONZ/rest_bridge.conf sollte aus zwei Zeilen bestehen und so aussehen:

355


Die zweite Zeile leer lassen. Kommt per Telnet auf port 7073 eine Ausgabe?

Grüße,
ct

olindner

Hallo CT, kein Problem, es läuft ja alles noch  :)

hier scheint noch was zu klemmen:
pi@raspbee-gw:~/deconz-push $ telnet 192.168.178.69 7073
Trying 192.168.178.69...
telnet: Unable to connect to remote host: Connection refused


der port wird gar nicht aufgemacht ...

vg Olaf

ct

Hallo Olaf,

sehe grad, du meintest 0 :-)
Bei NULL wäre etwas anderes schiefgelaufen und wäre kritischer ...
Bei 0 scheint keine Verbindung zu FHEM aufgebaut werden zu können.

Dann führe auf dem deCONZ-RPi mal ein ./install.sh 1 aus. Damit wird die Debug-Version installiert. Nach dem Starten werden 2 Logdateien erzeugt:
/tmp/raspBeeBridge.log
/tmp/beeBridge.log

Lass mir bitte die beide zukommen und ich schau mal wo es genau stockt. Am besten per PM oder Dropbox, etc. schicken.

Grüße,
ct

ct

#36
Upss... :D

Hallo Olaf,

mir ist grad aufgefallen, dass ich noch "Testcode" im Installer habe. Öffne doch die install.sh und kommentiere die Zeile 43 aus.

Um ganz sicher zu gehen, dass du den richtigen Branch aktualisierst solltest du folgendes ausführen:

git pull origin v0.2

Danach sollte das Plugin mit ./install.sh tatsächlich installiert werden.

Grüße,
ct

olindner

Moin CT,

jetzt hat der Installer auch was installiert  :) jetzt kommt auch die Ausschrift "Please restart deCONZ process now."
pi@raspbee-gw:~/deconz-push $ ./install.sh
Warning: $FHEM_HOME/FHEM not available!
Please restart deCONZ process now.


raspbee-gw neu gestartet (Ich sehe im Code, deConz als Service /etc/init.d/deConz zu integrieren, wird/ist dies schon umgesetzt? zz habe ich keinen Plan, wie ich deConz richtig neu starte!)
pi@raspbee-gw:~/deconz-push $ telnet raspbee-gw 7073
Trying 127.0.1.1...
Connected to raspbee-gw.
Escape character is '^]'.
355^l^3^level^255
355^l^3^bri^255
355^l^3^pct^100
355^l^3^level^255^bri^255^pct^100
355^l^3^manufacturer^OSRAM^modelid^Plug 01^swversion^V1.04.12^type^On/Off plug-in unit^manufacturerCode^48042^clusterId^25^groupCapacity^7^on^1^groupCount^1^sceneCapacity^16
355^l^3^id^3^uniqueid^84:18:26:00:00:09:84:2D-03^available^1
355^l^3^state^on^onoff^1
355^l^3^level^255^bri^255^pct^100


Sehe noch keine neuen Readings im Device, Neustart FHEM? Reload 99_myDeconz1.pm hatte ich gemacht!

Kann es aber erst heute Abend ausprobieren, hänge noch im Office fest  ;D

Danke uvg Olaf

ct

Hallo Olaf,

das sieht doch schon sehr gut aus. Gib mal in der FHEM-Kommandobox folgendes ein und schau ob "pushupd1"-Einträge in der fhem-log mit deCONZ_... erscheinen.

{deCONZ_set_verbose(1)}

Das Skript 99_myDeconz1.pm baut einen Cache mit Referenzen zu den HUEDevices zum Beschleunigen der Zugriffe auf. Allerdings wird der ungültig, wenn du ein "rereadcfg" in die Kommandobox eingibst. Sollte bald gefixt sein.

Bis dahin kannst du den Cache immer wieder neu aktualisieren oder neu aufbauen mit:

{deCONZ_get_config(0)}

Dies wird auch jedesmal automatisch aufgerufen, wenn sich deCONZ mit FHEM verbindet.

Zum init-skript für deCONZ kann ich heute Abend evtl. noch nen Tipp geben.

Grüße,
ct

olindner

#39
Hallo CT, hier mal der log ...

2017.03.02 14:34:04 1: pushupd1: Bridge 355 not found!
2017.03.02 14:34:04 1: deCONZ_get_config: Bridge found with NR 355
2017.03.02 14:34:04 1: deCONZ_get_config: Found 1 bridges.
2017.03.02 14:34:04 1: deCONZ_get_config: Bridge NR 355
2017.03.02 14:34:04 1: deCONZ_get_config: Creating Bridge for NR 355
2017.03.02 14:34:04 1: deCONZ_get_config: Creating lights
2017.03.02 14:34:04 1: deCONZ_get_config: Creating sensors
2017.03.02 14:34:04 1: deCONZ_get_config: Creating groups
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-3 ( HUEDevice3 ) -> 3 -> Device -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-G1 ( HUEGroup1 ) -> G1 -> Group 1 -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-1 ( HUEDevice1 ) -> 1 -> Device -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-G0 ( HUEGroup0 ) -> G0 -> Group 0 -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-2 ( HUEDevice2 ) -> 2 -> Device -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Device lightlink-G2 ( HUEGroup2 ) -> G2 -> Group 2 -> Added.
2017.03.02 14:34:04 1: deCONZ_get_config: Added 6 devices.
2017.03.02 14:34:04 1: pushupd1: l:3 bri 255
2017.03.02 14:34:04 1: pushupd1: l:3 pct 100
2017.03.02 14:34:04 1: pushupd1: l:3 state on
2017.03.02 14:34:04 1: pushupd1: l:3 onoff 1
2017.03.02 14:34:04 1: pushupd1: l:3 level 255
2017.03.02 14:34:04 1: pushupd1: l:3 bri 255
2017.03.02 14:34:04 1: pushupd1: l:3 pct 100


Bekomme keine Readings ans Device :( ...

ct

Hallo Olaf,
die Logs sehen eigentlich gut aus. Die pushupd1-Meldungen bedeuten, dass die Verbindung von deCONZ zu FHEM funktioniert und zumindest 4 Readings ins Device lightlink-3 gepushed wurden. Sind keine weiteren Readings in den Logs zu sehen?

Wenn die Readings sich in FHEM nicht ändern, dann könnte der Cache ungültig geworden sein, was allerdings ungewöhnlich wäre. Möglicherweise ist da noch ein Bug drin.

Falls keine weiteren logs zu sehen sind, könntest du versuchen die debug-logs mit "./install.sh 1" zu erzeugen?

Grüße,
ct

ct

Hallo Olaf,

Danke dir für die Logs. Die Logs sehen eigentlich gut aus. Nur um sicher zu gehen, weil du die HUEBridge-Device angehängt hast.
Meinst du die Readings im Device der HUEBridge oder denen der HUEDevice?

Die Readings in dein einzelnen HUEDevices sollten sich ändern, also z.B. HUEDevice3 ( https://192.168.xxx.xxx:8083/fhem?detail=HUEDevice3 )
bzw. wie viele Readings (ungefähr) sind dort zu finden?

Grüße,
ct

ct

Version wurde auf v0.2 aktualisiert.

NEU:
- Telnet Passwort
- Telnet Passwort / SSL
- deCONZ kann auf einem anderen RaspBerry als FHEM laufen

Damit push nach einem rereadcfg funktioniert, muss ein push-Device erzeugt werden:

define myDeconz myDeconz1

Danke an Olaf fürs Testen!

Grüße,
ct

mahowi

#43
Hallo ct,

bei der Installation der aktuellen Version gibt es noch ein Problem:
Installing plugin ...
cp: der Aufruf von stat für ,,rest_push.conf" ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Failed to install rest_push.conf
Failed to install plugin!


Heißt die Konfigurationsdatei jetzt rest_push.conf? Dann muß die Datei rest_push.txt noch umbenannt werden.



Edit:
Es fehlt noch eine Datei:
Installed rest_push.conf. You should update the configuration through this file.
cp: der Aufruf von stat für ,,rest_bridge.conf" ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Failed to install rest_bridge.conf


Ich habe die beiden Dateien mal aus dem v0.2 Branch genommen, dann läuft die Installation auch durch.



Edit2:
Noch was, das Modul 99_myDeconz1.pm wird mit uid.gid root.root installiert, d.h. der FHEM-User kann die Datei nicht laden.

Was sollte denn nach dem define myDeconz myDeconz1 passieren? Bei mir kommt die Meldung deCONZ_value:NR:166; Es wird aber kein Device angelegt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

ct

Hallo mahowi,

Danke dir für den Hinweis. Ich habe die Konfigurationsdateien und den Installer korrigiert.

Nach dem define müsste ein Device mit dem Namen myDeconz angelegt worden sein. Dieses dient lediglich dazu mitzubekommen, wenn fhem die Konfiguration neu ladet. D.h. du findest dieses auch nicht, wenn du es direkt mit https://ip:8083/fhem?detail=myDeconz abrufst?

Grüße,
ct

olindner

Hallo CT, kann das beschriebene Verhalten von mahowi bestätigen ...


define myDeconz myDeconz1
deCONZ_value:NR:355;

list myDeconz
No device named myDeconz found


Grüße Olaf

ct

Hallo ihr beide,

nur um ganz sicher zu gehen. Habt ihr auf dem RaspBerry auf dem FHEM läuft auch ein "git clone" bzw. "git pull" und dann ein ./install-fhem.sh ausgeführt?

Grüße,
ct

mahowi

Ein "list myDeconz" ergibt:
No device named myDeconz found

Aufrufen von https://ip:8083/fhem?detail=myDeconz ergibt nur eine leere Seite. Das Device wurde also scheinbar nicht angelegt. Auch shutdown restart bewirkt keine Änderung.

Ja, ich habe mit "git pull" die Sourcen aktualisiert. Und natürlich install.sh ausgeführt, das ja installfhem.sh mit ausführt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

olindner

Hallo CT,

um sicher zu gehen. Nochmals ein "git pull" gemacht! Ergebnis kein Device myDeconz!

ct

#49
Hallo ihr beide,

vielen Dank für die Hinweise. Ich habe die 99_myDeconz1.pm aktualisiert und nun sollte ein "define myDeconz myDeconz1" ein leeres Device erzeugen. Möglicherweise wird es in Zukunft für mehr genutzt, aber momentan dient es lediglich dazu Zustandsänderungen von FHEM mitzubekommen.

Aktualisierung im git-repo:
git pull
./install-fhem.sh


Aktualisierung durch die fhem-commandbox:
reload 99_myDeconz1.pm
define myDeconz myDeconz1


Grüße,
ct

mahowi

Danke, jetzt lässt sich das Device anlegen.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

derchrome

#51
Hallo zusammen,
wir habe mir die GardenPoles von Osram samt Gateway angeschafft. Da ich plattformübergeifende Systeme bevorzuge (ich würde auch gerne das neue System von Ikea ausprobieren), überlege ich mir das ConBee oder Raspbee-Modul anzuschaffen. Besteht dazwischen in Bezug auf die Push-API ein Unterschied? Ich würde eher zu dem USB-Modul tendieren, da ich die Pin noch für einen 433Mhz Sender/Empfänger nutze.

Kann ich die API so verwenden, dass ich bis auf die FW-Updates die Gateway von Osram nicht mehr benötige?

Und gibt es irgendwo ein Tutorial wie ich den Stick unter FHEM einbinde und verwende (und dann mit den Lampen koppel)? Ich habe die Sufu zwar benutzt aber so richtig was gefunden habe ich nicht...

j_sve

Hi,

I hope it is ok that I'm writing in english. I skimmed this thread, and I think my German is good enough for that. Not for writing though :)

I got the Push-API setup, and it seems to be somewhat working. Some sample output from my console is:

-1^s^3^reachable^1
-1^l^3^sceneCapacity^64
-1^l^3^level^5
-1^l^3^bri^5
-1^l^3^pct^0
-1^l^3^xy^0.461680,0.000000
-1^l^3^colorX^30138
-1^l^3^xy^0.461680,0.412215
-1^l^3^colorY^26909
-1^l^3^colorTemperature^250
-1^l^3^colorLoopSpeed^25


I read something that made me believe that this should also work with remotes. I have my remote connected (I think) to the deCONZ. It shows in the GUI and has that blue blinking dot on it when I push buttons. However, as you can see in the output above, there is nothing there about button-presses.

ct

#53
Hi j_sve,

english is okay. Whatever helps understand the problem is appropriate.

What remote do you have connected? Is it one of the Philips Hue devices?

Cheers,
ct

derchrome

Als was lege ich eigentlich die Conbee an im FHEM?

justme1968

die deCONZ software wird als HUEBridge eingebunden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ct

#56
Hallo derchrome,

habe deinen Post erst jetzt realisiert bzw. ganz übersehen. Wie justme bereits geschrieben hat, läuft alles über die HUEBridge und HUEDevices.

Im Prinzip ist es so, dass du entweder den RaspBee oder den ConBee (USB) verwenden kannst und als Software "deCONZ" verwendest. ConBee läuft (bei mir) sehr gut und zuverlässig und kann bei Bedarf sehr unkompliziert auch für andere Plattformen verwendet werden.
Der RaspBee ist beim RaspBerry Pi 3 nicht ganz so einfach wegen Konflikten mit UART und BT/WiFi etc.. Man kriegt es bestimmt hin mit genügend Modifikationen, aber mit ConBee klappt es auch mit einfachem "anstecken".

Alle Geräte (Steckdosen, Lichter, Schalter, etc.) werden mit deCONZ (statt mit der Osram-Bridge) gepaired und über deCONZ gesteuert.
Du solltest vorher sicherstellen, dass deine Geräte auch von deCONZ unterstützt werden: https://www.dresden-elektronik.de/funktechnik/solutions/wireless-light-control/compatibility/?L=1

deCONZ (http://www.dresden-elektronik.de/rpi/deconz/deconz-latest.deb) ist dann praktisch die "Bridge" und bietet eine Weboberfläche zur Konfiguration und Steuerung.
Um deCONZ beim booten auf einem RaspBerry zu starten habe ich das init.d script von homesbridge (https://wiki.fhem.de/wiki/Homebridge_einrichten#Homebridge_automatisch_starten) angepasst und deCONZ mit xvfb gestartet (https://www.amazon.de/review/R2RR4NDS0HG1C5).

deCONZ bietet auch eine (REST)-Schnittstelle an, die als HUEBridge an FHEM angebunden werden kann.
Standardmäßig wird die REST-API (und auch die Weboberfläche) auf Port 8080 angeboten, aber das kann man beim Starten von deCONZ auch auf 80 legen. Beim Anlegen der HUEBridge muss man das berücksichtigen und ggf. den Port 8080 mitangeben.

Ach ja: Wichtig ist, dass man vor dem Anlegen der HUEBridge in der Weboberfläche von deCONZ den Zugriff freischaltet: Menu/Settings/Unlock Gateway

Das ganze läuft auch ohne die Push-API. Die Push-API ist lediglich eine kleine Erweiterung für deCONZ um Zustandsänderungen der Geräte instant in FHEM verfügbar zu machen. Voraussetzung hierfür ist, dass deCONZ auf einem RaspBerry oder einer Linux-Plattform läuft. Andere Plattformen wurden bisher nicht berücksichtigt.

Die OSRAM-Bridge wird dann nicht mehr benötigt.

Grüße,
ct


GhostInTheBottle

#57
Jetzt bin ich aber wirklich gespannt, denn ich war kurz davor, das RaspBee in die Ecke zu haun bzw. ganz weit weg zu legen. das Einbinden dieses Teils hat mein FHEM bisher immer fast vollständig zum Erliegen gebracht. Also möglicherweise Port 8080 mit angeben und in deConz unlock Gateway nicht vergessen? Das war's? Oder akzetiert das aktuelle HUEDevice von Fhem dasRaspBee GW nicht mehr (richtig)? Eine Stunde gebe ich dem RaspBee noch und ich dachte, ich habe schon alles probiert.

Jetzt komme ich langsam in's Grübeln. Gerade habe ich mir von https://github.com/mhop/fhem-mirror/tree/9efad3599d9d9e2484b38e41abeda1ab605e413c Branch Master 30_HUEBridge.pm und auch gleich noch das HUEDevice.PM gezogen und die über die 'Originale' in meinem FHEM Verzeichnis gebügelt und welch Wunder nach dem manuellen autocreate sind die Lampen von deConz plötzlich da.
Zumindest An- und Ausschalten und Dimmen (leider nur auf der Befehlszeile) ist jetzt möglich. Ich gehe mal davon aus, dass ich im Trunk Bereich gelandet bin und im offiziellen Update Pfad das RaspBee Teil falsch eingebunden wird. Ich stehe gern für Tests zur Verfügung, weil ich auf mit meinen Lampen auf die Lösung von dresden elektronik angewiesen bin.

ct

Hallo GhostInTheBottle,

also eigentlich funktioniert HUEDevice.pm und HUEBridge.pm sehr gut mit deCONZ. Alle meine HUE-Lichter, Steckdosen, Tasten, etc. hängen an deCONZ. Lediglich für den rgb-Befehl habe ich nen kleinen Patch, wobei ich nicht weiß, ob das überhaupt noch notwendig ist.

Verstehe ich das richtig, dass mit der offiziellen FHEM-Installation die Lampen von deCONZ nicht in FHEM erscheinen bzw. nicht funktionieren?

Grüße,
ct

GhostInTheBottle

#59
@ct
Das ist richtig. FHEM 5.8 (tägliches manuelles Update) läuft auf einem Banana Pro. Die Erstinstallation war 5.7. Ohne das Überschreiben von HUEBridge und HUEDevice habe ich bei set autocreate immer nur  ein funktionsloses 'Lightset 0' . Erst nach dem Überschreiben wurden auch die Lampen erkannt (erneutes autocreate). Ich habe aber auch kein Problem mit einer zusätzlichen aktuellen FHEM Installation, denn ich habe noch ein Raspi3 und ein Orange Pi Plus2 herumliegen. Ich bin selbst in der IT tätig und da ist mir schon klar, dass saubere Ausgangsbedingungen so manches Mysterium gegenstandslos machen. Von dem produktiven System lasse ich erst mal die Finger, damit nicht 9 Wellensittiche und 4 Nymphen in der Nacht ungewollte Lichtspiele bekommen. Das läuft über Milight und deshalb zum Glück völlig getrennt von der Phillips Problematik.

Edit: Neuinstallation inzwischen durchgeführt. Das RaspBee rennt bestens und läßt sich problemlos einbinden und die Lampen werden übernommen, auch die welche die originale HUE Bridge nicht beherrscht (vermutlich weil der Anlernvorgang ausschalt des ursprünglichen ZigBee Standards liegt).

Einen Dimmer, so wie das bei Milight funktioniert, bekomme ich bei der Einbindung von deConz allerdings nicht, dafür aber wirkungslose (logisch) RGB Regler. Die dimup und dimdown Befehle machen aber das was sie sollen.  Das funktioniert allerdings auch bei der Original HUE-Bridge nicht, also auch da kein Slider zum Dimmen, jedenfalls nicht mit der Osram Lampe. Kann ja sein, dass es mit einer echten Hue Birne besser auto-createt wird. Ich nehme aber an, bei der Osram Birne kann ich noch einen Dimmer händisch in FHEM nachbasteln?!

Tom15

Hallo ct,

mit der neuen beta Version von deCONZ (2.04.40) ist es nun möglich Sensoren wie zb den Hue Motion Sensor in FHEM einzubinden.
Meines Wissens geht das aber nur durch pollen. Für einen Bewegungsmelder wäre es aber sinnvoll wenn bei einer erkannten Bewegung eine push Nachricht erfolgt.
Ist dies mit der Push-API möglich?

LG Tom


ct

Hallo Tom,

das sind ja tolle Neuigkeiten. Dann kann ich meine HUE-Bewegungsmelder endlich reaktivieren :-)

Wie ich in den Release-Notes gelesen habe, sollte es kein Problem sein, wenn es nicht eh so schon funktioniert. Im Prinzip sollten alle Änderungen eines ZigBee-Gerätes sich sofort in den Readings in FHEM wiederspiegeln. Das Problem bei Sensoren war eigentlich, dass die Rest-API diese nicht (richtig) unterstützt hat.

Evtl. muss das Plugin doch neu gebaut werden, da deCONZ auf QT5 umgestiegen ist. Und theoretisch bietet deCONZ von Haus aus schon eine Push-API die WebSockets verwendet.
Das müsste sich dann justme genauer anschauen.
Wenn FHEM die WebSocket-API (stabil) unterstützt, dann würde ich eh einen Umstieg darauf vorschlagen.

Hast du die Beta schon ausprobiert?
Ich bin da noch etwas vorsichtig...

Grüße,
ct

Tom15

Hallo ct,

ja den Bewegungsmelder inkl. Lichtsensor hab ich bereits in FHEM erfolgreich eingebaut (mit der beta 2.04.40 Version). Der Dimmer Switch funktioniert jetzt jedoch nicht mehr.
Das wäre natürlich die optimale Lösung wenn das FHEM Modul in Kombination mit deCONZ alle Funktionen unterstützen würde.

LG Tom

Tom15

Hallo ct

gibt es derzeit eine Möglichkeit beide Devices (Motion Sensor und Switch) sinnvoll mit FHEM zu verbinden?

Danke & LG
Tom

ct

Hallo Tom,

früher oder später schon. Ich bin leider noch nicht dazu gekommen die Beta-Version auszuprobieren. Beim Stöbern im Quellcode habe ich schon gesehen, dass die Sensor-Implementierung der REST-API umgestaltet wurde. Daher könnte das erst mal mit viel Testen verbunden sein.

Meine Idee ist es die Websocket-API wiederzuverwenden, was mit weniger Testen verbunden wäre. Die neue Websocket-API erleichtert vieles, da ich praktisch die ganzen Websocket-Events als Anker zum direkten Weiterleiten an FHEM nutzen kann. Sobald ich etwas Luft habe, schaue ich mir das genauer an. Kann allerdings etwas dauern, da es wieder etwas hektischer zugeht... Perfekt wäre es, wenn bis dahin aus der Beta ein Release geworden ist.
Bis dahin kann man die Bewegungsmelder leider noch nicht nutzen.

Viele Grüße,
ct

rs

Hallo

GIbt es hierzu etwas Neues, heisst, kann man nun den HUE Sensor in FHEM nutzen?

Ich konnte ihn bereits erfolgreich in der deCONZ (2.04.35) integrieren, er wird auch mit allen Attributen erkannt. Liefert aber ins FHEM keinen Status und keine Werte, ausser reachable = 1 und batterie = 100.

Leider bin ich noch zu sehr Anfänger hierin und komme im Moment nicht weiter.
Wäre froh um Feedback.

Gruss & Dank
Roland
rpi3+ & RaspBee | Phillips, Osram, IKEA, SIlvercrest Devices | FHEM 6.2 | Echo Show 15 | Yamaha YAS| LG TV | Ubuntu 22.04 - NextCloud 27 - OpemVPN - Wordpress - NAS - ...

ct

Hallo Roland,

bisher leider nicht. Seit dem letzten Post gab es nur Beta-Versionen von deCONZ. Der Issue-Tracker zeigt zwar keine gravierenden Probleme, aber vorerst möchte ich warten bis es ein stabiles Release gibt.

Ich möchte ungern mein (stabil) laufendes System für eine Beta "aufgeben" auf die Gefahr, dass es noch Probleme mit einer Beta gibt... Ich habe mittlerweile so viele Dim- und Tap-Switches mit deCONZ am laufen, dass ein Ausfall sehr unangenehm werden könnte.

Andererseits könnte es bis dahin auch eine FHEM-Integration geben, die die Websocket-API in den Betas nutzt.

Grüße,
  Chi-Tai

justme1968

eine test version der hue module für die websocket schnittstelle der deconz beta version gibt es in den nächsten tagen hier: https://forum.fhem.de/index.php/topic,80985.0.html.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ct

#68
Die HUE-Module mit Push-Unterstützung sind jetzt im neuen Thread verfügbar. Die Betas sind mit Vorsicht zu "genießen", aber auf Dauer empfehle ich den Umstieg. Die Implementierung hier wird nicht mehr weitergeführt.

Gruss,
  Chi-Tai