@prohand, tu as plus avancé que moi pour le coup.
Tu n’es pas le seul avec une configuration de ce type avec plusieurs VLAN 
Excellent ! Dans ce cas oui, mais il faut faire plus de tests avant, notamment il faut tester la migration de la 0.13.0 à la 0.16.8, car le CHANGELOG précise qu’il y a une migration de fichiers et je veux m’assurer que ça ne casse pas les installations existantes 
Est-ce que tu pourrais faire ces tests ?
Je veux bien mais comment je peux faire ces tests ?
Sachant que je n’ai pas d’autres appareils matter 
Je pourrais essayer avec une copie de ma base de donnée mais pas avant fin de semaine
Avec Matterbridge tu peux le faire ! Il y a un plugin qui créé plein d’appareils virtuels
Je suis en train de tester :
Donc avec la version stable actuelle j’arrive à joindre matterbridge et à ajouter des appareils :
J’ai d’ailleurs ces erreurs dans les logs Gladys :
Mise à jour avec la version matter.js 0.16.8 les appareils sont toujours visible :
J’ai fais la même manipulation pour appairer mon appareil que tout à l’heure et j’ai ce message maintenant :
Et je n’ai plus ceci dans la vue paramètre :
Quand je reviens sur la version stable je me retrouve avec ceci dans les paramètres :
Il doit y avoir une manipulation à faire je suppose du côté de matter.js
@pierre-gilles As-tu les détails de la migration de fichiers et de comment la faire ?
Merci
Ces erreurs sont normales, tu reçois des états pour des appareils que tu n’as pas ajouté
Et est-ce qu’ils sont bien fonctionnels toujours ? Tu reçois toujours des valeurs ? Ils sont contrôlables ?
Ah, il y a du code à corriger visiblement. Tu peux me copier le code d’erreur ? (pas juste une capture d’écran)
Oui c’est normal, tu ne peux pas revenir en arrière, la migration n’existe que dans un sens (ancien → nouveau)
Dans Gladys c’est pareil, tu ne peux pas passer d’une nouvelle version à une ancienne version.
Voici :
2026-02-09T21:53:23+01:00 <info> matter.pairDevice.js:38 (MatterHandler_pairDevice) Commissioning device with options: {"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 Received event for unsupported endpoint #5 on matter-controller-data.01@a18a450138dee8d3
2026-02-09T21:54:07+01:00 <info> matter.pairDevice.js:42 (MatterHandler_pairDevice) Successfully commissioned device with nodeId 11640192058443884755
2026-02-09T21:54:08+0100 <warn> errorMiddleware.js:68 (errorMiddleware) TypeError: device.childEndpoints.map is not a function
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: Cannot read properties of undefined (reading '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)
C’est noté merci
Alors ce que je voulais dire c’est qu’il manque ce menu dans la nouvelle version, en gros les noeud matter ne sont pas visible, il me met ça sur la nouvelle version :
Ah mince !
Bon, au vu des différents points, la migration n’est pas aussi simple que ça, il y a du travail de développement.
@prohand Tu penses pouvoir regarder (avec l’aide de l’IA peut-être ?) ou c’est vraiment hors de tes compétences ?
C’est un peu hors compétence pour moi 
Mais si tu me dis ou tu as vu la migration de fichiers je peux essayer de regarder car je n’ai pas trouvé dans le changelog cette information
C’est bien dans le CHANGELOG, version 0.16.0 : matter.js/CHANGELOG.md at main · matter-js/matter.js · GitHub
« The storage location of controller base data has moved » :
Ils disent que c’est automatique mais je ne sais pas comment vérifier si c’est bien fait ou pas 
Il y a d’autres breaking visiblement mais aucune idée si cela à un impact dans le code de Gladys
Donc je confirme c’est complétement hors compétence pour moi 
@prohand j’ai découvert que les SLZB-MRXU supportent OTBR et donc ils sont une très bonne option pour s’affranchir d’un OTBR sur Gladys. Est-ce que c’est le cas pour toi aussi ou tu as une ancienne version qui ne le supporte pas ?
C’est un produit qui n’est pas user friendly et pour moi ça n’empêche pas que Gladys à therme devra intégrer OTBR.
@pierre-gilles maintenant que tu as une SMLIGHT (j’ai vu ta vidéo ) qui peut faire Thread Border Router tu as pour projet de faire une vidéo sur l’utilisation de Matter avec cet appareil ? Tu as une vidéo complète pour Z2M avec Gladys et en faire une avec Matter peut être un plus surtout avec l’expansion du protocole.
Je ferai sûrement une vidéo sur Matter, oui. En revanche, Thread est un sujet à part entière. 
Pour rappel, Matter et Thread sont deux technologies différentes : Matter peut fonctionner aussi bien sur des appareils Wi-Fi ou Ethernet que sur des appareils Thread. Dans le cas des appareils Thread, disposer d’un Thread Border Router grand public à la maison (Apple TV, HomePod, etc.) simplifie énormément l’appairage et la gestion du réseau.
Pour l’instant, Gladys ne supporte pas ce type de configuration. D’ailleurs, je ne suis pas encore certain de comprendre à 100 % comment le processus est censé fonctionner. 
La partie que je n’ai encore jamais testée, ni vue fonctionner sur le forum, est l’appairage d’un appareil Thread à un réseau Thread. @prohand avait tenté un POC à l’époque, mais sans parvenir à le faire fonctionner.
Si je comprends bien, la plupart des appareils Thread utilisent le Bluetooth lors de l’appairage : ils détectent un contrôleur à proximité puis échangent via Bluetooth les informations nécessaires pour rejoindre le réseau Thread.
Pour gérer cette étape Bluetooth, je vois aujourd’hui deux approches possibles :
-
Implémenter la stack Bluetooth de la librairie
Matter.jsdirectement dans Gladys afin que le mini-PC réalise lui-même la découverte et l’appairage Bluetooth. Le problème, c’est qu’une stack Bluetooth en Node.js, dans Docker, sur un système d’exploitation inconnu et avec du matériel inconnu, c’est un cocktail qui risque de fonctionner de manière très aléatoire. Déjà que le Bluetooth n’est pas réputé pour sa fiabilité, on ajoute ici plusieurs couches de complexité supplémentaires. -
Implémenter la partie Bluetooth dans une application mobile compagnon, qui utiliserait directement le Bluetooth natif du téléphone. Cette approche serait probablement beaucoup plus robuste, mais représente un chantier conséquent.
L’autre question que je me pose concerne les informations à transmettre pour rejoindre le réseau Thread : quelles sont-elles exactement, et comment les communiquer soit à Gladys, soit à une éventuelle application compagnon ?
C’est quand même dommage que Thread ne fonctionne pas comme Zigbee sur ce point. Un simple mode appairage côté contrôleur, et l’affaire serait réglée beaucoup plus simplement.
Je suis d’accord que ça ne doit pas être simple. Surtout avec la pléthore d’appareil different. Le bluetooth a été choisi car c’est sur téléphone et il fallait bien choisir entre le Wifi, Thread et bluetooth. C’est n’est pas la même problématique avec le Zigbee.
C’est pourquoi la gestion des appareils Matter Thread directement avec le dongle SMLIGHT faisant office d’un Google Home avec Zigbee est une tuerie.
Malheureusement je ne trouve pas de vidéo avec ce cas d’utilisation. Le MR1U doit être trop récent je pense.
J’ai essayé aussi mais je n’ ai pour l’instant pas réussi a mettre l’OTBR en place. Donc j’ai abandonné, je reprendrais mes tests quand j’aurai le temps
C’est la même problématique, mais résolue avec une approche différente pour l’appairage.
Quand tu te connectes à un réseau Wi-Fi ou Zigbee, tu n’as pas besoin d’une technologie tierce pour établir la connexion. Tu peux t’y connecter directement, soit via un code (cas du Wi-Fi), soit via un mécanisme de mise en inclusion (cas du Zigbee).
Merci !
De mon côté, je reste focalisé sur Matter pour l’instant, je pense que c’est là où j’ai le plus de valeur ajoutée, il y a encore des dizaines de types d’appareils à ajouter
Et pour l’instant, on peut tout à fait utiliser Thread avec Gladys en passant par un routeur Thread externe qui sait gérer l’inclusion par Bluetooth lui-même. J’ai un capteur de mouvement Thread connecté à mon Apple TV et ça marche super dans Gladys !
Ce que je veux dire, c’est que Zigbee, c’est les messages et la communication. Pas comme Matter, qui peut être avec le Wi-Fi, Thread et Bluetooth. Donc le choix de prendre le Bluetooth pour l’appairage.