Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Bibo*13]

@arteck WXKG11LM
Aqara wireless switch supports: single, double click (and triple, quadruple, hold, release depending on model) seit 1.2 funktioniert der 3 und 4 fach Klick bei mir auch nicht mehr.

[Dragon]

@Bibo-13 Hier ohne Probleme

[Bibo*13]

@Bibo-13 Da sollte trotzdem ein Problem sein wenn 2 Leute das gleiche Problem reporten. Haben wir wirklich den gleichen 1.2 Stand?

[arteck]

@Bibo-13 gestern gabs ein fix für

[Bibo*13]

@arteck Heißt? 1.2 neu installieren?

[Bibo*13]

@arteck Von wo bitte updaten? latest oder git???

[Kueppert]

@Bibo-13 da ich auf latest stehe und kein Update angeboten bekommen hab gestern, vermute ich, dass es git sein wird. Aber warten wir lieber die Rückmeldung vom Master ab ;)

[arteck]

ja von GIT

[JackDaniel]

wenn die TRADFRI open/close remote über den deconz adapter am iobroker angebunden wird gibt es da dann sogenannte buttonevents (zb. 1002 für kurz und 1003 für langen tastendruck bei open), wäre es möglich sowas auch bei diesem adapter zu integrieren?
damit könnte man schön noch zwei zusätzliche position mit der rollo anfahren :blush:
im moment geht das nichtmal über ein ausführen timout, weil der datenpunkt auch bei langen tastendruck sofort wieder auf false wechselt :(
beim TRADFRI ON/OFF switch geht es mit dem timeout da der datenpunkt so lange der taster betätigt ist auf true bleibt.

danke im voraus

[Bibo*13]

@arteck Ok. Das funktioniert wieder. Sowohl 3fach als auch 4fach Klick geht wieder. Danke

Ich habe immer noch das Problem mit den Error Meldungen das erst seit 1.2 auftaucht. Unter 1.1.1 gab es das nicht.

DeviceConfigure failed 0x04cf8cdf3c78dbc9 lumi.sen_ill.mgl01, attempt 5 (Error: Bind 0x04cf8cdf3c78dbc9/1 genPowerCfg from '0x00124b00014d2885/1' failed (AREQ - ZDO - bindRsp after 10000ms)

Nach 5 Versuchen ist dann Ruhe. Der Sensor funktioniert übrigens.

[arteck]

@io_laurent diese Änderung ist das Problem

~~https://github.com/ioBroker/ioBroker.zigbee/issues/600~~

nope die ist nur für licht

[io_laurent]

@arteck
Nur um sicher zu gehen: du schreibst auf GitHub von Problem mit TRADFRI Curtain, ist aber kein TRADFRI, sondern ein Zemismart bzw. Tuya bzw. owvfni3 , also der hier:
https://www.zigbee2mqtt.io/devices/TS0601_curtain.html

Nicht, dass wir aneinander vorbeireden...

[Florian Evers]

Hallo,

ich war es, der für den besagten Patch (600) verantwortlich ist. Mir ist nicht klar, wie dieses "Rollo" (oder was genau das ist) angesteuert wird... tatsächlich so wie eine "Lampe" über ein "brightness"-Level? Ich habe mit dem Patch lediglich das Mapping zwischen "brightness" (0...100) und Lampenlevel (0...254) angepasst, und zwar für Lampen. Und geändert hat sich nicht viel: auch früher schon wurde immer "0" als "aus" verschickt; der niedrigste aktive Dimmwert ist aktuell "2/254", früher war es "3/254". Ich sehe noch nicht, wo das Problem herkommen soll.

Viele Grüße,
Florian

[io_laurent]

@Florian-Evers
Ich weiß leider auch nicht genau, was arteck meint. Auf GitHub schrieb er von einem tradfri curtain, es ist aber ein zemismart Vorhang.
So sehen dessen Datenpunkte aus:

Es geht um den Datenpunkt "position". 100% = Vorhang offen, 0%= Vorhang zu. Dieser Datenpunkt verhält sich sehr seltsam:
Also: ich will von 100% (=offen) auf 90% (= nur ein paar Zentimeter schließen), schreibe 90 in den DP "Position", der Vorhang schließt sich fast komplett (also er schließt sich zu eigentlich 10%) und sobald der Vorhang stoppt ändert sich der Wert position von selbst auf 10.
Wie und was das jetzt mit brightness zu tun hat, das weiß ich leider nicht.
Freu mich aber, wenn du helfen kannst :-)

[Florian Evers]

@io_laurent Ok, dann bin ich mir jetzt ziemlich sicher, dass mein Patch nichts mit dem Problem zu tun hat. Erstens fasse ich nirgends Datenpunkte namens "position" an, zweitens ist der von Dir beschriebene Effekt einer solchen falschen Umrechnung in meinem Patch nicht gegeben. Denn sollte tatsächlich "90%" in den falschen Rollo-Wert gewandelt und an das Rollo gesendet werden, würde der falsche Wert bei Bestätigung auch wieder "symmetrisch" in "90%" zurückgewandelt werden. Da hier aber etwas ganz anderes bei rauskommt sehe ich das Problem auch ganz woanders. Leider habe ich auch keine Idee wie und wo, da ich mich bislang nur mit Lampen beschäftigt habe, und da heißt der Datenpunkt immer "brightness".

Viele Grüße!
Florian

[io_laurent]

@Florian-Evers
Trotzdem vielen Dank, Florian. Dann werde ich wohl @arteck weiter auf die Nerven gehen müssen :grimacing:

[Florian Evers]

@io_laurent Teste mal bitte Folgendes:

• 90% führt zu "gefühlt" 10% und wird schlussendlich mit 10% bestätigt. So weit so gut.
• Was passiert mit 0%, 20%, 50%, 80% und 90%? Ist ein Muster erkennbar?
• Ggf. fahre das Rollo vorher immer auf wohldefinierte 100% und teste ab da. Vielleicht erwartet das Rollo als "Kommando" so etwas wie relative Bewegungswerte. 90% wäre vielleicht eine Bewegung um 90% auf besagte 10%.
• "Stottere" mal mehrmals mit "10%" als Kommando. Bleibt er beim zweiten Mal stehen, oder geht er jedesmal ein Stückchen weiter?

[io_laurent]

@Florian-Evers
Ich fürchte, genau so ist das.
Gebe ich 80 ein, er bewegt sich UM 80%, stoppt dann die Bewegung bei 20% und schreibt den Wert 20% dann auch in den Datenpunkt.
Bei 70% entsprechend Bewegung UM 70% bis stop bei 30%...usw.

[io_laurent]

@Florian-Evers
Bei mehrmals 10% Eingabe hintereinander bewegt er sich nur beim ersten mal und bleibt dann stehen, wenn ich immer wieder 10% eingebe.

[Florian Evers]

@io_laurent Prima! Das sind doch gute Nachrichten. So ein Verhalten ist vermutlich aktuell im ZigBee-Adapter noch nicht abgebildet worden und muss "nur" nachgerüstet werden. Kein Bug, nur ein neues Feature für ein neues Device.

Ich empfehle einen Bugreport / Featurerequest mit genau dem beobachteten Verhalten.

EDIT: Also Hin- und Rückrichtung haben eine andere Formel; eine Richtung ist quasi invertiert.