[Aufruf] deConz Adapter Testen 1.1.2

[mctom]

@Jey-Cee :

Ich habe heute das Update auf die Version 1.0.1 durchgeführt.
Leider ist es jetzt nicht mehr möglich Gruppen zu dimmen. Auch nach Änderungen in der Phoscon APP werden die korrekten Werte auch nicht in ioBroker angezeigt.

Sonst ist mir bisher noch nichts aufgefallen. Zu Thema oben habe ich auch ein Issue in Github eröffnet.

[Kugelkopf]

Hab heute Nacht auch geupdated und leider völlig verpeilt, dass sich die Benennung geändert hat. Das hat natürlich alle Skripte durcheinander gebracht. Auch das Logging für die mySQL Datenbank passt dann natürlich nicht.

Ich bin kein Fan von dieser Alias - Geschichte im SQL Adapter. Hat jemand eine Idee oder Skript welches die alten mySQL Datenpunkte umschreibt auf die neue Bezeichnung?! Oder zumindest einen Ansatz wie es gehen könnte?!

@Jey-Cee Leider konnte ich nicht mehr Downgraden auf die Version 0.4.0. NPM sagte mir, dass diese Version nicht zur Verfügung stände. Das ist schade, denn die Veränderungen mit der v. 1.0.1. sind ja nicht sehr gering. Lässt sich da noch etwas regeln?

Viele Grüße!

[Asgothian]

Hallo zusammen,

ich habe jetzt auch auf den neuen deconz adapter umgestellt. Dabei sind mir ein drei Dinge aufgefallen:

• wenn man per GitHub (Katze, nicht custom) installiert, bekommt man immer noch den 0.4.0 von jey-cee/iobroker.deconz.

• keine meiner im Phoscon angelegten Gruppen sind "sauber" benannt. Die meisten Gruppen heissen "unbenannt", mit ausnahme der einen Gruppe in der auch eine Szene verarbeitet ist, diese hat den Namen der Szene.

• Wenn ein Script der yahka Adapter einen der Datenpunkte für eine Lampe nach der alten Syntax schreibt, dann stürzt der deconz Adapter ab.

Spoiler

2019-04-03 18:45:17.397 - error: Caught by controller[0]: TypeError: Cannot read property 'native' of null
2019-04-03 18:45:17.397 - error: Caught by controller[0]: at Socket. (/opt/iobroker/node_modules/iobroker.deconz/main.js:57:37)
2019-04-03 18:45:17.397 - error: Caught by controller[0]: at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
2019-04-03 18:45:17.397 - error: Caught by controller[0]: at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Manager. (/opt/iobroker/node_modules/component-bind/index.js:21:15)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Manager.ondecoded (/opt/iobroker/node_modules/socket.io-client/lib/manager.js:332:8)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Decoder. (/opt/iobroker/node_modules/component-bind/index.js:21:15)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Decoder.Emitter.emit (/opt/iobroker/node_modules/component-emitter/index.js:134:20)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Decoder.add (/opt/iobroker/node_modules/socket.io-parser/index.js:246:12)
2019-04-03 18:45:17.398 - error: Caught by controller[0]: at Manager.ondata (/opt/iobroker/node_modules/socket.io-client/lib/manager.js:322:16)
2019-04-03 18:45:17.398 - error: host.ioTinker instance system.adapter.deconz.0 terminated with code 0 (OK)

A.

[Asgothian]

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

@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 0.4.0:

@siggi85 sagte in [Aufruf] deConz Adapter Testen 0.4.0:

Aktuell ist es immer aufregend den Adapter neu zu starten

Dann würde ich vorschlagen ihn nicht neu zu starten

Dafür habe ich noch zu viele Xiaomi Sensoren im Schrank liege die ich die nächste Zeit Stück für Stück verbauen, in meine Oberflächen, Skripte und Adapter hinzufügen möchte.

Ich habe für dieses Problem ggf. Eine Lösung. In meinem fork auf github habe ich für die Button-Events einen schattenevent eingefügt, der immer nur für 800 ms gesetzt wird. Insbesondere passiert dieses nicht beim Start des Adapters.

Du kannst den (wenn du magst) gerne mal testen, dazu müsstest du von hier installieren:

https://github.com/asgothian/ioBroker.deconz

A.

[Jey Cee]

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

alten Syntax schreibt

Was meinst du damit? Eigentlich ist der Fehler gar nicht möglich. Yahka müsste ein nicht vorhandenes Objekt beschreiben damit er auftritt. Kannst du irgendwie herausfinden welches Objekt yahka versucht zu beschreiben?

[Asgothian]

@Jey-Cee
Leider konnte ich das Objekt selber im Objektbaum nicht sehen. Allerdings war die Situation so:

• in Yahka eingetragen ist deconz.0.Light_20.on, iobroker.deconz 0.4.0 ist installiert
• Lampe lässt sich schalten.
• iobroker.deconz angehalten, alle Objekte unter deconz.0 gelöscht, ioBroker.deconz 1.0.2 installiert und gestartet
• Objekte im Baum nach dem neuen Muster angeordnet, Lampen lassen sich vom Objektbaum aus schalten.
• Reproduzierbar (jedes mal): Über HomeKit die Lampe an/aus schalten => ioBroker.deconz stürzt ab.

Genauer erklären kann ich leider nicht. Ich habe vergessen zu verifizieren ob Yahka den Datenpunkt wieder angelegt hat oder nicht.

A.

[Jey Cee]

@Asgothian kannst du mal im debug modus testen? Im log sollte eine Zeile zu finden sein wie die hier:

	stateChange deconz.0.Groups.1.bri {"val":125,"ack":false,"ts":1554368957051,"q":0,"from":"system.adapter.admin.0","lc":1554368957051}

[Asgothian]

@Jey-Cee Mach ich, aber erst heute Abend. Hab von hier keinen Zugriff auf das System.

A.

[siggi85]

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

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

@Jey-Cee sagte in [Aufruf] deConz Adapter Testen 0.4.0:

@siggi85 sagte in [Aufruf] deConz Adapter Testen 0.4.0:

Aktuell ist es immer aufregend den Adapter neu zu starten

Dann würde ich vorschlagen ihn nicht neu zu starten

Dafür habe ich noch zu viele Xiaomi Sensoren im Schrank liege die ich die nächste Zeit Stück für Stück verbauen, in meine Oberflächen, Skripte und Adapter hinzufügen möchte.

Ich habe für dieses Problem ggf. Eine Lösung. In meinem fork auf github habe ich für die Button-Events einen schattenevent eingefügt, der immer nur für 800 ms gesetzt wird. Insbesondere passiert dieses nicht beim Start des Adapters.

Du kannst den (wenn du magst) gerne mal testen, dazu müsstest du von hier installieren:

https://github.com/asgothian/ioBroker.deconz

A.

Cool danke!
Leider komme ich wohl aber erst Ende nächste Woche zum Testen, da wir aktuell Besuch haben und ich dadurch wenig Zeit zum Testen habe auf ein funktionierendes System angewiesen bin.
Trotzdem schon mal danke für die Änderung, Ende nächster Woche teste ich auf jeden Fall!

[Asgothian]

@Jey-Cee
So.. test gemacht:

deconz.0 auf debug logging gestellt.
In Yahka einen Datenpunkt für "on" von deconz.0.Lights.3.on auf deconz.0.Light_3.on umgebogen.
per HomeKit (von iOS aus) versucht die Lampe zu schalten - und Bumm

Spoiler

host.ioTinker 2019-04-04 17:59:36.509 error instance system.adapter.deconz.0 terminated with code 0 (OK)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Manager.ondata (/opt/iobroker/node_modules/socket.io-client/lib/manager.js:322:16)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Decoder.add (/opt/iobroker/node_modules/socket.io-parser/index.js:246:12)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Decoder.Emitter.emit (/opt/iobroker/node_modules/component-emitter/index.js:134:20)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Decoder.<anonymous> (/opt/iobroker/node_modules/component-bind/index.js:21:15)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Manager.ondecoded (/opt/iobroker/node_modules/socket.io-client/lib/manager.js:332:8)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Manager.Emitter.emit (/opt/iobroker/node_modules/socket.io-client/node_modules/component-emitter/index.js:133:20)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Manager.<anonymous> (/opt/iobroker/node_modules/component-bind/index.js:21:15)
host.ioTinker 2019-04-04 17:59:36.509 error Caught by controller[0]: at Socket.onpacket (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:236:12)
host.ioTinker 2019-04-04 17:59:36.508 error Caught by controller[0]: at Socket.onack (/opt/iobroker/node_modules/socket.io-client/lib/socket.js:312:9)
host.ioTinker 2019-04-04 17:59:36.508 error Caught by controller[0]: at Socket.<anonymous> (/opt/iobroker/node_modules/iobroker.deconz/main.js:57:37)
host.ioTinker 2019-04-04 17:59:36.508 error Caught by controller[0]: TypeError: Cannot read property 'native' of null
deconz.0 2019-04-04 17:59:35.989 error TypeError: Cannot read property 'native' of null at Socket.<anonymous> (/opt/iobroker/node_modules/iobroker.deconz/main.js:57:37) at Socket.onack (/opt/iobroker/node_modules/socket.io-client/l
deconz.0 2019-04-04 17:59:35.988 error uncaught exception: Cannot read property 'native' of null
deconz.0 2019-04-04 17:59:35.914 debug dp: on; id:Light_3
deconz.0 2019-04-04 17:59:35.913 debug stateChange deconz.0.Light_3.on {"val":true,"ack":false,"ts":1554393575905,"q":0,"from":"system.adapter.yahka.0","user":"system.user.admin","lc":1554393575905}

Nachtrag: Ich hab auch einfach mal einen ganz anderen Datenpunkt genommen, einen der vom Namen ueberhaupt nicht in das system passt, aber in Deconz.0 liegt (deconz.0.michgabesnochnie.on). Das Ergebnis ist identisch.

Spoiler

deconz.0 2019-04-04 18:04:26.786 error uncaught exception: Cannot read property 'native' of null
deconz.0 2019-04-04 18:04:26.786 debug dp: on; id:michgabesnochnie
deconz.0 2019-04-04 18:04:26.784 debug stateChange deconz.0.michgabesnochnie.on {"val":true,"ack":false,"ts":1554393866769,"q":0,"from":"system.adapter.yahka.0","user":"system.user.admin","lc":1554393866769}

[Asgothian]

Noch ein Nachtrag:

Ich hab einfach einmal von Hand einen Datenpunkt konstruiert (Siehe Bild), und diesen mit Yahka verbunden.

Damit "geht" es, i.e. Yahka kann den schalten, und es passiert auch nichts böses.
Log:

Spoiler

deconz.0 2019-04-04 18:08:47.626 debug dp: on; id:ManualObject
deconz.0 2019-04-04 18:08:47.625 debug stateChange deconz.0.ManualObject.on {"val":false,"ack":false,"ts":1554394127619,"q":0,"from":"system.adapter.yahka.0","user":"system.user.admin","lc":1554394127619}
deconz.0 2019-04-04 18:08:44.194 debug dp: on; id:ManualObject
deconz.0 2019-04-04 18:08:44.193 debug stateChange deconz.0.ManualObject.on {"val":true,"ack":false,"ts":1554394124191,"q":0,"from":"system.adapter.yahka.0","user":"system.user.admin","lc":1554394124191}

[Jey Cee]

@Asgothian gut zu wissen, das muss ich abfangen.

[Wildbill]

Hi,

seit heute läuft bei mir auch ein Conbee-II-Stick. Soweit alles problemlos, allerdings habe ich einen eigenartigen Effekt. Die Zeit bei lastupdated hängt exakt 2 Stunden hinterher. Deconz läuft auf einem Raspberry3 unter Raspbian (aktuelle Updates) in aktueller Version 2.05.61 (keine Beta). Der Raspberry zeigt mittels date die korrekte Zeit, auch die länderspezifischen Settings passen. Auf dem Raspi läuft auch noch PIVCCU, dort stimmen die Zeiten ebenfalls.
Iobroker läuft unter Ubuntu 18.04.2 in einer VM auf einem NUC, auch dort passt die Zeit und auch Skripte lösen korrekt aus und alles. Nur im Punkt lastupdated fehlen irgendwie zwei Stunden. Die Datenpunkte werden sofort und sauber aktualisiert, nur eben mit falschem Wert.

Also, wo kann ich noch schauen, wo die zwei Stunden Versatz stecken?

Gruss, Jürgen

[Asgothian]

@Wildbill

Ich hätte da 2 oder 3 Stellen im Verdacht:

• Eingestellte Zeitzone in der VM
• Eingestellte Zeitzone auf dem Host
• Eingestellter Ort im ioBroker

Was sagt die Zeit auf der Konsole in der VM bzw. auf dem Host ?

A.

[Asgothian]

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

Ich habe für dieses Problem (- wie erkenne ich Buttonpresses sauber, ohne das beim Neustart die events ausgelöst werden) ggf. Eine Lösung. In meinem fork auf github habe ich für die Button-Events einen schattenevent eingefügt, der immer nur für 800 ms gesetzt wird. Insbesondere passiert dieses nicht beim Start des Adapters.

Du kannst den (wenn du magst) gerne mal testen, dazu müsstest du von hier installieren:

https://github.com/asgothian/ioBroker.deconz

A.

Ich hab in den letzten 2 Wochen damit mal weitere Tests gemacht. Aus meiner Sicht funktioniert diese Methode deutlich besser als der "zuletzt geändert" Datenpunkt, primär weil diese Methode deutlich leichter in Skripten abzufragen ist. Ich nutze Events nach dem folgenden Muster.

on ({id: 'datenpunkt', change:'gt'}, function(obj) { 
    switch (obj.state.val) {
     case 1002: 
        // aktion auslösen
     break;
     case 2002:
        // aktion auslösen
      break;
    }
});

Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.

Ein Punkt noch: Seit der letzten Änderung des Adapters muss man nach dem Anlernen eines neuen Gerätes über die Phoscon Software den Adapter einmal neu starten. Das scheint systematisch so - ich hab inzwischen > 10 geräte neu angelernt und hatte immer nur einige Datenpunkte direkt, nie alle. Ich sehe das nicht als bug an der zu fixen ist, es sollte aber dokumentiert werden.

A.

[Wildbill]

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

@Wildbill

Ich hätte da 2 oder 3 Stellen im Verdacht:

• Eingestellte Zeitzone in der VM
• Eingestellte Zeitzone auf dem Host
• Eingestellter Ort im ioBroker

Was sagt die Zeit auf der Konsole in der VM bzw. auf dem Host ?

A.

Die habe ich schon alle durch. Date liefert sowohl auf dem Host (NUC), in der iobroker-VM als auch auf dem Raspberry die korrekte Zeit. In iobroker ist der Ort auch korrekt, die Astrozeiten steuern seit Beginn an Skripte zu den richtigen Zeiten an. Auch per Cronjob gestartete Events starten dann, wenn ich es erwarten würde. In der Phoscon-App wird mir auch die korrekte Uhrzeit angezeigt. Nur auf dem Weg von deconz zu iobroker gehen irgendwie zwei Stunden verloren. Und auch nur da.

Gruss, Jürgen

[siggi85]

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

Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.

Ich werde das wohl dieses Wochenende testen. Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.

[Asgothian]

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

Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.

Vorsicht dabei - Ich empfehle den folgenden Weg:

• alle Skripte anhalten
• Adapter anhalten
• Objektbaum deconz.0 löschen
• Adapter updaten
• Adapter starten
• Skripte umstellen und neu starten.

Ich hab das nicht so gemacht, und mir damit regelmässige Neustarts des Adapters eingehandelt, weil es Probleme mit den alten Skripten / den Alten Datenpunkten in Yahka gegeben hat.

A.

[siggi85]

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

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

Da ich aktuell auf 0.3.0 bin, ändert sich wohl etwas mehr, daher brauche ich ggf. etwas Zeit die potentiellen Anpassungen in Skripten vorzunehmen.

Vorsicht dabei - Ich empfehle den folgenden Weg:

• alle Skripte anhalten
• Adapter anhalten
• Objektbaum deconz.0 löschen
• Adapter updaten
• Adapter starten
• Skripte umstellen und neu starten.

Ich hab das nicht so gemacht, und mir damit regelmässige Neustarts des Adapters eingehandelt, weil es Probleme mit den alten Skripten / den Alten Datenpunkten in Yahka gegeben hat.

A.

Danke, so werde ich das machen!

[Wildbill]

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

Ich wuerde mich freuen wenn das noch jemand testen könnte, um zu sehen ob die Änderung für den Adapter auf Dauer sinnvoll ist. Alternative Vorschläge (hier oder auch am pull-Request auf Github) ist willkommen.

Hi, getestet und für gut befunden. Einzig der lange Klick auf die On/Off bei der Tradfri-remote will mir nun nicht immer gelingen. Aber den brauche ich auch nicht unbedingt...
Prinzip habe ich korrekt verstanden? Trigger und Auswerten nun auf "buttenpressed" anstatt "buttonevent"?

Wegen mir kann die Änderung so eingecheckt werden, wüsste gerade nichts, was dagegen spricht...

Gruss, Jürgen