Aqara Button (WXKG11LM) - alle 5-6 Minuten state Aktualisierung?

Begonnen von shamal2008, 09 Mai 2020, 13:57:56

Vorheriges Thema - Nächstes Thema

shamal2008

Hallo zusammen,

vielleicht kennt jemand von euch das Phänomen und hat auch eine Lösung dafür:

Der Aqara Button (WXKG11LM - https://www.amazon.de/Aqara-Wireless-Switch-Mini-Lichtschalter/dp/B07D19YXND) sollte bei mir diverse Schaltungen vornehmen. Zuerst als Türgong mit Sonos URIPlay.

Ich konnte in in deconz einbinden und auch im FHEM erkennen. Er liefert einen state und div. andere Readings (battery, temperature, etc.).

ALLERDINGS: das Teil hat ein mehr als seltsames Verhalten: Sobald ich ein DOIF mit der State-abfrage auf 1002 (einmal drücken) oder 1004 (zweimal) mache, beginnt er im ca. 5-6 Minuten Takt selbstständig ein state-Update zu schicken und löst die "Dampflok" (=Gong) aus. Das macht er auch, wenn man stattdessen testweise ein Leuchte steuern will, dann wird halt das licht eingeschalten. Er liefert scheinbar immer 1002 als "state", auch wenn nichts gedrückt wird.

Ich habe mein Doif schon so ergänzt, dass ich nach jedem Durchführungsbefehl ein setreading state off einfüge und das als "Einsprungspunkt" für das Doif verwende. Hilft auch nicht. Das Doif löst weiterhin alle 5-6 Minuten aus.

Habe auch event-on-update state rausgenommen, sondern reagiere eigentlich nur mehr auf ein event-on-change. Den timestamp habe auch mal testweise drin. Devstateicon ist auch nur, damit ich "sichtkontrolle" habe, was er eigentlich tut.

So ist der Switch konfiguriert:

Internals:
   DEF        sensor 28  IODev=gw.deconz
   FUUID      5e9f2703-f33f-6c8f-2ff0-7cb114dc60a1bad4
   FVERSION   31_HUEDevice.pm:0.217030/2020-04-16
   ID         S28
   INTERVAL   
   IODev      gw.deconz
   NAME       sw.button
   NR         289
   STATE      1004
   TYPE       HUEDevice
   lastupdated 2020-05-09 11:40:08
   lastupdated_local 2020-05-09 13:40:08
   manufacturername LUMI
   modelid    lumi.remote.b1acn01
   name       Smart Switch
   on         1
   reachable  1
   swversion  20180525
   type       ZHASwitch
   uniqueid   00:15:8d:00:04:01:92:9f-01-0012
   READINGS:
     2020-05-09 13:02:13   battery         100
     2020-05-09 13:02:13   batteryPercent  100
     2020-05-09 13:02:13   reachable       1
     2020-05-09 13:40:08   state           1004
     2020-05-09 13:02:13   temperature     30
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     configList:
     json:
       ep         1
       etag       a4cf1056e2598439007d10f18e1d3073
       manufacturername LUMI
       mode       1
       modelid    lumi.remote.b1acn01
       name       Smart Switch
       swversion  20180525
       type       ZHASwitch
       uniqueid   00:15:8d:00:04:01:92:9f-01-0012
       config:
         battery    100
         temperature 3000
       state:
         buttonevent 1004
         lastupdated 2020-05-09T11:40:08
     setList:
Attributes:
   DbLogExclude .*
   IODev      gw.deconz
   devStateIcon off:ios-off 1002:audio_sound 1004:audio_sound
   event-on-change-reading state,reachable,batteryPercent,battery
   genericDeviceType switch
   group      03_Status
   icon       ring
   model      ZGPSWITCH
   room       01_Dashboard,10_Vorzimmer
   subType    switch
   timestamp-on-change-reading state


Habt ihr eine Idee dazu?
lg Shamal
FHEM auf RasPiI 3+, MapleCUL 868+433MhZ, MAX! via CUL, LD686 LED-Controller, GHoma Plugins,, Shelly, ConbeeII + IKEA + Xiaomi, div. Infodienste & Google Assistant via FHEM;

Ronn

Hallo shamal2008,
hallo zusammen,

konntest du hierzu eine Lösung finden? ich stehe genau vor dem gleichen Problem. Ich habe einige DOIF mit einem ":state:sec"-Timer. Dadurch funktionieren diese nicht mehr richtig.

Kann mir jemand dabei helfen wie ich das lösen könnte?

Benutze deCONZ neueste Version in einem Docker.

Beste Grüße + Dank

TiPpFeHlEr

#2
Hi folks,

ich kenne das Problem auch

Der Taster gibt nur beim loslassen (kurzer Druck) ein Signal. nicht beim drücken.
Das wäre der Status 1002

diesen sendet er auch bei fast jedem Statuspaket (reachable etc...) mit.(logge das grade mal mit)
somit reagiert ein DOIF immer auch dann auf den state.1002


2022-08-13_08:08:00 HUESensor103 1002
2022-08-13_08:08:00 HUESensor103 reachable: 1
2022-08-13_08:08:00 HUESensor103 battery: 100
2022-08-13_08:08:00 HUESensor103 lastseen: 2022-08-13T06:08Z
2022-08-13_08:08:00 HUESensor103 temperature: 28
2022-08-13_08:08:00 HUESensor103 batteryPercent: 100


Damit ist dieser Taster praktisch unbrauchbar für kurze Tastendrücke.


mfg maik

update: Post unten

Beta-User

HUEBridge etc. sind aktuell? dto. die Firmware des Interfaces etc? Anlernen mal wiederholt?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TiPpFeHlEr

Zitat von: shamal2008 am 09 Mai 2020, 13:57:56

ALLERDINGS: das Teil hat ein mehr als seltsames Verhalten: Sobald ich ein DOIF mit der State-abfrage auf 1002 (einmal drücken) oder 1004 (zweimal) mache, beginnt er im ca. 5-6 Minuten Takt selbstständig ein state-Update zu schicken und löst die "Dampflok" (=Gong) aus. Das macht er auch, wenn man stattdessen testweise ein Leuchte steuern will, dann wird halt das licht eingeschalten. Er liefert scheinbar immer 1002 als "state", auch wenn nichts gedrückt wird.


kannst du mal dein doif zeigen?

ich habe da einen verdacht, ich habe meins jetzt so hinbekommen das er nicht mehr falsch reagiert.
Ob es wirklich geht sehe ich aber erst nach einem Tag, wenn öfter mal ein Status reinkam.

Gruß Maik

TiPpFeHlEr

Also,

bei mir scheint es jetzt zu funktionieren.

altes DOIF
([Switch1] eq "1002")(set ON_dummy [Switch_dummy:state];set Ankleide_doif cmd_1)
hierbei triggerte das DOIF auf das Device Switch1, und somit erkannte das DOIF das alte reading state:1002.
Obwohl das reading state sich selber nicht aktuallisiert hatte.

neue DOIF
([Switch1:state] eq "1002")(set ON_dummy [Switch_dummy:state];set Ankleide_doif cmd_1)
hierbei triggert das reading Switch1:state direkt das DOIF, somit wird das DOIF nur aktiv wenn sich Switch1:state ändert/aktuallisiert.

Der Fehler lag also wieder mal vor der Tastatur  ;D

Mfg
Maik