Naive Matter over Thread question

Some background:
I have a SmartThings V2 (2015) for about 7 years now. I have mostly Zigbee lightbulbs (Ikea Tradfri, Hue, etc.), Zigbee sensors and dimmers but have expanded to include Z-Wave thermostats, TRVs, and water heater controllers (I wrote Edge drivers for these).
As my V2 hub does not support Matter over Thread, I have not rushed into Matter over Thread.
As an experiment, I bought an Ikea Bilresa scroll. I have an Echo V4 that can serve as a Thread Border Router.
My question:
Do I pair the Bilresa with my V2 hub using the Echo V4 as a TBR to ‘find’ it, or do I have to pair the Bilresa directly with the Echo V4 and then have the V2 hub discover it there?

yes, you will need to add it to the Echo V4. If ST does not discover it, you will need to share it from the Echo 4 to generate a Matter code. In ST, you would add it as a Matter device and paste in the Matter code when prompted.

… which still requires the ST hub to have Thread functionality. You’re just pairing your Bilresa into two separate Thread networks.

The Alexa system can neither join an existing Thread network, nor does it act as a Matter bridge - which is what you’re looking for, a Matter bridge. This is not the same thing as a border router.

I would comment that I have several Echoflex and also an Eero router and have experimented extensively on pairing through Alexa and then sharing to ST. Never found it very easy going and at worst the devices paired but then went offline.
Now have a 25+ thread device network (incl 14 router devices) which after I bought a Homepod are paired there before sharing, and the difference in the experience is tremendous.
You could argue that then on starting as I had a weaker mesh this was the problem, but anyway I wish you luck.

Ideally yes. SmartThings should detect the TBR. However it may ask you for a password for the Thread network and I don’t know how accessible that is.

So it may be better to pair the Bilresa with Alexa, which should hopefully have all the required credentials. You should then be able to use the multi-admin functionality to add the device to SmartThings. Unless Alexa knows how to work with the SmartThings app this might involve generating a Matter code and using that instead of the one printed on the device when adding to SmartThings.

If that works you then you should have the option of removing the device from Alexa and leaving it paired to SmartThings.

I’ll defer to those who have actually done it though.

No and sorta.

ST can’t “use” the Echo’s thread radio directly, so there is no concept of ST seeing the Echo as a TBR.

What you would do in this case is

  1. add the device to the Echo’s Thread network by adding it as a Matter device via the Alexa app. Its now a real matter device that can be added to any other Matter hub via multi admin.
  2. Inside the Alexa app, go to the device and use the “other assistants and apps” function to “add another”. This will generate the 11 digit code to pair it with another Matter controller.
  3. Inside the ST app, add a matter device, and use the device code function pasting in the code from Alexa. It doesn’t “discover” it, you have to perform the action to add it as a shared device to ST as a secondary Matter controller.

The device itself is now on Alexa’s thread network, its acting as the TBR to add the Matter device to your LAN. ST then can access the device as Matter. ST doesn’t know anything about the thread network or the TBR.

Note that while this does work, Alexa/Echo based Thread networks can be iffy, especially if you have multiple Amazon devices on the same network. Sometimes they create one thread network with multiple TBRs, sometimes they each create their own. Sometimes they just decide to partition and all of a sudden things are out of sync. Amazon echo devices are currently only Thread 1.3 so they are limited that they can’t do credential sharing to join thread networks later. The Echo 4th gen is only Thread 1.1. And WiFi devices in my opinion are never solid TBRs. Ethernet is preferred, at least as primary.

Personally I wouldn’t use Amazon devices as a TBR or the thread network they create, and I went down this road already thinking they were an option.

A ST V3 hub would be a better choice as a TBR honestly. Get a used one, and you can even do a hub swap with your existing V2, not losing anything in the process.

Or people have good success with Apple’s or Google’s products if you’re looking for mass market. The Aqara and Ikea hubs are good TBRs but then you’re in their ecosystem too. Or you can always roll your own with Home Assistant.

A thread network being managed by 3 echo’s. It’s not currently being used:

If you want to see what Echo TBRs are on your local LAN and what networks they provide, the “Thread Tools” app on Android is perfect to visualize how its setup currently. The alexa app has nothing really to show you what they are doing.

Thanks all for this information. It looks like an Echo V4 is not a great choice for a TBR in the SmartThings world. Matter may well be the future, but it makes Zigbee and Z-Wave seem very straightforward by comparison.

Small confession: In fact, I have already bought a second hand SmartThings V3 (2018) hub and have paired my Bilresa scroll dimmer with it. I just used my Echo V4 as a straw horse for my TBR question (For now I have not migrated my ~80 devices from V2 to V3).
So, you might ask, what problem am I trying to solve? Well, my understanding is that Bilresa routines (on the V3 hub), that control devices on my V2 hub, are not ‘local’ because they cross between hubs.
I guess I should delete the Bilresa from my V3 hub and try to pair it with my V2 hub using the V3 hub as a TBR. If that works, I can check to see if Bilresa routines are local (by temporarily dropping my WAN connection).

Thanks again for all the feedback.

Yep, as you said any routines that use devices that cross hubs will always run in the cloud, so thats not ideal.

Im not sure how ST will handle this if the 2 hubs are part of the same location. It may see that the device ID (the unique mac address/ipv6 address) already exists and not allow you to add it to the second.

To test, you can add it to the V3’s thread network as a new device. Then get the share code from the device inside the V3 to add it to the V2 hub as a Matter device.

If this doesn’t work, you could try moving the V3 to its own location so the two hubs are “isolated”. They’ll still be on the same LAN of course. And then try the test again and that should work.

You know that this is just a couple of clicks in the app? Takes about 5 minutes to migrate everything from one hub to the other. Start the process, wait 5 minutes and done.

He may have reasons why not to do a hub swap just yet. Maybe all needed drivers won’t fit on the reduced ram of the V3 hub. Maybe he’s waiting to mount them both before deciding where they should og.

In the meantime its reasonable (and Im genuinely curious) how well sharing Matter devices between two hubs (same or different locations) can work. :slight_smile:

You can add your thread devices to your v2 hub in 2 different ways using you v3 hub as the TBR.

  1. Add the device to the v3 hub and then share it with the v2 hub via Matter multi Admin. No network key is needed. The problem is you will have duplicate devices. Since you only have 80 devices that is not a big issue.

  2. Add the device directly to your v2 hub, when asked select your v3 hub as the TBR. It will then ask for network key which you can get in the AWA under the Thread section of your v3 hub.

As well as my main production hub, which has multiple TBRs on its thread network, I have a beta hub in the same SmartThings Location. I used to use multi-admin so that certain key devices on my production hub were also available independently on my beta hub in case my production hub went offline (so for example the beta hub could be used to cycle power to the production hub).

It seemed to work fine, though I noticed that when adding a device to the beta hub I was always offered the same device name it already had on the production hub as a default. Then I simulated a failure on my production hub and discovered that the ‘duplicate’ devices on the beta hub were also marked offline in the app even though they should have been completely independent. I don’t know if this issue still exists as I now avoid this situation and use multi-admin to Google as my backup.

As an aside, I don’t think SmartThings has ever offered me a choice of thread networks on a V3 hub. It has always imposed the hub’s own thread network on me whether I want it to or not.

I’ve seen it happen on 2 o 3 ocasions but it never worked. No reason as far as I could see why this happened but a popup said "Allow Smartthings access to your Home (my Apple Thread network) network " or something like that.
Said yes but it timed out without result. Repeated and it paired to the V3 hub.
Another thing is that it always asks me which of my 2 V3 hubs I want to pair to, but they share the same network.

Ahh. You make a very good point. I have my V3 hub on the beta program. If I was fully migrating from my V2 to the V3 I would leave the beta.
I will have a go at using the V3 as a TBR first.
Thanks all!
p.s. I have marked @Paul_Oliver 's reply as a solution. In fact there are several other replies that are also solutions.