Push-API (deCONZ)

[ct]

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]

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]

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

./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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

reload 99_myDeconz1.pm

2. Auf dem RaspBerry auf dem deCONZ läuft:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

/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:

Code Auswählen Erweitern

# 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:

Code Auswählen Erweitern

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" 

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

anlegen: define telnetPortDeConz telnet 7074 global

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

openssl s_client -connect 192.168.178.xx 7074
ServerCert wird abgefragt und dann das Password abgefragt ...

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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]

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.

Code Auswählen Erweitern

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)
---


Code Auswählen Erweitern

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

Code Auswählen Erweitern

./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]

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

Code Auswählen Erweitern

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?)

Code Auswählen Erweitern

# 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]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

telnet IP 7073

SSL wird auf diesem Port noch aufgerüstet.

Grüße,
ct