UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

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

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

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

[Jey Cee]

@Wildbill hab den code 1:1 von @Asgothian übernommen, hab nur den PR nicht gemerged weil ich schon andere Änderungen lokal drin hatte. Die Zeit von 800ms ist drin.

Ich schau mir das nochmal an.

[Wildbill]

@Jey-Cee
Kein Problem. Ist ja kein Beinbruch und die Skripte waren schnell angepasst. Im Prinzip ist es ja so, wie es jetzt ist, fast logischer. Mich hat es nur gewundert, dass die Funktion sich geändert hat.
Also von meiner Seite hier wirklich kein Bedarf mehr, dem nachzugehen oder nochmal was zu ändern.
Stattdessen nochmal ein FETTES DANKE.

Gruss, Jürgen

[BigWumpus]

Habe gestern auf 1.1.1 umgestellt - startet nicht.

Erst die 1.0.1 startet wieder, also ab 1.1.0 habe ich den Fehler drin:

host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	info	Restart adapter system.adapter.deconz.0 because enabled
host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	error	instance system.adapter.deconz.0 terminated with code 1 ()
host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	error	Caught by controller[0]: at Object.<anonymous> (/opt/iobroker/node_modules/iobroker.deconz/node_modules/ws/index.js:3:19)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	error	Caught by controller[0]: at require (internal/module.js:20:19)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	error	Caught by controller[0]: at Module.require (module.js:504:17)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.198	error	Caught by controller[0]: at Function.Module._load (module.js:445:3)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at tryModuleLoad (module.js:453:12)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at Module.load (module.js:494:32)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at Object.Module._extensions..js (module.js:586:10)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at Module._compile (module.js:549:28)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at Object.runInThisContext (vm.js:97:10)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: at createScript (vm.js:56:10)
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: SyntaxError: Unexpected token ...
host.Home-Pi-ioBroker	2019-05-05 01:31:23.197	error	Caught by controller[0]: ^^^
host.Home-Pi-ioBroker	2019-05-05 01:31:23.196	error	Caught by controller[0]: ...options
host.Home-Pi-ioBroker	2019-05-05 01:31:23.196	error	Caught by controller[0]: /opt/iobroker/node_modules/iobroker.deconz/node_modules/ws/lib/websocket.js:347
host.Home-Pi-ioBroker	2019-05-05 01:31:21.707	info	instance system.adapter.deconz.0 started with pid 18094

[Jey Cee]

@BigWumpus läuft bei dir noch nodejs v6.x.x?

[BigWumpus]

@Jey-Cee
jupp, v6.14.3

So, Update nach hier durchgeführt.

Läuft jetzt!

[BigWumpus]

Das Problem mit dem unbekannten "Drücken"-Zustand bei Switches habe ich mit einer Abfrage gelöst:
Die letzte Änderung des Feldes "lastupdated" darf bei mir maximal 100ms alt sein, dann ist es frisch gedrückt, sonst kann es von einem Adapter-Neustart stammen. Diese Abfrage muß aber etwas verzögert erfolgen, weil der "Buttonevent" zuerst gesetzt wird und ca. 4ms später der "Lastupdated"...

Switch-Kopf.gif

[Asgothian]

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

@Wildbill hab den code 1:1 von @Asgothian übernommen, hab nur den PR nicht gemerged weil ich schon andere Änderungen lokal drin hatte. Die Zeit von 800ms ist drin.

Ich schau mir das nochmal an.

Hallo,

der Pull request den ich auf Github abgelegt hab hatte 2 Anpassungen am main.js - einmal auf die "true/false" Variante, die du auch in den haupt-zweig übernommen hast. Diese hat so nicht sauber funktioniert, da nach dem Trägern immer noch der Wert des eigentlichen buttonevent abgefragt werden muss. Deswegen hatte ich eine 2. Anpassung im Pull-Request, die den 'buttonpressed' auf den Wert setzt der auch im buttonevent drin steht, und später auf 0. Nur so kann man auch schnelle Tastenkombinationen sauber abfangen, da der Timeout kurz gewählt werden kann.

Kannst Du das noch anpassen ?

A.

[siggi85]

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

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

@Wildbill hab den code 1:1 von @Asgothian übernommen, hab nur den PR nicht gemerged weil ich schon andere Änderungen lokal drin hatte. Die Zeit von 800ms ist drin.

Ich schau mir das nochmal an.

Hallo,

der Pull request den ich auf Github abgelegt hab hatte 2 Anpassungen am main.js - einmal auf die "true/false" Variante, die du auch in den haupt-zweig übernommen hast. Diese hat so nicht sauber funktioniert, da nach dem Trägern immer noch der Wert des eigentlichen buttonevent abgefragt werden muss. Deswegen hatte ich eine 2. Anpassung im Pull-Request, die den 'buttonpressed' auf den Wert setzt der auch im buttonevent drin steht, und später auf 0. Nur so kann man auch schnelle Tastenkombinationen sauber abfangen, da der Timeout kurz gewählt werden kann.

Kannst Du das noch anpassen ?

A.

Fande ich auch super. 😊