Aqara Multisensor verliert immer Verbindung Conbee II

Begonnen von oelidoc, 29 Mai 2022, 17:31:46

Vorheriges Thema - Nächstes Thema

oelidoc

Hallo, ich habe hier 12 Aqara Tür/Fenster Kontakte und einen Aqara Multisensor WSDCGQ11LM über einen Conbee II angebunden.
Während die Tür/Fenster Kontakte alle funktionieren, verliert der Multisensor immer seine Verbindung, meistens nach Stunden, anfangs auch erst nach 1-2 Tagen. Ich muss ihn dann immer neu pairen, was problemlos klappt, damit er wieder ein paar mal sendet...

Was ich bisher gemacht habe:

den Multisensor zurückgesetzt (10 sec Knopf drücken usw.)
den Multisensor in der Phoscon App gelöscht und neu angelegt
die Batterie gewechselt
den Conbee II neu gestartet
die neueste Firmware 26720700 geflasht
die neueste Deconz Beta 2.16.01 installiert
den Zigbee Kanal gewechselt und alle 13 Geräte neu angelernt

Nichts hat geholfen - jemand eine Idee woran´s liegen könnte?

Hier noch ein List des ConbeeII
DEF        192.168.178.40
   FD         66
   FUUID      6210dcf6-f33f-74ea-0864-60232f2d9c74625d
   FVERSION   30_HUEBridge.pm:0.259530/2022-04-13
   INTERVAL   60
   NAME       Conbee_II
   NOTIFYDEV  global
   NR         526
   NTFY_ORDER 50-Conbee_II
   PORT       59276
   STATE      connected
   TYPE       HUEBridge
   apiversion 1.16.0
   bridgeid   00212EFFFF07C93C
   buf       
   host       192.168.178.40
   is_deCONZ  1
   mac        b8:27:eb:cd:81:d9
   manufacturer Royal Philips Electronics
   modelName  Philips hue bridge 2015
   modelid    deCONZ
   name       Conbee II
   swversion  2.16.1
   updatestate 0
   websocket  1
   websocketport 20877
   zigbeechannel 15
   READINGS:
     2022-05-15 10:57:17   groups          0
     2022-05-23 21:58:01   lastError       parameter, on, not available
     2022-02-19 13:12:22   lights          1
     2022-02-19 13:12:22   rules           0
     2022-02-19 13:12:22   scenes          0
     2022-02-19 13:12:22   schedules       0
     2022-05-23 16:49:21   sensors         16
     2022-05-29 17:18:31   state           connected
   helper:
     apiversion 69632
     count      1
     last_config_timestamp 1653837511
     offsetUTC  7200
     updatestate 0
     groups:
     ignored:
     lights:
       1:
         etag       288f84b0f30e291d1eba6341958cc253
         lastannounced
         lastseen   2022-05-29T15:18Z
         manufacturername dresden elektronik
         modelid    ConBee II
         name       Configuration tool 1
         swversion  0x26720700
         type       Configuration tool
         uniqueid   00:21:2e:ff:ff:07:c9:3c-01
         state:
     scenes:
Attributes:
   httpUtils  1
   icon       cul_usb
   key        FC16C4BC05
   noshutdown 1
   room       HUEDevice
und eines Sensors:
DEF        sensor 15  IODev=Conbee_II
   FUUID      628b9ec8-f33f-74ea-a740-5dd82d9265c8417c
   FVERSION   31_HUEDevice.pm:0.260120/2022-05-01
   ID         S15
   INTERVAL   
   IODev      Conbee_II
   NAME       Conbee_II_HUESensor15
   NR         558
   STATE      22.31 °C
   TYPE       HUEDevice
   has_events 1
   lastannounced 2022-05-29T15:14:26Z
   manufacturername LUMI
   modelid    lumi.weather
   name       Temperature 15
   on         1
   reachable  1
   swversion  20191205
   type       ZHATemperature
   uniqueid   00:15:8d:00:07:08:7b:02-01-0402
   READINGS:
     2022-05-29 16:40:05   IODev           Conbee_II
     2022-05-23 19:59:04   attrTemplateVersion Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor_20211015
     2022-05-29 17:15:42   battery         75
     2022-05-29 17:15:42   batteryPercent  75
     2022-05-29 17:15:42   lastseen        2022-05-29T15:15Z
     2022-05-29 17:15:42   reachable       1
     2022-05-29 17:15:42   temperature     22.31
   helper:
     devtype    S
     reachable  0
     state     
     update_timeout 1
     configList:
     json:
       ep         1
       etag       5386b516cba8ecf44320ff6d68317008
       lastannounced 2022-05-29T15:14:26Z
       lastseen   2022-05-29T15:15Z
       manufacturername LUMI
       modelid    lumi.weather
       name       Temperature 15
       swversion  20191205
       type       ZHATemperature
       uniqueid   00:15:8d:00:07:08:7b:02-01-0402
       config:
         battery    75
         offset     0
       state:
         lastupdated 2022-05-29T15:15:42.504
         temperature 2231
     setList:
Attributes:
   IODev      Conbee_II
   alias      Aqara Temperatur
   event-on-change-reading battery.*:2,temperature:0.5
   group      HUESensor
   icon       xiaomi_multi
   model      lumi.weather
   room       Garten,HUEDevice
   stateFormat temperature °C


Parallel läuft noch seit Jahren und problemlos eine HUE Bridge von Philips mit ein paar Lampen, das sollte doch aber kein Problem sein, oder?

Vielen Dank und liebe Grüße
oelidoc

rx

Ich hatte ebenfalls so einen Multisensor- darüber hinaus mittlerweile auch einen Aqara Button, die beide immer wieder die Verbindung verloren haben bzw. beim ersten Druck auf den Schalter nicht funktioniert haben. Ich habe die Komponenten dann einfach entsorgt, weil ich einfach auf einen Defekt getippt habe. Das Setup ist bei mir ebenfalls mit Conbee-Stick.
Server started with 1333 defined entities (fhem.pl:27302/2023-03-05 perl:5.028001 os:linux user:root pid:29591)

Beta-User

Ein ZigBee-Netz ausschließlich mit batteriebetriebenen Komponenten zu betreiben (zumal, wenn man parallel noch ein weiteres mit Router-Devices hat), ist auch nach meiner eigenen Erfahrung eher suboptimal. Alles, was eine Batterie hat, sollte ein dauerbestromtes Gerät als "nächsten hop" in der Nähe haben.
Die Xiaomi-Geräte scheinen da besonders sensibel zu sein, mein (früher) am häufigsten ausfallendes Gerät war ein Temp/Hum-Sensor dieser Marke.

Dass ein Aqara-Taster nach langer Nicht-Benutzung in eine Art Tiefschlaf zu verfallen scheint, ist mir auch schon aufgefallen. Ist etwas lästig, aber wenn man das weiß, ist es kein Beinbruch...
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

oelidoc

#3
Leider verliert der Multisensor nach unterschiedlich langer Zeit auch seine Verbindung, wenn er nur 1,5 Meter vom Conbee II Stick entfernt liegt. Und die Philips Hue Leuchten befinden sich alle im Garten - also viel weiter weg. An Pfingsten werde ich mal zigbee2mqtt statt deconz ausprobieren. Das soll woanders schon mal geholfen haben...

sash.sc

Wurde bei mir auch als nicht auffindbar angezeigt. Hat aber seine Werte gebracht.
Was auffällig war, über den normalen Webbrowser Firefox auf dem Laptop liest sich keiner der neue bewegungsmelder von xiaomi anlernen.

Bin dann übers Handy gegangen und da hat es ohne Probleme funktioniert.

Habe auch nen conbee 2.

Gruß Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Thyraz

Nicht hilfreich für den Ersteller dieses Threads, aber wenn jemand drüber stolpert:
Die Multisensoren scheinen ihr Routing nicht automatisch anzupassen?

Ich hatte auch massive Probleme mit diesen Teilen seit wir in ein größeres Haus gezogen sind.

Letztendlich hat ein neues Anlernen das Problem beseitigt. Aber nicht in der Nähe des Conbee II Sticks, sondern jeweils nahe an eine HUE Lampe gehalten die in der Nähe des jeweiligen finalen Einsatzortes steht.

Seither keinerlei Funkausfälle mehr.
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...

oelidoc

Ich habe die 13 Aqara Sensoren am Wochenende von deconz zu zigbee2mqtt mit conbee II umgezogen, war ein ziemlicher Akt, da die kleinen Fensterkontakte alle oben unsichtbar im Rahmen eingebaut sind und alle 12 neu angelernt werden mussten.

Seitdem hat der Multisensor allerdings seine Verbindung gehalten, mal sehen, ob´s von Dauer ist.

Dafür habe ich im Gegensatz zu deconz jetzt schon 2 x Fake Batterie Alarme bei den Fenstersensoren gehabt: springen plötzlich auf null Prozent, link quality geht runter und sie ließen sich dann nur durch langes Knöpfchen drücken im Anlernmodus wieder zur Weiterarbeit (sprich Batteriestand wie zuvor) überreden.

Hab ich da jetzt etwa den Teufel mit dem Beelzebub ausgetrieben?   :-[

Auffällig ist auch, dass unter zigbee2mqtt alle Sensoren eine link quality von 255 haben - egal wie weit sie vom conbee II weg sind.
Werde das jetzt noch ein paar Tage beobachten, wenn es nicht zuverlässig läuft, fliegt Aqara bei mir aus dem Sortiment.

Gruß

oelidoc

Jamo

https://forum.iobroker.net/topic/28650/conbee-ii-maximum-erreicht/7

Hier ist nochmal schön erklaert, was es mit dem ConbeeII support von 200 end-devices auf sich hat. Mit nur einem ConbeeII, und nur batteriebetriebenen end-devices sind es maximal nur 32, und die 32 müssen alle gut erreichbar sein.

Ich habe dann mal bei mir in der Phoscon App durchgezählt, und überraschenderweise war ich bei mehr als 32. Ich hatte mich auch immer gewundert warum manche Devices die Verbindung verlieren. Nachdem ich einige strombetriebene 'Router' eingefügt habe (Ikea Repeater, Lidl Silvercrest Zigbee Mehrfachsteckdosen), ist das Problem nicht mehr aufgetreten.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

oelidoc

Okay, bei mir aber nur 12 Fensterkontakte und ein Multisensor - macht 13 batteriebetriebene Geräte an einem Conbee II mit neuester FW.
Sollte also eigentlich funktionieren...

Gruß

oelidoc

oelidoc

#9
Kurze Rückmeldung:
der Aqara Multisensor verliert auch bei zigbee2mqtt und direkt neben dem Conbee II dauernd seine Verbindung und ist damit für mich leider nicht nutzbar. Schade  :'(

Gruß

oelidoc