[Aufruf] deConz Adapter Testen 1.1.2

[Wildbill]

Also bei mir betrifft es alle lastupdated Datenpunkte der Sensoren. Und das sind ein paar Tradfri-Bewegungsmelder, Tradfri-Remotes, ein Tradfri-Dimmer und ein Hue-Dimmer-Switch. Und bei allen sind es exakt zwei Stunden Versatz. Also wohl kein "China-Problem"...

Und ja, in Phoscon sehe ich die korrekte Uhrzeit, ebenso im iobroker, und sowohl auf Host, iobroker-VM und Phoscon-.Raspi mittels date. Und Phoscon oder iobroker laufen bei mir nicht in Docker, da das in dem Github-Issue anscheinend als mögliche Ursache ausgemacht wurde. Also irgendwo baut (vermutlich) die deconz-api 2 Stunden Versatz ein.

Gruss, Jürgen

Gruss, Jürgen

[Asgothian]

@Wildbill
Kannst du mal bitte per web-Browser die rest-api direkt abfragen ? Da steht dann drin welcher Zeitstempel von deconz übertragen wird.

A.
(Anleitung wie das geht kann ich erst heute Abend geben)

[Wildbill]

Klar, wenn ich es bis heute Abend nicht selbst rausgefunden habe, dann wäre eine kleine Anleitung nicht schlecht...

Gruss, Jürgen

[Jey Cee]

Man kann das Log level der Instanz auch auf Debug stellen dann findet man die Ausgaben der API auch im log

[Wildbill]

Das habe ich soeben gemacht und dann eine Hue-FB getestet:

deconz.0	2019-04-18 15:53:36.020	debug	Websocket message: {"e":"changed","id":"7","r":"sensors","state":{"buttonevent":4002,"lastupdated":"2019-04-18T13:53:36"},"t":"event","uniqueid":"00:17:88:01:04:af:d5:63-02-fc00"}

Da kommen also auch schon zwei Stunden Versatz an...

Gruss, Jürgen

[Wildbill]

Hier im Thread zum deconz-rest-plugin auf Github gab es nun die Aussage, dass die API die Zeiten grundsätzlich in UTC ausgibt, was die zwei Stunden erklären würde. Somit wundert es mich nun eher, wenn doch bei jemandem die MESZ als lastupdated steht?!
Kann da jemand sagen, dass bei ihm die lokale Sommerzeit ankommt?

Gruss, Jürgen

[siggi85]

Bei mir ist sie auch 2 Stunden versetzt. Version 1.0.2.

[mehrwiedu]

@Wildbill sagte in [Aufruf] deConz Adapter Testen 1.0.2:

Somit wundert es mich nun eher, wenn doch bei jemandem die MESZ als lastupdated steht?!
Kann da jemand sagen, dass bei ihm die lokale Sommerzeit ankommt?

Nein, nein. Die MESZ kommt auch bei mir nicht an. Ich habe sie nur ins Verhältnis gesetzt und als mögliche Erklärung in den Ring geworfen.

Es wäre jetzt mal wieder nur interessant, was in einem UTC +1 ohne Sommerzeit angezeigt würde. Kriegt man aber nicht raus, ausser man fliegt mal kurz nach Marokko. Wenn dort dann nur eine Stunde Versatz wäre, dann ignoriert die Phoscon Software schlicht die Zeitzonen und gleicht nur gegen UTC 0 ab, was dann aber bedeuten würde, dass in New York der Timestamp dann minus 4 Stunden wäre. Aber auch da komme ich jetzt nicht so fix hin und kenne keinen, der dort lebt und mal eben in ioBroker schauen kann.

[Kugelkopf]

@Wildbill Jo ist bei mir auch so. deconz adapter 0.4.0, api: 2.5.63

[Wildbill]

Hi,

ich hatte heute ein kleines Problemchen: Mir ist aufgefallen, dass die Datenpunkte im iobroker nicht mehr aktualisiert wurden, wenn ich direkt in Deconz/Phoscon etwas schalte oder z.B. ein Bewegungsmelder eine Lampe aktiviert. Von iobroker aus konnte ich alles problemlos ein- und ausschalten, nur andersrum kam nichts an. Auch die Zeiten der Datenpunkte änderten sich nicht.
Ein einfacher Neustart des Deconz-Adapters hat gereicht, damit iobroker auch wieder Änderungen von Deconz mitbekommt.
Ist das normal, dass irgendwann die Verbindung einseitig aussetzt? Dann könnte ich das ja mit einem automatischen Adapterneustart einmal die Woche oder so beheben.
Oder ist da nichts bekannt in der Richtung und ich gehe mal von einem einmaligen Effekt aus?

Gruss, Jürgen

[thewhobox]

@Wildbill hast du zu dem Zeitpunkt mal ins Log geschaut?
War vll der DeConz mal nicht erreichbar, dann könnte es nur ein verbindungsabbruch gewesen sein, was durch einen Neustart behoben wurde?

[Wildbill]

Im Log nichts Auffälliges und keinerlei Meldungen vom Deconz-Adapter. Verbindung war ja da, ich konnte ja von iobroker aus Lampen in Deconz steuern, da haben im iobroker dann auch logischerweise die Datenpunkte gepasst. Nur wenn ich direkt in Phoscon was geschaltet habe oder eben ein BWM eine Lampe eingeschaltet hat, bekam iobroker das nicht mit. Habe ich dann die Lampe im iobroker einmal auf true und wieder false geschaltet, ging sie auch wieder aus.

Und direkt nach Adapterneustart kamen die States wieder sauber im iobroker an, auch wenn eine Lampe kurz mal stromlos war und dann los leuchtete, wenn sie wieder eingesteckt wurde.

Komisch das ganze, irgendwie einseitiger Verbindungsabbruch...

Gruss, Jürgen

[Jey Cee]

Ich hab gerade die 1.1.0 auf github und npm veröffentlicht.

Das buttonpressed Objekt ist jetzt mit drin und neue Objekte für den Xiaomi Vibrationssensor gibt es auch.

[Wildbill]

Hi,

ich habe eben von Github upgedatet ( Link) über die Katze und beliebige URL. Als Version wird mir nun immer noch die 1.0.2 angezeigt und das mit den buttonpressed funktioniert nicht mehr, da bleibt 0 stehen. Upload und Adapterneustart habe ich gemacht. Kann es sein, dass da auf Github noch was fehlt oder nicht aktualisiert wurde?

Gruss, Jürgen

[Jey Cee]

OK Kommando zurück. Die 1.1.0 ist nicht auf github/npm, upload ist schief gegangen.

Muss ich später nochmal machen.

[Wildbill]

Alles klar, ansonsten läuft ja alles bis auf das mit dem buttonpressed.

Gruss, Jürgen

[Jey Cee]

so jetzt kann von gizhub getestet werden

[Wildbill]

So, das mit den buttonpressed ist nun mit enthalten. Allerdings irgendwie anders, als es im Fork von @Asgothian enthalten war?! Dort wurde im Punkt buttonpressed immer für die 800ms der gesendete Code der Fernbedienung angezeigt und ging danach wieder auf 0. Meine Skripte hatte ich so, dass sie einfach diesen Punkt direkt als trigger haben und den Wert verarbeiten. Mit der jetzigen Version von github geht buttonpressed für die Zeit des Tastendrucks auf true und danach wieder auf false. Was war der Grund, dass das nun so implementiert wurde? Ist nun kein Beinbruch, aber ich muss halt nun meine Skripte anpassen, auf buttonpressed triggern und danach den Wert bei buttonevent abfragen und verarbeiten. Aber, hatte es einen festen Grund, warum das geändert wurde?

Ansonsten fettes Danke, der Adapter an sich läuft, wie bisher auch, perfekt.

Gruss, Jürgen

[siggi85]

@Wildbill
Das wäre schlecht, denn einige Geräte geben ja viele verschiedene Statusse aus, bspw. der Xiaomi Würfel. Da wäre ein simples true/false etwas wenig. Oder gibt es dann für jeden möglichen Zustand eine true/false Objekt?!

EDIT: Trotzdem natürlich danke für die Arbeit und das Engagement und dass es weiter geht und immer besser wird.

[Wildbill]

Neee, da hast Du mich falsch verstanden. Mit dem Adapter aus dem Fork von @Asgothian kam der vierstellige Code einmal im Punkt buttonevent an und blieb da stehen. Und im Punkt buttenpressed wurde für 800ms auch der vierstellige Code geschrieben und danach eine 0. Somit konnte man direkt auf diesen Punkt triggern und diesen auch gleich auswerten, da ja für einen kurzen Zeitraum der Code drin stand. Auch bei Geräten mit vielen verschiedenen Statussen (eher Stati?). Nun habe ich meine Skripte eben anpassen müssen. Trigger auf buttonpressed, Abfrage ob dieser true, und dann eben buttonevent auswerten. Der Effekt ist der gleiche, halt eine Abfrage mehr. OK, es sieht schöner aus, da man nun unter buttonpressed mit true/false direkt eine ja/nein-Abfrage hat, ob gerade eine Taste gedrückt wurde, aber davon ab sehe ich gerade keinen weiteren Vorteil?!

Gruss, Jürgen