ich möchte mein neues Modul Matter Diagnose vorstellen. Ihr findet es im Store unter „Matter Diagnose“.
Das Modul prüft mit einem Klick, warum Matter-Geräte nicht ins Haus kommen oder plötzlich verstummen – besonders bei Matter over Thread. Heraus kommt eine Ampel-Liste in Klartext: was los ist, was es bedeutet und was zu tun ist.
Entstanden ist es aus einer eigenen Fehlersuche: Ein IKEA-Sensor ließ sich am Windows-Rechner partout nicht koppeln, weil Windows die Route ins Thread-Netz nicht übernommen hatte. Symcon meldete nur „Fehlgeschlagen“. Solche Ketten soll die Diagnose künftig auf einen Blick zeigen.
Wann hilft das Modul?
Die Kopplung endet mit „Fehlgeschlagen“ – ohne weitere Angabe.
Ein Gerät steht auf „aktiv“, liefert aber keine Werte mehr, während es in der Hersteller-App oder in Home Assistant weiterläuft.
Nach einem Neustart oder Update sind Thread-Geräte tot.
Was wird geprüft?
IPv6 und Multicast am Symcon-Rechner (inkl. Docker ohne --network host)
sichtbare und koppelbereite Geräte – auch solche, deren Kopplungsfenster geschlossen ist
die in Symcon gekoppelten Geräte gegen das, was sich im Netz tatsächlich meldet
volle Tabelle der verbundenen Systeme eines Geräts (die häufige, aber unsichtbare Ursache für scheiternde Kopplungen)
die Route ins Thread-Netz: vorhanden, dauerhaft, automatisch gelernt, veraltet oder auf einen Border Router, den es nicht mehr gibt
die Gesundheit des Thread-Netzes: nur ein Border Router, getrennte Netze, zerfallene Partitionen, abweichende Einstellungen
Wo ein Befehl nötig ist (etwa zum Setzen einer Route), steht er fertig zum Kopieren im Formular. Ausgeführt wird nichts – die Diagnose ist rein lesend.
Dauerbetrieb
Ein Wächter wiederholt die Prüfung im Hintergrund (Vorgabe stündlich, ohne schlafende Batteriegeräte anzupingen) und schreibt nur dann in die Variable Letzte Änderungen, wenn sich wirklich etwas geändert hat – ein Gerät verschwindet, ein Border Router fällt weg, ein Befund kommt oder geht. Daran lässt sich eine Benachrichtigung hängen; ein Rezept steht in der Anleitung.
Voraussetzungen
Symcon 8.1 oder neuer, unter Windows und Linux (SymBox)
für den Geräteabgleich: der Matter Controller von Symcon
Besonders interessieren mich Anlagen, die ich selbst nicht habe: andere Border Router, Docker, mehrere Matter-Controller. Wenn der Bericht etwas Falsches oder Unverständliches meldet, schickt mir gern einen Screenshot. Ich freue mich über Rückmeldungen und Praxiserfahrungen.
vorhin beim Friseur hab ich diesen Beitrag gelesen und nachdem ich nun frisch geschoren zu Hause ankam direkt Dein Modul installiert. Super Sache das!!!
Hier bekommst DU dann auch direkt meine Diagnosedaten:
danke fürs Ausprobieren, und für die Screenshots gleich mit — zwei Sachen daraus sind behoben.
Vorweg: Der gelbe Hinweis heißt nicht, dass etwas kaputt ist. Die drei Geräte annoncieren sich im Netz gerade nicht, Symcons Verbindung zu ihnen ist davon unberührt; wäre das Abonnement weg, hättest du einen roten Befund bekommen. Die Karte aus Home Assistant widerspricht dem auch nicht, sie zeigt die Thread-Topologie und nicht die aktuellen Annoncen. Das sagt der Befundtext jetzt selbst, und Batteriegeräte tragen ein — Fenstergriff und Türschloss dürfen lange stumm bleiben, eine Steckdose am Stromnetz sollte sich melden.
Dein Apple TV war übrigens die ganze Zeit drin, als Loerdy-TV in der Zeile mit den Border Routern. Im Befund zum Thread-Funknetz fehlte es, weil von ihm in dem Lauf die _meshcop-Angaben (Netzname, Thread-Version) nicht ankamen — die fragt das Modul jetzt gezielt nach.
Beides liegt als Beta 0.4 build 32 im Store. Magst du aktualisieren und mir sagen, was danach bei der GRILLPLATS Plug steht, und ob ihre Werte in Symcon aktuell sind?
Von den Grillplats habe ich 2 und das sind ja keine Batteriegeräte.
Die habe wegen ihrer Funktion als Router mit eingebunden.
Wie man in der Graphik aus dem Home Assistant sieht sind die auch gemesht.
Immer wieder erstaunlich, was Ihr so auf die Beine stellt. Hut ab!
Danke, dein Bericht zeigt genau, was ich sehen wollte: Der Apple TV steht jetzt im Thread-Netz und ist bei dir sogar der Übergang ins Heimnetz.
Dass Smart Lock Go und Fenstergriff nicht als Batteriegeräte erkannt wurden, lag daran, dass sich das Modul allein auf die Ansage der Geräte verließ — und die fehlt bei genau diesen dreien. Künftig nimmt es dafür die Batteriewerte, die Symcon für ein Gerät führt; dann steht das Batteriezeichen auch bei einem stillen Gerät.
Was die fehlende Ansage bedeutet, sagt der Befund bisher nicht deutlich genug, das habe ich ergänzt: Eine bestehende Verbindung läuft weiter, dafür braucht es die Ansage nicht. Sie ist aber der Weg, auf dem Symcon ein Gerät wiederfindet — nach dem nächsten Neustart von Symcon oder sobald das Gerät eine neue Adresse bekommt, fehlt es. Bei einem Batteriegerät kommt die Ansage von selbst zurück, sobald sich das Gerät wieder meldet; ein Gerät am Stromnetz, das sie eingestellt hat, braucht einen Neustart.
Magst du die stille GRILLPLATS einmal vom Strom nehmen und danach die Diagnose wiederholen?
Gibt es einen Unterschied, ob ich die Diagnose manuell starte oder wenn es stündlich vom System erfolgt? Weil ich bei der geplanten Diagnose immer diese Meldung erhalte:
Danke, damit sind beide Beobachtungen einzuordnen.
Der rote Befund im stündlichen Lauf war ein Fehler im Modul: Der Wächter pingt nicht (schlafende Batteriegeräte bleiben in Ruhe) und urteilt allein nach der Routentabelle — und dort übersah er eine kürzere Route, die dein Thread-Netz fdb2:3abb:80f6:2:: abdeckt. Der manuelle Lauf pingt, deshalb war die Meldung danach wieder weg. Seit Beta 0.4 build 36 zählt eine solche Route.
Zur GRILLPLATS: Wenn Werte kommen und du schalten kannst, steht die Verbindung, und die fehlende Ansage ist im Moment ohne Folgen. Warum sie auch nach dem Neustart nicht auftaucht, sehe ich erst, wenn ich weiß, was bei deinem Modul überhaupt ankommt. Build 36 schreibt das ins Debug-Fenster. Magst du nach dem Update das Debug-Fenster der Instanz öffnen, eine Diagnose starten und mir den Inhalt hier einstellen?
Das nützt sehr, danke — der Auszug erklärt beide Punkte, und ich lag mit meiner Vermutung zur Route daneben.
fdb2:3abb:80f6:2:: ist gar kein Thread-Netz: Die Geräte darin (die Shellys mit 192.168.30.x) hängen in einem zweiten Netzsegment, und dein Router spiegelt ihre Ansagen ins Heimnetz. Das Modul hielt den Adressbereich für ein Thread-Netz, weil er nicht am eigenen Netz hängt, und wollte dir eine Route über den Aqara-Hub verkaufen — den Befehl also bitte nicht ausführen. Seit Beta 0.4 build 37 zählt nur noch als Thread-Gerät, was keine IPv4-Adresse hat; der rote Wächter-Befund verschwindet damit.
Zur GRILLPLATS: Von deinen vier Border Routern annonciert allein der Apple TV die Thread-Geräte deines Symcon-Systems, und dort fehlt ihr Eintrag — samt Smart Lock Go und Fenstergriff. Die Aqara-Hubs antworten nur mit ihren eigenen Geräten. Build 37 fragt deshalb jeden Border Router zusätzlich direkt: Vielleicht halten die Aqara-Hubs die Einträge, geben sie auf die allgemeine Anfrage aber nicht heraus. Magst du nach dem Update noch einmal den Debug-Auszug einstellen — die Zeilen „Direktabfrage …" reichen mir?
Danke, das ist eindeutig: Der Apple TV antwortet auch auf die direkte Anfrage, die beiden Aqara-Hubs und der HomePod gar nicht. Einen Eintrag für die stille GRILLPLATS im Symcon-System hat also kein Border Router in deinem Netz — auch nicht auf Nachfrage.
Zu deiner Frage: In der Konfiguration unterscheiden sich die beiden nicht, das zeigt auch dein Screenshot (vier Systeme, Symcon dabei). Der Unterschied liegt beim Border Router: Für die eine führt der Apple TV den Eintrag für Symcons System, für die andere nicht. Warum das Gerät ihn dort nicht (mehr) anmeldet, ist von außen nicht zu sehen — und mit weiteren Abfragen komme ich hier nicht weiter.
Was jetzt zählt, ist die Folge, und die lässt sich nur auf einem Weg prüfen: Magst du bei Gelegenheit Symcon neu starten und mir sagen, ob die stille GRILLPLATS danach noch Werte liefert und schaltbar ist? Findet Symcon sie ohne den Eintrag wieder, ist der Hinweis weniger dringend, als ich ihn formuliert habe.
Seit heute liegt Beta 0.5 im Store: Unter den Befunden steht eine Geräteliste mit einer Spalte je System — deine stille GRILLPLATS sollte dort Häkchen bei Apple Home und Home Assistant haben, aber keins bei Symcon. Und genau dieser Fall ist seit build 43 ein eigener Befund („meldet sich für andere Systeme, aber nicht für Symcon"), damit man ihn nicht aus der Tabelle herauslesen muss — er greift ab dem zweiten Lauf, weil das Modul sich den Netzwerknamen des Geräts zuerst merken muss.
Danke für den Auszug, Rainer. Die 20 sind Ansagen, keine Geräte: Jedes Matter-Gerät meldet sich einmal je System, dem es angehört. Bei dir sind es 20 Ansagen von 10 Geräten in 3 Systemen — Symcon mit allen zehn, dazu zwei weitere (vermutlich Aqara Home und die FRITZ!Box), in denen je fünf davon stecken.
Die Beta 0.5 von heute zählt das getrennt aus und zeigt unter den Befunden eine Geräteliste mit einer Spalte je System. Magst du aktualisieren und schauen, ob die Liste zu deinem Konfigurator passt?
Ich habe das Modul aktualisiert und einmal die ganze Symbox neu gestartet.
Der Ikea Plug lässt sich schalten und liefert Werte. Das ist die aktuelle Ausgabe:
das letzte ist auch ein FP300 der über ZigBee an den Aqara Hub angelernt ist.
Was A = anderes System ist kann ich noch nicht ganz nachvollziehen. Ich habe hier nur Symcon, Aqara Hub und die Fritzbox. Die Shellys sind direkt an Symcon angelernt.
Übrigens hat dein Modul mir heute gezeigt, dass die beiden Shelly Power Stips nach dem Update der Fritzbox keine Verbindung hatten und keine Daten mehr geliefert haben. Beide neu gestartet und alles war wieder ok.
Danke, der Neustart-Test ist die wichtigste Rückmeldung bisher — und er widerlegt meine Annahme: Symcon findet das Gerät auch ohne sichtbare Ansage wieder. Mein Befundtext behauptete das Gegenteil; ab build 46 heißt es dort „kann scheitern", mit deinem Fall als Gegenbeispiel.
Die Meldung „konnte nicht getestet werden" ist ein Fehler von mir: Der Lauf hatte sein Zeitbudget aufgebraucht, bevor der Erreichbarkeitstest an der Reihe war. Bei dir kommt einiges zusammen — vier Border Router, und weil Geräte fehlen, läuft zusätzlich eine zweite volle Suchrunde. Ab build 47 sind für den Test in jedem Fall sieben Sekunden reserviert, die Suchrunden werden notfalls gekürzt, und das Debug-Fenster gibt jetzt aus, wie lange jeder Abschnitt gedauert hat.
Magst du nach dem Update noch einmal laufen lassen? Wenn die Meldung bleibt, hilft mir der Debug-Auszug weiter.
A und B sind deine beiden anderen Zentralen — die Ansage enthält nur eine zufällige Kennung, keinen Namen, deshalb buchstabiert das Modul sie durch. Ablesen lässt es sich an der Besetzung: In B stehen genau deine fünf Aqara-Geräte, das ist Aqara Home; in A die Bridge der Fritzbox, die Shellys und der Wall Switch, da bleibt nur die Fritzbox. Trag die Namen im Feld „Systeme benennen" ein, dann heißen die Spalten danach.
Das elfte Gerät hat dieselbe Adresse wie der Aqara Hub M3 — der Hub meldet seine ZigBee-Geräte unter eigenem Namen, aber mit seiner eigenen Adresse an. Das gehört als Hinweis in die Liste, ich baue es ein.
An „Letzte Änderungen" habe ich nichts geändert, der Text wird weiter mit Zeilenumbrüchen geschrieben, und bei mir bricht die Anzeige sie auch um. Magst du bei der Variablen nachsehen, ob in der Darstellung „Mehrere Zeilen" gesetzt ist? Unabhängig davon stelle ich jedem Eintrag ein Aufzählungszeichen voran, dann sind sie auch in einer Zeile getrennt.
— Fenstergriff und Türschloss dürfen lange stumm bleiben, eine Steckdose am Stromnetz sollte sich melden.
