@prohand, you’ve made more progress than I have on this one.
You’re not the only one with a setup like this with multiple VLANs 
Excellent! In that case yes, but we need to run more tests first, notably we need to test the migration from 0.13.0 to 0.16.8, because the CHANGELOG specifies that there is a file migration and I want to make sure it doesn’t break existing installations 
Could you run those tests?
I’d like to, but how can I run these tests?
Given that I don’t have any other Matter devices 
I could try with a copy of my database, but not until the end of the week.
With Matterbridge you can do it! There’s a plugin that creates lots of virtual devices
I am testing:
So with the current stable version I can reach matterbridge and add devices:
I also have these errors in the Gladys logs:
After updating to matter.js version 0.16.8 the devices are still visible:
I did the same procedure to pair my device as before and I now get this message:
And I no longer have this in the settings view:
When I go back to the stable version I end up with this in the settings:
There must be some action to take, I suppose on the matter.js side
@pierre-gilles Do you have the details of the file migration and how to perform it?
Thanks
These errors are normal, you’re receiving states for devices that you haven’t added
And are they still fully functional? Are you still receiving values? Are they controllable?
Ah, there’s code to fix apparently. Can you copy the error code for me? (not just a screenshot)
Yes that’s normal, you can’t go back, the migration only exists in one direction (ancien → nouveau)
In Gladys it’s the same, you can’t go from a new version to an old one.
Here it is:
2026-02-09T21:53:23+01:00 \u003cinfo\u003e 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 \u003cinfo\u003e matter.pairDevice.js:42 (MatterHandler_pairDevice) Successfully commissioned device with nodeId 11640192058443884755
2026-02-09T21:54:08+0100 \u003cwarn\u003e 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 (\u003canonymous\u003e)
at /src/server/services/matter/lib/matter.getNodes.js:52:24
2026-02-09T21:54:08+0100 \u003cwarn\u003e 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)
Noted, thanks
So what I meant is that this menu is missing in the new version — basically the Matter nodes are not visible; it shows this on the new version:
Oh no!
Well, given the various points, the migration isn’t as straightforward as that — there’s development work to be done.
@prohand Do you think you can take a look (maybe with the help of AI?) or is it really beyond your skills?
It’s a bit outside my expertise 
But if you tell me where you saw the file migration I can try to take a look, because I couldn’t find that information in the changelog
It’s indeed in the CHANGELOG, version 0.16.0 : https://github.com/matter-js/matter.js/blob/main/CHANGELOG.md#0160-2026-01-12
« The storage location of controller base data has moved » :
They say it’s automatic but I don’t know how to check if it’s been done properly or not 
There are other breaking changes apparently but no idea if that has any impact on Gladys’ code
So I confirm it’s completely beyond my abilities 
@prohand I discovered that the SLZB-MRXU (SLZB-MRXU) support OTBR and therefore they are a very good option to get rid of an OTBR on Gladys. Is this also the case for you or do you have an older version that does not support it?
It’s a product that is not user-friendly and for me this does not prevent Gladys from having to integrate OTBR.
@pierre-gilles now that you have a SMLIGHT (I saw your video ) which can do Thread Border Router do you plan to make a video about using Matter with this device? You have a complete video for Z2M with Gladys and making one with Matter could be a plus especially with the expansion of the protocol.
I will surely make a video about Matter, yes. However, Thread is a subject in its own right. 
For the record, Matter and Thread are two different technologies: Matter can work just as well on Wi-Fi or Ethernet devices as on Thread devices. In the case of Thread devices, having a consumer Thread Border Router at home (Apple TV, HomePod, etc.) greatly simplifies pairing and network management.
For now, Gladys does not support this type of configuration. Moreover, I am not yet sure I fully understand how the process is supposed to work. 
The part I have never tested, nor seen working on the forum, is pairing a Thread device to a Thread network. @prohand had attempted a POC at the time, but without succeeding.
If I understand correctly, most Thread devices use Bluetooth during pairing: they detect a nearby controller and then exchange via Bluetooth the necessary information to join the Thread network.
To manage this Bluetooth step, I see two possible approaches today:
-
Implementing the Bluetooth stack of the
Matter.jslibrary directly in Gladys so that the mini-PC performs the Bluetooth discovery and pairing itself. The problem is that a Bluetooth stack in Node.js, in Docker, on an unknown operating system and with unknown hardware, is a cocktail that is likely to work very randomly. Bluetooth is not known for its reliability, and here we are adding several additional layers of complexity. -
Implementing the Bluetooth part in a companion mobile app, which would use the phone’s native Bluetooth. This approach would probably be much more robust, but represents a significant undertaking.
The other question I ask myself concerns the information to be transmitted to join the Thread network: what exactly are they, and how to communicate them either to Gladys or to a potential companion app?
It’s a shame that Thread doesn’t work like Zigbee on this point. A simple pairing mode on the controller side, and the matter would be settled much more simply.
I agree that it can’t be easy. Especially with the plethora of different devices. Bluetooth was chosen because it’s on the phone and we had to choose between Wi-Fi, Thread, and Bluetooth. It’s not the same issue with Zigbee.
That’s why managing Matter Thread devices directly with the SMLIGHT dongle, acting as a Google Home with Zigbee, is amazing.
Unfortunately, I can’t find a video with this use case. The MR1U must be too recent, I think.
I tried too but I haven’t been able to set up OTBR so far. So I gave up, I’ll resume my tests when I have time
It’s the same issue, but solved with a different approach for pairing.
When you connect to a Wi-Fi or Zigbee network, you don’t need a third-party technology to establish the connection. You can connect directly, either via a code (in the case of Wi-Fi) or via an inclusion mechanism (in the case of Zigbee).
Thanks!
On my end, I’m staying focused on Matter for now, I think that’s where I can add the most value, there are still dozens of device types to add
And for now, you can absolutely use Thread with Gladys by going through an external Thread router that can handle Bluetooth inclusion itself. I have a Thread motion sensor connected to my Apple TV and it works great in Gladys!
What I mean is that Zigbee is about messages and communication. Not like Matter, which can be with Wi-Fi, Thread, and Bluetooth. So the choice to use Bluetooth for pairing.