Zigbee-Mesh mehrmals mal pro Tag für 5 Minuten im Sekundentakt gestört

Die Ausfälle des Zigbee2MQTT Netzes häuften sich zunehmend.
Der Grund war zunächst nicht offensichtlich.

Es sah anfangs danach aus, als wenn der Koordinator (SLZB-06) die Netzwerkkonnektivität über den POE-Injector verlieren würde. Das war aber nicht so.

Im FritzBox-Log habe ich gesehen, dass an einem Repeater eine Störung durch Radarstrahlung eingetragen war. Das streut in das 5Ghz Netz und kann auch die LAN-Konnektivität beeinflussen. Über diesen Repeater läuft das LAN-Kabel zum SLZB-06
Präsenzmelder deaktiviert - Störung des Z2M war immer noch da.

Sodann habe ich die Log-Files von Home Assistant, Mosquito-Broker & Zigbee2MQTT an die KI meines Vertrauens gesendet.
Das Ergebnis war überraschend.
Neben verschieden kleinen, nebensächlichen „Unsauberkeiten“ stand eine Sache im Vordergrund.

Um es vorweg zu nehmen - nachdem ich die Störquelle entfernt habe, läuft mein Zigbee-Mesh Störungsfrei.

Hier die Zusammenfassung der Analyse durch die KI:

1. Die Ursache: Frontend-Überlastung

Die ring-tile-card (eine Custom Card aus HACS) hat einen sogenannten Registrierungs-Konflikt verursacht. Im Log tauchte sekündlich folgende Fehlermeldung auf: Error: Failed to execute 'define' on 'CustomElementRegistry': the name "ring-tile" has already been used...

  • Was bedeutete das? Die Karte versuchte ständig, sich neu im System anzumelden. Da sie aber bereits registriert war (evtl. durch Mehrfachnutzung), erzeugte dies eine Endlosschleife an Fehlermeldungen.
  • Der „Stau“: Da diese Fehler im MainThread (dem Hauptprozessor-Kern) von Home Assistant (HA) verarbeitet wurden, war dieser zu fast 100 % mit der Fehlerausgabe beschäftigt.

2. Die Auswirkung auf Zigbee & MQTT

Obwohl die Hardware deiner Sensoren einwandfrei funktionierte, kam es zu einer Kettenreaktion:

  • Verzögerungen: Wenn ein Sensor (z. B. deine Haustür) ein Signal sendete, konnte HA dieses Signal nicht sofort verarbeiten, weil der „Stau“ durch die Frontend-Fehler den Weg blockierte.
  • Timeouts: Der MQTT-Broker (Mosquitto) bemerkte, dass HA nicht schnell genug antwortete, und schloss kurzzeitig die Verbindungen (Client <unknown> closed its connection).
  • Status „Unbekannt“: Wenn HA für einige Minuten keine neuen Daten vom MQTT-Broker verarbeiten kann, setzt es die betroffenen Sensoren sicherheitshalber auf den Status „unbekannt“, um Fehlbedienungen durch veraltete Daten zu verhindern.

3. Der Vorfall vom 11. Januar (Beispiel 09:34 – 09:38 Uhr)

In diesem Zeitraum kam alles zusammen:

  1. Hohe Aktivität: Die Haustür wurde geöffnet, Bewegung in der Küche wurde erkannt und die Spülmaschine lief.
  2. Kollaps: Die Masse an eintreffenden Zigbee-Signalen traf auf einen bereits durch die ring-tile-card völlig überlasteten Hauptprozessor.
  3. Funkstille: Das System konnte für ca. 4 Minuten keine Daten mehr wegschreiben oder anzeigen.

4. Die Lösung: Bereinigung des Systems

Nachdem du die folgenden Schritte durchgeführt hast, kehrte die Stabilität zurück:

  • Entfernen der Karte: Die Fehlerschleife im MainThread wurde gestoppt.
  • Ressourcen-Cleanup: Durch das Löschen der Einträge in HACS und den Dashboard-Ressourcen versucht HA nicht mehr, die fehlerhaften Dateien zu laden.
  • Ergebnis: Der Prozessor hat nun wieder die volle Kapazität, um Zigbee-Signale in Echtzeit zu verarbeiten.

Aktueller Status

Dein System läuft jetzt wieder faktisch sauber. Die Sensoren melden sich zuverlässig zurück, und im Log sind die massiven „Uncaught error“-Meldungen verschwunden. Die verbleibenden kleinen Fehler (wie die Manifest-Meldungen zu localtuya) sind im Vergleich dazu harmlos und belasten das Netzwerk nicht.

Ende der KI-Analyse


Damit will ich die Ring-Tile-Card nicht verurteilen,
Das System hat ja auch wochenlang damit störungsfrei gearbeitet.
Ob es am Zusammenspiel mit Card-Mod lag?
Ich kann auch keine Veränderung meinerseits, mit den Störfällen in einen zeitlichen Zusammenhang bringen.

Wenn in obiger Analyse die Rede vom Prozessor ist, ist damit mMn nicht die CPU meines NUC gemeint, sondern der MainThread (dem Hauptprozessor-Kern) von Home Assistant.
Die CPU meines NUC ist mit 8C/16T und 4,7GHz sehr performant. Die CPU-Auslastung liegt im Normalfall bei 1-2%.

Ich werde aus sportlichem Ehrgeiz und weil ich die Karte gut finde, sie wieder neu aktivieren und aufmerksam beobachten.

Ich finde es allerdings sehr spannend, wie 2 Komponenten, von denen man glaubt, dass sie überhaupt nichts miteinander zu tun haben, sich derart massiv stören.

2 „Gefällt mir“