Autor Thema: deconz push api (offiziell)  (Gelesen 1698 mal)

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
deconz push api (offiziell)
« am: 12 Dezember 2017, 20:36:20 »
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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #1 am: 14 Dezember 2017, 22:02:29 »
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.
« Letzte Änderung: 29 Dezember 2017, 19:58:29 von justme1968 »
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #2 am: 15 Dezember 2017, 00:21:17 »
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
« Letzte Änderung: 20 Dezember 2017, 15:10:07 von ct »

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #3 am: 19 Dezember 2017, 22:22:49 »
gibt es schon irgendwelche erkenntnisse ?
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #4 am: 19 Dezember 2017, 22:42:53 »
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 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #5 am: 19 Dezember 2017, 23:01:32 »
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

 

Offline mahowi

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 909
Antw:deconz push api (offiziell)
« Antwort #6 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.

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

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #7 am: 20 Dezember 2017, 08:43:28 »
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.


Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #8 am: 20 Dezember 2017, 08:59:04 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #9 am: 20 Dezember 2017, 11:59:15 »
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?



Offline OBPASNRW

  • Newbie
  • Beiträge: 1
Antw:deconz push api (offiziell)
« Antwort #10 am: 20 Dezember 2017, 12:51:13 »
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

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #11 am: 20 Dezember 2017, 15:08:31 »
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.

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #12 am: 20 Dezember 2017, 18:27:22 »
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.

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #13 am: 20 Dezember 2017, 21:01:32 »
Ü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.serviceund 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
« Letzte Änderung: 20 Dezember 2017, 21:38:58 von ct »

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #14 am: 20 Dezember 2017, 22:59:55 »
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?

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #15 am: 20 Dezember 2017, 23:43:17 »
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
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #16 am: 21 Dezember 2017, 12:14:18 »
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.

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #17 am: 21 Dezember 2017, 15:24:17 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 53
Antw:deconz push api (offiziell)
« Antwort #18 am: 22 Dezember 2017, 19:58:21 »
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 deconzausgefü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 deconzreboote nund dann findet die gui das Modul

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #19 am: 22 Dezember 2017, 21:55:45 »
Hallo Teamdrachen,

Bisher den Autostart über

> sudo systemctl enable deconzausgeführt.
Webinterface und Rest Api liefen.
Mit diesem Kommando sorgst du dafür, dass deconz beim Booten als Dienst startet.

für was ist dann

sudo systemctl start deconz
Damit startest du den Dienst manuell.

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

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 53
Antw:deconz push api (offiziell)
« Antwort #20 am: 22 Dezember 2017, 22:38:38 »
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



Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #21 am: 22 Dezember 2017, 23:02:12 »
Irgendwie 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
« Letzte Änderung: 26 Dezember 2017, 17:59:46 von ct »

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 53
Antw:deconz push api (offiziell)
« Antwort #22 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
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #23 am: 23 Dezember 2017, 11:03:27 »
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
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #24 am: 23 Dezember 2017, 17:24:46 »
wenn keine einwände kommen werde ich die module demnächst mit diesem stand einchecken.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #25 am: 23 Dezember 2017, 20:22:27 »
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

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #26 am: 29 Dezember 2017, 19:58:49 »
ich habe die module mal so wie sie sind eingecheckt.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #27 am: 29 Dezember 2017, 20:13:46 »
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
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #28 am: 29 Dezember 2017, 20:58:25 »
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
« Letzte Änderung: 29 Dezember 2017, 21:08:31 von MadMax-FHEM »
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #29 am: 29 Dezember 2017, 21:51:16 »
Hallo Joachim,

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


Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #30 am: 29 Dezember 2017, 21:56:50 »
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
« Letzte Änderung: 29 Dezember 2017, 21:59:21 von MadMax-FHEM »
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #31 am: 29 Dezember 2017, 22:05:55 »
Hallo Joachim,

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

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.

Oder 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
« Letzte Änderung: 29 Dezember 2017, 22:07:32 von ct »

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #32 am: 29 Dezember 2017, 22:09:02 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #33 am: 29 Dezember 2017, 22:11:31 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #34 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
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline sash583

  • Newbie
  • Beiträge: 1
Antw:deconz push api (offiziell)
« Antwort #35 am: 01 Januar 2018, 14:28:52 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #36 am: 02 Januar 2018, 14:14:38 »
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
« Letzte Änderung: 02 Januar 2018, 14:59:41 von MadMax-FHEM »
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 53
Antw:deconz push api (offiziell)
« Antwort #37 am: 03 Januar 2018, 09:41:24 »
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #38 am: 03 Januar 2018, 11:10:56 »
Stimmt, Porteintrag hat bei mir auch nicht geholfen...

Ansonsten: läuft...

Gruß, Joachim
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #39 am: 03 Januar 2018, 11:26:57 »
da sind noch zwei log nachrichten übrig geblieben. die sollten ab morgen weg sein.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 3088
  • NIVEAu ist keine Creme...
Antw:deconz push api (offiziell)
« Antwort #40 am: 03 Januar 2018, 11:29:25 »
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
« Letzte Änderung: 03 Januar 2018, 11:33:59 von MadMax-FHEM »
FHEM 5.8 Pi 3: HM-CFG-USB, 40x HM, ZWave-USB, 5x ZWave, EnOcean-PI, 3x EnOcean, DashButtons, CO2, ESP-Multisensor, FireTV, NanoLeaf
FHEM 5.8 PI 2: HM-CFG-USB, 23x HM, ZWave-USB, 3x ZWave, EnOcean-PI, 3x EnOcean, CO2, KODI, ha-bridge
FHEM 5.8 PI 3 (Test): HM-MOD-PCB, Alexa (alexa-fhem), Google Home

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17317
Antw:deconz push api (offiziell)
« Antwort #41 am: 03 Januar 2018, 11:57:38 »
den port mit anzugeben geht. ist aber nicht nötig wenn es eine standard installation auf port 80 ist.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline ct

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #42 am: 04 Januar 2018, 02:25:57 »
Hallo Sascha,

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

Online sinus61

  • Full Member
  • ***
  • Beiträge: 259
Antw:deconz push api (offiziell)
« Antwort #43 am: 11 Januar 2018, 20:31:38 »
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.
« Letzte Änderung: 12 Januar 2018, 17:29:48 von sinus61 »

Offline LordVoodoo

  • Jr. Member
  • **
  • Beiträge: 50
Antw:deconz push api (offiziell)
« Antwort #44 am: 15 Januar 2018, 08:40:12 »
Hallo zusammen,

kürzlich habe ich gesehen, dass es auch Stromzwischenstecker gibt, die eine Strommessung erlauben und ZigBee-Standard sind, aufgefallen sind mir:


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.

Offline Teamdrachen

  • Jr. Member
  • **
  • Beiträge: 53
Antw:deconz push api (offiziell)
« Antwort #45 am: 15 Januar 2018, 13:51:38 »
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.

 

decade-submarginal