NEWS
ZigBee neue/unbekannte Geräte - ab 1.2.0
-
@io_laurent was ist wenn du 10 eingibst ....
@arteck
Wenn der Vorhang ganz geöffnet ist (also=100%) und ich schreibe den Wert 10 in Position, schließt er 10%, also nur ein kleinwenig und schreibt mir dann von selbst den Wert 90% in Position.
Eigentlich sollte er bei 10 ja fast ganz geschlossen sein... -
Hallo,
habe die innr smart outdoor spots gepaired (OSL 130 C).
Diese wird als supported gepaired, meldet aber einen Status-Mappingfehler.



habe das Problem gefunden.
In /opt/iobroker/node_modules/iobroker.zigbee/lib/devices.js fehlt die Konfiguration für den 'OSL 130 C'
Habe diesen der Einfachheit halber mal beim 'FL 130 C'' hinzugefügt:{ models: ['FL 130 C', 'OSL 130 C'], icon: 'img/innr_flex_FL130C.png', states: lightStatesWithColortemp, linkedStates: [comb.brightnessAndState], }, -
habe das Problem gefunden.
In /opt/iobroker/node_modules/iobroker.zigbee/lib/devices.js fehlt die Konfiguration für den 'OSL 130 C'
Habe diesen der Einfachheit halber mal beim 'FL 130 C'' hinzugefügt:{ models: ['FL 130 C', 'OSL 130 C'], icon: 'img/innr_flex_FL130C.png', states: lightStatesWithColortemp, linkedStates: [comb.brightnessAndState], }, -
@Schranzistor ne gewolt glaube ich nicht.. nur weiss ich nicht obs sich was im converter geändert hat . bei uns nicht
-
@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. -
@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. -
@Bibo-13 Da sollte trotzdem ein Problem sein wenn 2 Leute das gleiche Problem reporten. Haben wir wirklich den gleichen 1.2 Stand?
-
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 -
@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
Hallo arteck, ich habe das update auf Version 1.20 gemacht und seit dem verhält sich ein Datenpunkt sehr, sehr seltsam., ich versuche das mal zu beschreiben.
Ich habe einen motorisierten Vorhang von Zemismart:

als model: owvfni3 (laut Änderungsprotokoll hast du den eingepflegt).
Vor dem Update (also mit Version 1.1.1) des Adapters konnte ich nur den Datenpunkt Position ändern. Stop ging nicht, open und close waren nicht vorhanden.
Nach Update auf Version 1.20 habe ich immer noch die gleichen Datenpunkte, stop geht leider immer noch nicht und open und close gibt es nicht.
Aber mit Position kann ich jetzt auch nicht mehr arbeiten, denn:
Beispiel: der Vorhang ist offen, Position=100%
Schreibe ich nun 90 in diesen Datenpunkt, also 90%, soll er sich nur ein kleinwenig schließen. Er fährt aber fast ganz zu (also auf 10%) und schreibt das dann auch von selbst in den Datenpunkt.
Also: ich will von 100 auf 90, schreibe 90 in den DP Position, der Vorhang schließt sich fast komplett, und der Wert von Position wird von selbst auf 10 geändert.
Ich weiß nicht, ob das verstehbar ist, ich kanns nicht besser erklären, könnte dir noch ein Video machen.
Kannst du da helfen?
Wäre toll, vielen Dank!@io_laurent diese Änderung ist das Problem
~~https://github.com/ioBroker/ioBroker.zigbee/issues/600~~
nope die ist nur für licht
-
@io_laurent diese Änderung ist das Problem
~~https://github.com/ioBroker/ioBroker.zigbee/issues/600~~
nope die ist nur für licht
@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.htmlNicht, dass wir aneinander vorbeireden...
-
@io_laurent diese Änderung ist das Problem
~~https://github.com/ioBroker/ioBroker.zigbee/issues/600~~
nope die ist nur für licht
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 -
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@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
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 :-)@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 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@Florian-Evers
Trotzdem vielen Dank, Florian. Dann werde ich wohl @arteck weiter auf die Nerven gehen müssen :grimacing: