@prohand, has avanzado más que yo en este caso.
No eres el único con una configuración de este tipo con varios VLAN 
¡Excelente! En ese caso sí, pero hay que hacer más pruebas antes, especialmente hay que probar la migración de la 0.13.0 a la 0.16.8, porque el CHANGELOG indica que hay una migración de archivos y quiero asegurarme de que no rompa las instalaciones existentes. 
¿Podrías hacer estas pruebas?
Quiero, pero ¿cómo puedo hacer estas pruebas?
Sabiendo que no tengo otros dispositivos Matter 
Podría intentarlo con una copia de mi base de datos, pero no antes de fin de semana.
¡Con Matterbridge puedes hacerlo! Hay un complemento que crea muchos dispositivos virtuales
Estoy probando:
Por lo tanto, con la versión estable actual, puedo conectar matterbridge y agregar dispositivos:
De hecho, tengo estos errores en los registros de Gladys:
Actualización con la versión matter.js 0.16.8, los dispositivos siguen visibles:
Hice la misma manipulación para emparejar mi dispositivo como antes y ahora tengo este mensaje:
Y ya no tengo esto en la vista de configuración:
Cuando vuelvo a la versión estable, me encuentro con esto en la configuración:
Debe haber una manipulación que hacer, supongo del lado de matter.js
@pierre-gilles ¿Tienes los detalles de la migración de archivos y cómo hacerla?
Gracias
Estos errores son normales, recibes estados para dispositivos que no has añadido
¿Y siguen funcionando bien? ¿Sigues recibiendo valores? ¿Son controlables?
Ah, parece que hay código que corregir. ¿Puedes copiarme el código de error? (no solo una captura de pantalla)
Sí, es normal, no puedes volver atrás, la migración solo existe en un sentido (antiguo → nuevo)
En Gladys es igual, no puedes pasar de una nueva versión a una antigua.
Aquí tienes:
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)
Entendido, gracias
Lo que quería decir es que falta este menú en la nueva versión, en resumen los nodos Matter no son visibles, me pone esto en la nueva versión:
¡Vaya!
Bueno, dado los diferentes puntos, la migración no es tan sencilla, hay trabajo de desarrollo.
@prohand ¿Crees que podrías echar un vistazo (con la ayuda de la IA, tal vez?) o realmente está fuera de tus competencias?
Es un poco fuera de mi ámbito 
Pero si me dices dónde has visto la migración de archivos, puedo intentar echar un vistazo, porque no he encontrado esa información en el changelog
Está en el CHANGELOG, versión 0.16.0: matter.js/CHANGELOG.md at main · matter-js/matter.js · GitHub
« La ubicación de almacenamiento de los datos base del controlador se ha movido »:
Dicen que es automático, pero no sé cómo verificar si se ha hecho bien o no 
Hay otros cambios importantes, pero no tengo ni idea si afectan al código de Gladys
Por lo tanto, confirmo que está completamente fuera de mi alcance 
@prohand he descubierto que los SLZB-MRXU admiten OTBR y, por lo tanto, son una muy buena opción para prescindir de un OTBR en Gladys. ¿Es tu caso también o tienes una versión antigua que no lo soporta?
Es un producto que no es muy amigable, pero para mí eso no impide que Gladys a therme deba integrar OTBR.
@pierre-gilles ahora que tienes una SMLIGHT (vi tu vídeo ) que puede hacer Thread Border Router, ¿tienes previsto hacer un vídeo sobre el uso de Matter con este dispositivo? Tienes un vídeo completo para Z2M con Gladys y hacer uno con Matter podría ser un plus, especialmente con la expansión del protocolo.
Seguramente haré un video sobre Matter, sí. Sin embargo, Thread es un tema aparte. 
Para recordarlo, Matter y Thread son dos tecnologías diferentes: Matter puede funcionar tanto en dispositivos Wi-Fi o Ethernet como en dispositivos Thread. En el caso de los dispositivos Thread, tener un Thread Border Router doméstico (Apple TV, HomePod, etc.) simplifica enormemente el emparejamiento y la gestión de la red.
Por el momento, Gladys no soporta este tipo de configuración. De hecho, aún no estoy seguro de entender al 100% cómo se supone que debe funcionar el proceso. 
La parte que aún no he probado ni visto funcionar en el foro es el emparejamiento de un dispositivo Thread con una red Thread. @prohand intentó un POC en su momento, pero sin conseguir que funcionara.
Si entiendo bien, la mayoría de los dispositivos Thread utilizan Bluetooth durante el emparejamiento: detectan un controlador cercano y luego intercambian a través de Bluetooth la información necesaria para unirse a la red Thread.
Para gestionar este paso de Bluetooth, hoy en día veo dos enfoques posibles:
-
Implementar la pila Bluetooth de la librería
Matter.jsdirectamente en Gladys para que el mini-PC realice él mismo el descubrimiento y el emparejamiento por Bluetooth. El problema es que una pila Bluetooth en Node.js, en Docker, en un sistema operativo desconocido y con hardware desconocido, es una combinación que probablemente funcionará de manera muy aleatoria. Ya que el Bluetooth no es conocido por su fiabilidad, aquí añadimos varias capas de complejidad adicionales. -
Implementar la parte de Bluetooth en una aplicación móvil acompañante, que utilizaría directamente el Bluetooth nativo del teléfono. Este enfoque sería probablemente mucho más robusto, pero representa una tarea considerable.
Otra pregunta que me hago es sobre la información que hay que transmitir para unirse a la red Thread: ¿cuál es exactamente y cómo comunicarla, ya sea a Gladys o a una posible aplicación acompañante?
Es una lástima que Thread no funcione como Zigbee en este punto. Un simple modo de emparejamiento en el lado del controlador, y el asunto se resolvería mucho más fácilmente.
Estoy de acuerdo en que no debe ser sencillo. Sobre todo con la gran cantidad de dispositivos diferentes. Se eligió Bluetooth porque es en el teléfono y había que elegir entre WiFi, Thread y Bluetooth. No es el mismo problema con Zigbee.
Por eso, la gestión de los dispositivos Matter Thread directamente con el dongle SMLIGHT que actúa como un Google Home con Zigbee es increíble.
Desafortunadamente, no encuentro ningún vídeo con este caso de uso. El MR1U debe ser demasiado reciente, creo.
Yo también lo intenté, pero por ahora no he logrado implementar OTBR. Así que lo abandoné, retomaré mis pruebas cuando tenga tiempo.
Es el mismo problema, pero resuelto con un enfoque diferente para el emparejamiento.
Cuando te conectas a una red Wi-Fi o Zigbee, no necesitas una tecnología de terceros para establecer la conexión. Puedes conectarte directamente, ya sea mediante un código (caso del Wi-Fi) o mediante un mecanismo de inclusión (caso del Zigbee).
¡Gracias!
De mi parte, sigo enfocado en Matter por el momento, creo que es donde tengo más valor agregado, aún hay docenas de tipos de dispositivos para agregar
Y por el momento, podemos usar Thread con Gladys pasando por un enrutador Thread externo que sepa manejar la inclusión por Bluetooth. Tengo un sensor de movimiento Thread conectado a mi Apple TV y funciona muy bien en Gladys.
Lo que quiero decir es que Zigbee son los mensajes y la comunicación. No como Matter, que puede ser con Wi-Fi, Thread y Bluetooth. Por eso la elección de tomar Bluetooth para el emparejamiento.