NEWS
UNSOLVED Zigbee Probleme seit Update auf Adapter 1.4
-
Bin hier nach Tagen der Fehlersuche und nicht mehr funktinionierenden Heizungen etc. ziemlich ratlos und schreibe nun doch mal einen Beitrag und hoffe auf Hilfe.
Seit einem der letzten Updates funktionieren gleich 12 meiner Xiaomi Sensoren auf einen Schlag nicht mehr, bzw. auch das komplette Mesh-Netz nicht mehr sauber. Blöderweise kann ich nicht genau eingrenzen welches der Updates es war, da ich gleichzeitig auf den Zigbee Adapter 1.4 gewechselt habe, als auch ein pivccu Update gefahren haben und auch das Raspbian System aktualisiert habe, achja und leider auch noch ein Firmwareupdate angestoßen habe aus der Zigbee Instanz... Jedenfalls habe ich seit dem, seit ca. 1-2 Wochen gleich mehrere Probleme in einem vorher absolut stabilen System!
Das Log ist nach wie vor ohne Fehler!
Fehlerbilder:
- list itemSensoren lassen sich nicht normal löschen, Timeout Fehler
- list itemSensoren lassen sich bei erzwungenem Löschen danach nicht mehr einbinden, sie werden schlicht beim Anlernen nicht mehr erkannt, tauchen also nicht mal mehr in der Countdown Liste auf
- list itemTouchlink zurücksetzen funktioniert inzwischen ebenfalls nicht mehr, es passiert genau: nichts - weder die Lampen setzen sich zurück, noch die Steckdosen.
- list itemZigbee Adapter bzw. Rasppi muss 3- 4 mal am Tag neu gestartet werden damit die verbleibenen Sensoren wieder funktionieren, anderenfalls stellen sie einfach irgendwann die Arbeit ein und aktualisieren Ihren Status nicht mehr in den Objekten. Da ich dafür in Nodered eine Überwachung per Pushover laufen habe, sehe ich das immer recht schnell. Dabei fallen die Sensoren auch immer alle gleichzeitig aus... Manchmal kommen sie Stunden später aich alle gleichzeitig von allein wieder...
- list itemauch in der Netzwerkansicht bleiben alle Sensoren rot, keinerlei Verbindungen zum Coordinator. Hier hatte ich vor ca. 2 Monaten extra vom cc2531 auf den cc2652R gewechselt um per Zigbee 3.0 ein Mesh zu haben...
- list itemManchmal half auch per Touchlink die Steckdosen und Lampen zurückzusetzen und dann war sofort das Netzwerk wieder in der Ansicht und erreichbar... auch die Sensoren waren wieder alle da. Das hielt dann etwa 3-4 h und war wieder vorbei...
Was ich schon versucht habe:
- entfernen und reparieren des Adapters
- entfernen der Steckdosen (Osram Smart+) die vorher verlässlich als Repeater gearbeitet haben, seitdem kann ich gar keine Devices mehr am Coordinator neu anlernen
Aktuell hier im Einsatz:
- 11 Fenstersensoren von Xiaomi
- 1 Wassersesor
- 7 Temp Sensoren von Xiaomi
- 3 Steckdosen Osram Smart + als Repeater
- 10 hue E27 Birnen ohne Bridge
- diverse Thermostate von Homematic IP (die alle mit den Fenstersensoren kombiniert sind und deshalb gerade alle spinnen, da sie die Fenster falsch erkennen)
Systemdata Bitte Ausfüllen Hardwaresystem: Raspberry Pi 4 Arbeitsspeicher: 4GB Festplattenart: SSD Betriebssystem: Rasbian Buster Node-Version: v12.20.0 Nodejs-Version: v12.20.0 NPM-Version: 6.14.8 Installationsart: Skript Image genutzt: Ja -
@ujoerk zeig mal die ersten 10 zeilen aus dem log nach adapter start und die coordinator Kachel..
steck den cc2652R nicht in den USB3 porrt am pi
p.s.: die hue birnen sind auch Router.. also wenn du die plugs nicht brauchst dann entferne die aus dem netzt und gut ist .. musst die aber ordentlich ablernen.. aber erstmal nach und nach
-
ich habe inzischen noch mal alles komplett rausgeschmissen, auf die 1.4.1 geupdatet und neu initial angelernt. Dabei habe ich die meisten Lampen bisher ausgelassen und nur die Steckdosen und danach die einzelnen (noch nicht alle) Sensoren angelernt. Bisher, also seit ca. 20h läuft alles was angelernt ist wieder sauber.
Die Lampen kann ich leider nicht als Repeater nutzen, da alle Wandschalter analog sind. Sprich, an / aus wird über die Wandschalter geschaltet und damit sind die Lampen stromlos, ergo kein Repeater mehr. Nutze die nur um sie per Homekit über Szenen (bspw. Nachts) zu dimmen etc...
Hier das Log, ist identisch zum vorherigen, defekten, nur das dort noch Warnings kamen weil er die Lampen alle nicht mehr per Ping erreichen konnte, sprich, die waren alle weggeflogen.
zigbee.0 2021-01-03 21:16:57.795 info (2052) Zigbee started zigbee.0 2021-01-03 21:16:57.794 info (2052) 0x7cb03eaa0a08d2c8 (addr 38441): AB3257001NJ - OSRAM Smart+ plug (Router) zigbee.0 2021-01-03 21:16:57.792 info (2052) 0x001788010325fbc8 (addr 62891): 8718696449691 - Philips Hue White Single bulb B22 (Router) zigbee.0 2021-01-03 21:16:57.790 info (2052) 0x00158d0004a06d2e (addr 49634): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.789 info (2052) 0x00158d000478dfd4 (addr 28228): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.788 info (2052) 0x00158d00049ff639 (addr 27920): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.786 info (2052) 0x00158d00045ad104 (addr 40760): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.785 info (2052) 0x00158d0004a087fc (addr 53061): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.783 info (2052) 0x00158d00045cfb23 (addr 9106): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.782 info (2052) 0x00158d00049da8e1 (addr 7929): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.781 info (2052) 0x00158d0004a06db4 (addr 57203): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.779 info (2052) 0x00158d00045d006a (addr 17497): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.778 info (2052) 0x00158d00046057f6 (addr 43971): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.776 info (2052) 0x00158d0004523592 (addr 33608): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.775 info (2052) 0x7cb03eaa0a08f1a2 (addr 3135): AB3257001NJ - OSRAM Smart+ plug (Router) zigbee.0 2021-01-03 21:16:57.773 info (2052) 0x00178801026ce94b (addr 44203): 8718696449691 - Philips Hue White Single bulb B22 (Router) zigbee.0 2021-01-03 21:16:57.771 info (2052) 0x00158d0004a064de (addr 21850): SJCGQ11LM - Xiaomi Aqara water leak sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.770 info (2052) 0x00158d0004658d25 (addr 12923): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.767 info (2052) 0x7cb03eaa0a098d50 (addr 15825): AB3257001NJ - OSRAM Smart+ plug (Router) zigbee.0 2021-01-03 21:16:57.765 info (2052) 0x00158d000479a26f (addr 31927): MCCGQ11LM - Xiaomi Aqara door & window contact sensor (EndDevice) zigbee.0 2021-01-03 21:16:57.757 info (2052) 0x0017880102245bcd (addr 42406): 8718696449691 - Philips Hue White Single bulb B22 (Router) zigbee.0 2021-01-03 21:16:57.747 info (2052) Currently 20 devices are joined: zigbee.0 2021-01-03 21:16:57.735 info (2052) --> transmitPower : high zigbee.0 2021-01-03 21:16:57.735 info (2052) Unable to disable LED, unsupported function. zigbee.0 2021-01-03 21:16:57.725 info (2052) Coordinator firmware version: {"type":"zStack3x0","meta":{"transportrev":2,"product":1,"majorrel":2,"minorrel":7,"maintrel":1,"revision":20201026}} zigbee.0 2021-01-03 21:16:55.480 info (2052) Installed Version: iobroker.zigbee@1.4.1 zigbee.0 2021-01-03 21:16:55.314 info (2052) Starting Zigbee npm ... zigbee.0 2021-01-03 21:16:55.216 info (2052) starting. Version 1.4.1 in /opt/iobroker/node_modules/iobroker.zigbee, node: v12.20.0, js-controller: 3.1.6 zigbee.0 2021-01-03 21:16:49.610 info (1903) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason zigbee.0 2021-01-03 21:16:49.609 info (1903) terminating zigbee.0 2021-01-03 21:16:49.161 info (1903) Zigbee: disabling joining new devices. zigbee.0 2021-01-03 21:16:49.158 info (1903) cleaned everything up... zigbee.0 2021-01-03 21:16:49.154 info (1903) Got terminate signal TERMINATE_YOURSELF
aktuelles, unfertiges Netz:
Was allerdings immer noch anders ist und vorher (besser) funktioniert hat:
- Touchlink zurücksetzen über die Administration vom Adapter geht nach wie vor nicht, musste wieder alle Birnen per Hue Fernbedienung zurücksetzen. Vorher ging das, nach eingebundenen Steckdosen vollautomatisch in allen Zimmern mit Klick auf den Button
- vorher konnte ich beim Neuanlernen, nachdem die Steckdosen eingebunden waren die Adapter einfach so an ihrer Position zurücksetzen und anlernen, musste sie also nicht zum Coordinator tragen. Jetzt muss ich immer alles abbauen und am Coordinator anlernen, wie früher mit dem alten CC2531 und Zigbe 1.x
-
@ujoerk sagte in Zigbee Probleme seit Update auf Adapter 1.4:
Die Lampen kann ich leider nicht als Repeater nutzen, da alle Wandschalter analog sind. Sprich, an / aus wird über die Wandschalter geschaltet und damit sind die Lampen stromlos, ergo kein Repeater mehr. Nutze die nur um sie per Homekit über Szenen (bspw. Nachts) zu dimmen etc...
Das wird meiner Meinung nach nicht auf Dauer stabil laufen. Die Tatsache das 3 Repeater immer wieder im Netz auftauchen und dann heraus genommen werden ist denkbar schlecht. Dafür ist Zigbee nicht gemacht.
A.
-
@ujoerk sagte in Zigbee Probleme seit Update auf Adapter 1.4:
Die Lampen kann ich leider nicht als Repeater nutzen, da alle Wandschalter analog sind. Sprich, an / aus wird über die Wandschalter geschaltet und damit sind die Lampen stromlos, ergo kein Repeater mehr.
na dan willkomen im chaos... wenn du so ein chickmeck machst dann wunder dich nicht, dass das Netz nicht stabil ist... das Netz lebt von Routern.. und nur weil du der Meinug bist nö diese fungieren nicht als Router weil du das nicht willst heisst es lange nicht das es so technisch auch ist..
sry.. so ist es
-
@arteck said in Zigbee Probleme seit Update auf Adapter 1.4:
@ujoerk sagte in Zigbee Probleme seit Update auf Adapter 1.4:
Die Lampen kann ich leider nicht als Repeater nutzen, da alle Wandschalter analog sind. Sprich, an / aus wird über die Wandschalter geschaltet und damit sind die Lampen stromlos, ergo kein Repeater mehr.
na dan willkomen im chaos... wenn du so ein chickmeck machst dann wunder dich nicht, dass das Netz nicht stabil ist... das Netz lebt von Routern.. und nur weil du der Meinug bist nö diese fungieren nicht als Router weil du das nicht willst heisst es lange nicht das es so technisch auch ist..
sry.. so ist es
Naja, die Steckdosen sind ja immer verfügbar als Router... wäre aber schon krass, denn wenn dem wirklich so wäre dann wäre doch aber Zigbee 3.x schon per Definition eben kein MESH Netz! Denn genau das ist ja eines der Ken-Features einer Mesh-Struktur. Siehe Definition:
https://www.ip-insider.de/was-ist-ein-mesh-network-a-681042/
oder für Zigbee: https://www.conrad.de/de/ratgeber/technik-einfach-erklaert/zigbee-standard.html#meshIn einem Mesh Netz gibt es eben beliebig viele Verbindungsstrukturen und es ist ausfallsicher. Fällt ein Knoten / Router aus wird ein anderer Weg gewählt. Was stimmt denn dann nun? Bin als Dipl. Informatiker zugegebener Maßen verwirrt...
Aber nun gut, wenn sich das bewahrheitet hab ich in der Tat ein Problem und werde wohl von Smart auf Analog zurückrüsten... den in einer Mietwohnung nun auch noch 30 vorhandene Wandtaster auf Zigbee umzustellen wird mir dann doch preislich und vom Aufwand zu oversized, zumal die einzig bezahlbaren Taster von Aqara nicht in die Einbaudosen passen...
-
@ujoerk sagte in Zigbee Probleme seit Update auf Adapter 1.4:
Fällt ein Knoten / Router aus wird ein anderer Weg gewählt.
Ja, aber nicht ad hoc.
Das kann bei zigbee schon mal ein paar Stunden dauern bis sich das Netz berappelt. -
Danke. verstehe... Widerspricht zwar auch der MESH Definition, lässt sich dann aber wohl nicht ändern mit der MESH-Mogelpackung
Zu schade... wenn ich jetzt noch wüsste wie ich meiner Frau erkläre, dass ich nach vielen Wochen Smart-Home Nachtschichten alles wieder zurückrüste... -
@ujoerk sagte in Zigbee Probleme seit Update auf Adapter 1.4:
Widerspricht zwar auch der MESH Definition
Warum? Von Zeiten bis sich das Netz erholt ist in den Definitionen doch gar keine Rede.
Ein WiFI-Mesh ist dann auch wieder was anderes als ein ZigBee-Netzwerk, welches auf Sparsamkeit hin entwickelt wurde. -
@Thomas-Braun
naja... Auslegungssache Wenn ich das so zu meinen Industrikunden in Bezug auf die MESH Netze für Ihre Maschinen erklären würde, gäbe es mein Unternehmen nicht mehrAuch die Conrad Definition ist Auslegungssache: "Die Mesh-Funktion verhindert überdies Funklöcher und sorgt für eine hohe Zuverlässigkeit: Im Falle einer Unterbrechung des Signalpfads durch ein abgeschaltetes oder ausgefallenes Gerät wird einfach eine alternative Route über die anderen Geräte verwendet, um das Datensignal ans Ziel zu bringen." Explizit wird laut denen auch ein ausgeschaltetes Gerät umgangen...
However, ändert ja nichts. Sollte es mir wieder abschmieren und alle Sensoren wegfliegen muss es eben weg, bringt mir dann leider nichts wenn das eben Stand der Technik ist, dann ist es eben die falsche Technologie für mich Hat trotzdem bisher irre Spaß gemacht... Und ist wirklich etwas schade, da ich schon aktuell mind. 20 Anwendungsfälle im Business Umfeld von Maschinensteuerung und Sensorik in meinen Projekten dafür im Kopf hatte...
EDIT: Und klar, Sparsamkeit vs. Stabilität, da hast du schon Recht... WiFi ist (wenn nicht Wifi 6 und mit sinnvollem Ubiquity Mesh oder ähnlichem) auch Schrott in den meisten Industriehallen in denen Starkstom oder große EM Felder im Spiel sind... Hier habe ich auch schon viel lernen dürfen
-
@ujoerk
Um hier ein wenig Klarheit rein zu bringen:- Das Zigbee Mesh funktioniert auch bei wechselnden Routern da problemlos wo Geräte regelmässig ansprechbar sind und sich über einen weggefallen Router austauschen können. Das ist bei den meisten fest am Strom hängenden Geräten der Fall (aber nicht bei allen)
- Batteriebetriebene Geräte sind kritisch, da diese nur wenn sie aktiv sind versuchen eine Nachricht an das Netz abzusetzen. Wenn ihnen das nicht gelingt dann gibt es nur ein kleines Fenster in dem sie versuchen (können) einen korrekten Adressaten für ihre Nachricht zu bekommen. Die Mesh Spezifikation gibt ein solches verhalten durchaus her - allerdings halten sich nicht alle Geräte daran so das es immer wieder zu Auffälligkeiten kommt.
In deinem Fall kann es dazu führen das einzelne Sensoren aus dem Netz fallen wenn sich diese vorher an eine Lampe gekoppelt haben die dann nicht verfügbar ist. Dagegen ist wenig zu tun. Auch hilft es nicht unbedingt das Netz mit Repeatern voll zu stopfen da gerade die batteriebetriebenen Geräte keine lange Liste von "Nachbarn" zu führen scheinen.
In wie weit dieses Verhalten für Dich zu einem Problem führt musst du selber bewerten. Die Warnmeldungen wegen nicht erreichbarer Geräte kannst du so lange ignorieren wie du weisst das die Geräte nicht vorhanden sind.
A
-
@Asgothian
Ah, danke, das erklärt es, wenn sich die Devices Ihre Nachbarn nat. nicht ausreichend abspeichern geht das nicht... Aktuell sind die Osram Dosen super Positioniert, so dass quasi jeder Raum einen eigenen Router hat und auch der Weg dahin "geroutert" ist. Nur hängt sich eben tats. manchmal eine Lampe dazwischen, weil die Couchlampe eben neben dem FEnstersensor ist oder die SZ Lampe neben dem Temp. Sensor im SZ... klar, dämlich... Wäre aber auch echt herb, wenn sich die Aquara Teile nur einen oder zwei Nachbarn merken könnten...wirklich problematisch ist das für mich nur im Falle der Fenster Sensoren, da diese den geöffnet Status an die Homematic Thermostate schicken. Fällt also der Fenstersensor im geschlossen Zustand aus ist das nicht so schlimm - läuft nur bei offenem Fenster die Heizung Amok. Umgedreht ists schlimmer, fällt der Sensor aus wenn das Fenster offen ist, so bleibt der Status offen und die Thermostate lassen sich manuell nicht mehr bedienen / die Temperatur lässt sich nicht hochregeln. Da muss ich jedes mal auf die iobroker Webseite und den Status des Sensors manuell verändern, damit NodeRed das dann an das Thermostat pusht... Sonst wirds mächtig kalt, zumindest im Kinderzimmer kritisch...
-
@ujoerk ich nutze zur Überwachung der ausgefallenen Zigbee-Geräte folgendes Batterie-Skript und lass mich zusätzlich zum Batteriestatus noch über ausgefallene Geräte per Telegramm informieren.
Funktioniert super!
https://github.com/Pittini/iobroker-Batterienauswertung -
@TheFoX
Danke für die Batterieüberwachung! Ich schaue mir das Script bei Gelegenheit mal an, denn die habe ich noch nicht, gebe aber den Status der Batterie über Yakha an Homekit und sehe es dort frühzeitig...Die Überwachung der ausgefallenen Sensoren habe ich jetzt schon via NodeRed und Pushover Adapter... bekomme dort nur immer ein Problem wenn so viele Adapter auf einmal ausfallen, weil er dann versucht bspw. 20 Pushover Nachrichten auf einmal zu senden was zu einem To Many Replys bei Pushover führt...
Hilft mir aber früh bspw. auch noch nicht. Zu der Zeit zu der ich das Fenster im Kinderzimmer schließe habe ich das Handy noch nicht in der Hand. Und selbst wenn müsste ich wie gesagt erst mühsam im Webinterface den Status des Fensters manuell auf Closed setzen...
Trotzdem Danke!