Neue Adresse: die ioBroker-Webseite liegt jetzt auf iobroker.com

[poppele]

https://forum.iobroker.net/user/asgothian Ich habe nochmals unter 3.3.5 getestet hier ist das Verhalten insfesamt korrekt. Auch unter zigbbe2mqtt mit Zigbee2MQTT-Version 2.13.0 commit: fcbb7ff4 Frontend-Version 2.14.0 zigbee-herdsman-converters Version 26.90.0 zigbee-herdsman Version arbeitet der device korrekt.
E.

[Pedder007]

Hallo auch nochmal von mir. ich bin jetzt schonmal etwas weiter bei meiner Analyse hier.
Ich verwende folgende Geräte:

ALLE diese Geräte werden nach dem Update von 3.3.5 nach 3.5.5 verkehrt herum gesteuert.
Sprich, was vorher up war ist hinterher down. Die Ansteuerung erfolgt bei mir bei allen Devices über das Datenfeld 'state', mit dem Blockly-Befehl 'steuere...'
Ausgelöst wird die Steuerung dabei aus 2 verschiedenen VIS-en und automatisiert (Zeit- oder Beschattungssteuerung) direkt aus Blockly. Deshalb geht es erst über eine Variable, welche dann jeweils den zugehörigen Alias des jeweiligen Device-Datenfeldes triggert.
Dort wird dann je nach gesendetem Befehl mit 'UP', 'STOP', oder 'DOWN' das Datenfeld 'state' gesteuert.
Der Grad der Öffnung, Datenfeld 'position', wird bei mir nach dem Update, trotz verdrehter Ansteuerung, weiterhin korrekt angezeigt. Ist ebenfalls über Alias eingebunden.

Warum schreibe ich das bevor ich nun (pro Device-Typ, vorher/nachher) in die Logs einsteige?
Mich wundert das es wohl keine anderen Nutzer mit genau diesem Problem gibt und frage mich deshalb, ob ich evtl. bei der Ansteuerung einen Denkfehler gemacht habe? Weil wenn das so wäre, müsste ich wohl eher da ran gehen.

zigbee2MQTT habe ich bei Zigbee übrigens nicht im Einsatz, sondern nur den Zigbee-Adapter.

Evtl noch ein Aspekt:
Ich bin gerade per Admin mal zurück bis auf die Vers. 3.4.1. gegangen und habe festgestellt, dass das Problem (bei mir) schon mit dieser Version auftritt. Es ist also (bei mir) definitiv nicht erst ab Vers. 3.5.5.

Auf GIT finde ich dazu an Änderungen:

• new Binding UI
• new model specific option meta_state - accepts a list of states (.ie. 'state,brightness')
• adapter defined default-options

Hat sich da evtl. durch den 2.ten Bullet etwas im Umgang mit dem 'state' DP geändert?

[Asgothian]

@Pedder007 sagte:

Hallo auch nochmal von mir. ich bin jetzt schonmal etwas weiter bei meiner Analyse hier.
Ich verwende folgende Geräte:

Danke für die Info. Damit kann ich arbeiten.

ALLE diese Geräte werden nach dem Update von 3.3.5 nach 3.5.5 verkehrt herum gesteuert.
Sprich, was vorher up war ist hinterher down. Die Ansteuerung erfolgt bei mir bei allen Devices über das Datenfeld 'state', mit dem Blockly-Befehl 'steuere...'
Ausgelöst wird die Steuerung dabei aus 2 verschiedenen VIS-en und automatisiert (Zeit- oder Beschattungssteuerung) direkt aus Blockly. Deshalb geht es erst über eine Variable, welche dann jeweils den zugehörigen Alias des jeweiligen Device-Datenfeldes triggert.
Dort wird dann je nach gesendetem Befehl mit 'UP', 'STOP', oder 'DOWN' das Datenfeld 'state' gesteuert.
Der Grad der Öffnung, Datenfeld 'position', wird bei mir nach dem Update, trotz verdrehter Ansteuerung, weiterhin korrekt angezeigt. Ist ebenfalls über Alias eingebunden.

Auch das ist schon einmal hilfreich.

Warum schreibe ich das bevor ich nun (pro Device-Typ, vorher/nachher) in die Logs einsteige?
Mich wundert das es wohl keine anderen Nutzer mit genau diesem Problem gibt und frage mich deshalb, ob ich evtl. bei der Ansteuerung einen Denkfehler gemacht habe? Weil wenn das so wäre, müsste ich wohl eher da ran gehen.

Ich denke das du keinen Denkfehler gemacht hast. Ich denke eher das die Änderungen im ZHC Dich da treffen.

Ich habe auch noch gute Nachrichten - soweit ich den Code überblicken kann laufen die 3 TuYa alle über den gleichen Konverter - sprich logs reichen von genau einem davon, während der Lonsonho anders angesprochen wird.

Evtl noch ein Aspekt:
Ich bin gerade per Admin mal zurück bis auf die Vers. 3.4.1. gegangen und habe festgestellt, dass das Problem (bei mir) schon mit dieser Version auftritt. Es ist also (bei mir) definitiv nicht erst ab Vers. 3.5.5.

Auf GIT finde ich dazu an Änderungen:

• new Binding UI
• new model specific option meta_state - accepts a list of states (.ie. 'state,brightness')
• adapter defined default-options

Hat sich da evtl. durch den 2.ten Bullet etwas im Umgang mit dem 'state' DP geändert?

Nein, das ist nicht die relevante Anpassung. Entscheidend ist der Sprung von ZHC 25 (Zigbee Adapter 3.3.x) auf ZHC 26 (Zigbee Adapter 3.4.x oder neuer)

Insgesamt ist genau das auch das Problem - der Adapter hat genau keinen Device-Spezifischen Code für diese Geräte. Die Veränderung des Verhaltens liegt an einer Veränderung der Anforderungen der ZHC, so das ich dafür entsprechend 'optionen' einbauen muss. Nur muss ich erst einmal heraus finden an welchen Stellen da Anpassungen notwendig sind.

A.

Edit - Schreibfehler korrigiert

[Pedder007]

@Asgothian danke für Deine Rückmeldung
Verständnisfrage zu Deinem letzten Satz:
Benötigst Du dazu von mir entsprechende Logs als Input oder gehts Du bei Deiner Suche zunächst anderweitig vor?
Ich bin mir nicht sicher wie Du das genau meist
PS.
Werde frühestens Mitte nächster Woche dazu kommen Logs zu ziehen.

[Asgothian]

@Pedder007 sagte:

@Asgothian danke für Deine Rückmeldung
Verständnisfrage zu Deinem letzten Satz:
Benötigst Du dazu von mir entsprechende Logs als Input oder gehts Du bei Deiner Suche zunächst anderweitig vor?
Ich bin mir nicht sicher wie Du das genau meist
PS.
Werde frühestens Mitte nächster Woche dazu kommen Logs zu ziehen.

Ja, es würde helfen wenn ich die Logs von zumindest einem Lonsonho und einem Tuya Gerät bekomme.

Auch - welche Node Version nutzt du, und wenn es noch Node 22 ist, was passiert wenn du auf Node 24 hoch gehst ?

@poppele @skippy07 @falkomfs - Die Frage zur Node Version gilt auch für euch.

A.

[Skippy07]

Entschuldige das ich noch keine neuen Logs geliefert habe, bin im Moment wirklich voll mit Arbeit und kriege das irgendwie nicht fertig. Nächste Woche wird es wohl ruhiger, hoffe das klappt dann.

Nur Info: Node.js: v22.23.2

[Asgothian]

@Skippy07 sagte:

Entschuldige das ich noch keine neuen Logs geliefert habe, bin im Moment wirklich voll mit Arbeit und kriege das irgendwie nicht fertig. Nächste Woche wird es wohl ruhiger, hoffe das klappt dann.

Nur Info: Node.js: v22.23.2

Alles gut - gibt es einen Grund für dich nicht auf Node 24 zu aktualisieren ? Wenn nein wäre es gut das zu testen - ich sehe da eine Chance das damit die Effekte weg sind.

A.

[Skippy07]

@Asgothian sagte:

Alles gut - gibt es einen Grund für dich nicht auf Node 24 zu aktualisieren ? Wenn nein wäre es gut das zu testen - ich sehe da eine Chance das damit die Effekte weg sind.

A.

Weil Node 22 empfohlen wird oder ist mir da was entgangen?

[Thomas Braun]

@Skippy07 sagte:

Weil Node 22 empfohlen wird oder ist mir da was entgangen?

Stand heute ist nodejs@22 die empfohlene Version für den ioBroker.
Wenn es sich aber anbietet kann man auch schon mit 24 experimentieren. Wird vermutlich in nächster Zeit ohnehin zur neuen Empfehlung werden.
Mit

iob nodejs-update 24

bzw.

iob nodejs-update

kommst du ja auch ganz easy auf die gewünschte Version.

[Michael Schmitt]

@Thomas-Braun sagte:

Wenn es sich aber anbietet kann man auch schon mit 24 experimentieren.

also noch nicht auf dem Produktivsysten laufen lassen ?

[Thomas Braun]

@Michael-Schmitt sagte:

also noch nicht auf dem Produktivsysten laufen lassen ?

Musst du selber wissen.

[Pedder007]

@Asgothian Node 22.23.2, weil aktuell noch Standard
Logs, wie gesagt dann leider erst kommende Woche.

[Asgothian]

Es wäre gut wenn mindestens noch ein User, besser Zwei das System auf Node24 aktualisieren würden. Ich sehe da bei einem Produktivsystem aktuell auch keine Probleme - kann das aber letztendlich nicht entscheiden, da ich nicht weiss welche Adapter installiert sind. Mein System läuft bereits auf Node24 - allerdings habe ich die Geräte nicht.

Es gibt einen Hinweis darauf das das Problem unter Node24 nicht oder nicht in der Form auftritt. Siehe auch hier: https://github.com/ioBroker/ioBroker.zigbee/issues/2982#issuecomment-5531390105

A.
p.s. Wie gesagt läuft mein System auf Node24. Der einzige Adapter bei dem ich aus dem Stable heraus musste ist Yahka - der ist erst ab zu 1.1.16 Node24 kompatibel.

[Skippy07]

Ich bin dann mal auf Node 24 und habe 3.5.5 installiert und in der Tat die Jalousien laufen jetzt richtig herum.

[Asgothian]

@Skippy07 sagte:

Ich bin dann mal auf Node 24 und habe 3.5.5 installiert und in der Tat die Jalousien laufen jetzt richtig herum.

Vielen Dank für diese Verifikation. Ich gehe also erst einmal davon aus das die aktuelle Kombi von ZH/ZHC sich unter Node 22 anders verhält als unter Node 24 - werde dem aber erst einmal nicht im Detail weiter nachgehen.

Trotzdem werde ich mir die Konverter anschauen, und schauen ob mit weiteren Optionen da Abhilfe geschaffen werden kann ohne das auf Node 24 hochgezogen werden muss. Vielleicht bekomme ich alleine mit der Code-Analyse etwas heraus.

A.

[Pedder007]

Hallo zusammen, ich habe gerade den gleichen 'mutigen' Schritt vollzogen und kann es auch bestätigen.
Mit node v24.20.0 läuft auch bei mir die Zigbee v3.5.5 korrekt, bei allen drei Device-Typen.