deconz push api (offiziell)

Begonnen von justme1968, 12 Dezember 2017, 20:36:20

Vorheriges Thema - Nächstes Thema

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

#1
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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

ct

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

justme1968

gibt es schon irgendwelche erkenntnisse ?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

MadMax-FHEM

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

ct

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



mahowi

deCONZ ist übrigens seit 2.04.97 aus der Beta raus und auch als 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.
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

LordVoodoo

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.


justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

LordVoodoo

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?



OBPASNRW

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

ct

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 auf der Dowloadseite. Aktuell ist 2.04.99.

Danke für den Hinweis! Hab gleich mal die Links im Post aktualisiert.

LordVoodoo

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.

ct

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

LordVoodoo

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?