@prohand, du bist weiter als ich in diesem Fall.
Du bist nicht der Einzige mit einer solchen Konfiguration mit mehreren VLANs ![]()
@prohand, du bist weiter als ich in diesem Fall.
Du bist nicht der Einzige mit einer solchen Konfiguration mit mehreren VLANs ![]()
Es handelte sich also tatsächlich um ein Versionsproblem
Kann man auf die nächste Version von Gladys aktualisieren oder nicht?
Ausgezeichnet! In diesem Fall ja, aber es müssen vorher mehr Tests durchgeführt werden, insbesondere muss die Migration von 0.13.0 zu 0.16.8 getestet werden, da das CHANGELOG angibt, dass eine Dateimigration erfolgt und ich sicherstellen möchte, dass bestehende Installationen nicht beschädigt werden ![]()
Könntest du diese Tests durchführen?
Gern, aber wie kann ich diese Tests durchführen?
Da ich keine anderen Matter-Geräte habe ![]()
Ich könnte es mit einer Kopie meiner Datenbank versuchen, aber nicht vor Ende der Woche.
Da ich keine anderen Matter-Geräte habe :denk:
Mit Matterbridge kannst du das machen! Es gibt ein Plugin, das viele virtuelle Geräte erstellt
Ich teste gerade:
Mit der aktuellen stabilen Version kann ich matterbridge verbinden und Geräte hinzufügen:
Ich habe übrigens diese Fehler in den Gladys-Logs:
Nach dem Update auf matter.js 0.16.8 sind die Geräte weiterhin sichtbar:
Ich habe denselben Vorgang wie zuvor durchgeführt, um mein Gerät zu paaren, und jetzt erhalte ich diese Meldung:
Und dies ist nicht mehr in den Einstellungen zu sehen:
Wenn ich zur stabilen Version zurückkehre, habe ich dies in den Einstellungen:
Es muss einen Vorgang geben, den man auf Seiten von matter.js durchführen muss, nehme ich an.
@pierre-gilles Hast du die Details zur Dateimigration und wie man sie durchführt?
Danke
Ich habe übrigens diese Fehler in den Gladys-Logs:
Diese Fehler sind normal, du erhältst Statusmeldungen für Geräte, die du nicht hinzugefügt hast
Aktualisierung mit der Version matter.js 0.16.8, die Geräte sind immer noch sichtbar:
Und sind sie immer noch funktionsfähig? Erhältst du immer noch Werte? Sind sie steuerbar?
Ich habe die gleiche Manipulation wie vorhin durchgeführt, um mein Gerät zu paaren, und jetzt habe ich diese Meldung:
Ah, es gibt anscheinend Code, der korrigiert werden muss. Kannst du mir den Fehlercode kopieren? (nicht nur ein Screenshot)
Wenn ich zur stabilen Version zurückkehre, habe ich dies in den Einstellungen:
Ja, das ist normal, du kannst nicht zurückgehen, die Migration funktioniert nur in eine Richtung (alt → neu)
Bei Gladys ist es genauso, du kannst nicht von einer neuen Version zu einer alten Version wechseln.
Ah, es gibt offensichtlich Code, der korrigiert werden muss. Kannst du mir den Fehlercode kopieren? (nicht nur einen Screenshot)
Hier:
2026-02-09T21:53:23+01:00 <info> matter.pairDevice.js:38 (MatterHandler_pairDevice) Gerät mit den folgenden Optionen kommissionieren: {"commissioning":{"regulatoryLocation":0,"regulatoryCountryCode":"XX","regulatoryLocationType":0},"discovery":{"identifierData":{"shortDiscriminator":7},"discoveryCapabilities":{"ble":false}},"passcode":23138390,"commissioningTimeoutSeconds":90,"commissioningAttempts":4,"commissioningRetryDelayMs":1000}
2026-02-09 21:54:07.067 WARN ClientEventEmitter Event für nicht unterstützten Endpunkt #5 auf matter-controller-data.01@a18a450138dee8d3 empfangen
2026-02-09T21:54:07+01:00 <info> matter.pairDevice.js:42 (MatterHandler_pairDevice) Gerät mit der Node-ID 11640192058443884755 erfolgreich kommissioniert
2026-02-09T21:54:08+0100 <warn> errorMiddleware.js:68 (errorMiddleware) TypeError: device.childEndpoints.map ist keine Funktion
at convertDevice (/src/server/services/matter/lib/matter.getNodes.js:19:48)
at /src/server/services/matter/lib/matter.getNodes.js:53:16
at Array.map (<anonymous>)
at /src/server/services/matter/lib/matter.getNodes.js:52:24
2026-02-09T21:54:08+0100 <warn> errorMiddleware.js:68 (errorMiddleware) TypeError: Eigenschaften von undefined können nicht gelesen werden (Lesevorgang 'get')
at handleDevice (/src/server/services/matter/lib/matter.handleNode.js:29:76)
at /src/server/services/matter/lib/matter.handleNode.js:87:13
at tryCatcher (/src/server/services/matter/node_modules/bluebird/js/release/util.js:16:23)
at Object.gotValue (/src/server/services/matter/node_modules/bluebird/js/release/reduce.js:166:18)
at Object.gotAccum (/src/server/services/matter/node_modules/bluebird/js/release/reduce.js:155:25)
at Object.tryCatcher (/src/server/services/matter/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/src/server/services/matter/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/src/server/services/matter/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromiseCtx (/src/server/services/matter/node_modules/bluebird/js/release/promise.js:641:10)
at _drainQueueStep (/src/server/services/matter/node_modules/bluebird/js/release/async.js:97:12)
at _drainQueue (/src/server/services/matter/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/src/server/services/matter/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues (/src/server/services/matter/node_modules/bluebird/js/release/async.js:15:14)
at processImmediate (node:internal/timers:485:21)
Diese Fehler sind normal, du erhältst Zustände für Geräte, die du nicht hinzugefügt hast
Notiert, danke ![]()
Ja, das ist normal, du kannst nicht zurückgehen, die Migration existiert nur in eine Richtung (alt → neu)
In Gladys ist es genauso, du kannst nicht von einer neuen Version zu einer alten Version wechseln.
Also, was ich sagen wollte, ist, dass in der neuen Version dieses Menü fehlt, im Grunde sind die Matter-Knoten nicht sichtbar, es zeigt mir das in der neuen Version:
Also, was ich sagen wollte, ist, dass in der neuen Version dieses Menü fehlt, kurz gesagt, die Matter-Knoten sind nicht sichtbar, in der neuen Version zeigt es mir das:
Ach Mist!
Nun, angesichts der verschiedenen Punkte ist die Migration nicht so einfach, es gibt Entwicklungsarbeit.
@prohand Denkst du, du kannst das (vielleicht mit Hilfe der KI?) anschauen, oder ist das wirklich außerhalb deiner Kompetenzen?
Das ist ein bisschen außerhalb meines Aufgabenbereichs ![]()
Aber wenn du mir sagst, wo du die Dateimigration gesehen hast, kann ich versuchen, danach zu schauen, denn ich habe diese Information nicht im Changelog gefunden.
Das steht im CHANGELOG, Version 0.16.0: matter.js/CHANGELOG.md at main · matter-js/matter.js · GitHub
« Der Speicherort der Controller-Basisdaten wurde verschoben »:
Sie sagen, dass es automatisch ist, aber ich weiß nicht, wie ich überprüfen soll, ob es richtig gemacht wurde oder nicht ![]()
Es gibt offensichtlich andere Breaking Changes, aber ich habe keine Ahnung, ob das Auswirkungen auf den Code von Gladys hat
Also bestätige ich, dass es komplett außerhalb meiner Kompetenz liegt ![]()
@prohand ich habe herausgefunden, dass die SLZB-MRXU OTBR unterstützen und sie daher eine sehr gute Option sind, um auf Gladys einen OTBR zu vermeiden. Ist das bei dir auch der Fall oder hast du eine ältere Version, die das nicht unterstützt?
Es ist ein Produkt, das nicht benutzerfreundlich ist, aber für mich bedeutet das nicht, dass Gladys zu Therme OTBR integrieren muss.
@pierre-gilles jetzt, wo du eine SMLIGHT hast (ich habe dein Video gesehen
), die als Thread Border Router fungieren kann, hast du vor, ein Video über die Verwendung von Matter mit diesem Gerät zu machen? Du hast ein vollständiges Video für Z2M mit Gladys und eines mit Matter zu machen, könnte ein Pluspunkt sein, besonders mit der Ausbreitung des Protokolls.
Du hast ein vollständiges Video für Z2M mit Gladys und es wäre toll, auch eines mit Matter zu machen, besonders mit der Ausweitung des Protokolls.
Ich werde sicherlich ein Video über Matter machen, ja. Thread ist jedoch ein eigenes Thema. ![]()
Zur Erinnerung: Matter und Thread sind zwei verschiedene Technologien: Matter kann sowohl auf Wi-Fi- oder Ethernet-Geräten als auch auf Thread-Geräten funktionieren. Im Fall von Thread-Geräten erleichtert die Verfügbarkeit eines Thread-Border-Routers für den Heimgebrauch (Apple TV, HomePod, etc.) die Paarung und das Netzwerkmanagement erheblich.
@pierre-gilles jetzt, wo du eine SMLIGHT hast (ich habe dein Video gesehen
), planst du ein Video über die Verwendung von Matter mit diesem Gerät?
Derzeit unterstützt Gladys diese Art von Konfiguration nicht. Außerdem bin ich mir noch nicht sicher, ob ich den Prozess zu 100 % verstehe. ![]()
Der Teil, den ich noch nie getestet habe oder auf dem Forum funktionieren gesehen habe, ist die Paarung eines Thread-Geräts mit einem Thread-Netzwerk. @prohand hatte damals einen POC versucht, aber ohne Erfolg.
Wenn ich es richtig verstehe, verwenden die meisten Thread-Geräte Bluetooth während der Paarung: Sie erkennen einen Controller in der Nähe und tauschen über Bluetooth die notwendigen Informationen aus, um dem Thread-Netzwerk beizutreten.
Für die Bluetooth-Verwaltung sehe ich heute zwei mögliche Ansätze:
Die Bluetooth-Stack der Matter.js-Bibliothek direkt in Gladys implementieren, damit der Mini-PC selbst die Bluetooth-Erkennung und -Paarung durchführt. Das Problem ist, dass eine Bluetooth-Stack in Node.js, in Docker, auf einem unbekannten Betriebssystem und mit unbekannter Hardware ein Cocktail ist, der sehr zufällig funktionieren könnte. Schon allein Bluetooth ist nicht für seine Zuverlässigkeit bekannt, hier kommen noch mehrere zusätzliche Komplexitätsschichten hinzu. ![]()
Die Bluetooth-Komponente in eine Begleit-App für mobile Geräte implementieren, die direkt das native Bluetooth des Telefons nutzt. Dieser Ansatz wäre wahrscheinlich viel robuster, stellt aber ein erhebliches Projekt dar.
Eine weitere Frage, die ich mir stelle, betrifft die Informationen, die zum Beitritt zum Thread-Netzwerk benötigt werden: Was sind das genau, und wie können sie entweder an Gladys oder eine mögliche Begleit-App übermittelt werden?
Es ist wirklich schade, dass Thread in diesem Punkt nicht wie Zigbee funktioniert. Ein einfacher Paarungsmodus auf der Controller-Seite, und die Sache wäre viel einfacher geregelt. ![]()
Ich stimme zu, dass es nicht einfach sein muss. Besonders mit der Vielzahl verschiedener Geräte. Bluetooth wurde gewählt, weil es auf dem Telefon ist und man sich zwischen WLAN, Thread und Bluetooth entscheiden musste. Das ist ein anderes Problem mit Zigbee.
Daher ist die Verwaltung von Matter-Thread-Geräten direkt mit dem SMLIGHT-Dongle, der als Google Home mit Zigbee fungiert, einfach großartig.
Leider finde ich kein Video mit diesem Anwendungsfall. Der MR1U ist wahrscheinlich zu neu.
Ich habe es auch versucht, aber bisher habe ich es nicht geschafft, den OTBR einzurichten. Also habe ich es aufgegeben, ich werde meine Tests wieder aufnehmen, wenn ich Zeit habe.
Das ist nicht dasselbe Problem mit Zigbee.
Es ist dasselbe Problem, aber mit einem anderen Ansatz für die Paarung gelöst.
Wenn du dich mit einem Wi-Fi- oder Zigbee-Netzwerk verbindest, benötigst du keine Drittanbieter-Technologie, um die Verbindung herzustellen. Du kannst dich direkt verbinden, entweder über einen Code (Wi-Fi-Fall) oder über einen Einschlussmechanismus (Zigbee-Fall).
Ich werde meine Tests wieder aufnehmen, wenn ich Zeit habe
Danke!
Ich konzentriere mich derweil auf Matter, ich denke, da habe ich den größten Mehrwert. Es gibt noch Dutzende Gerätetypen, die hinzugefügt werden müssen ![]()
Und im Moment kann man Thread problemlos mit Gladys nutzen, indem man einen externen Thread-Router verwendet, der das Bluetooth-basierte Einschließen selbstständig verwalten kann. Ich habe einen Thread-Bewegungssensor an mein Apple TV angeschlossen und es funktioniert super in Gladys!
Es ist dasselbe Problem, aber mit einem anderen Ansatz für das Pairing gelöst.
Was ich damit sagen will, ist, dass Zigbee die Nachrichten und die Kommunikation sind. Anders als Matter, das mit Wi-Fi, Thread und Bluetooth funktionieren kann. Daher die Entscheidung, Bluetooth für das Pairing zu verwenden.