As the title suggests, I’m trying to use a Nest Wifi as a Thread Border Router to extend my Smartthings network.
My use-case is an outbuilding which is on my wired IP network, but beyond the Zigbee range of ST.
In the outbuilding I have a Nest Wifi Router, and I was hoping that this would allow thread devices in the building to be able to connect to the Smartthings hub back in my home.
When I attempt to add a thread/matter device (in my case an eve energy smart plug), I get to the point in the ST setup where is says “looking for a thread network”. At this point the process waits for a minute or two, and then comes back with a message saying “Something went wrong. Try again later. Error code: 39-402”.
I have tried adding the same device within range of the ST hub (so connecting directly to the thread network of the hub) and it connects and works fine. But I can’t get it to work from the “remote” thread network of the Nest Wifi Router .
The following article from Smartthings support suggests that this should be possible
(see the section entitled “Using a Third Party border router in SmartThings.”. Although this paragraph it is referring to the 2015 hub and mine is a v3, it does specifically talk about the ST hub talking via network to a Thread Border Router).
Has anyone tried this or got it working, or got any suggestions of what I’m doing wrong?
That article is talking about the situation where you have a Thread enabled ST hub, but without support for a TBR. Assuming you have a device that can serve as a TBR, you can add your ST Thread network to that device if the functionality is provided. In that way, Thread devices connected to a ST hub would be accessible via the TBR function of the 3rd party device. If I read your description correctly, you have the opposite situation where you need Thread devices in your out-building that are connected to the Nest router to be manageable by your ST network. To my knowledge, there is no way to add a 3rd party Thread network to a ST TBR.
To further complicate the situation, you have the v3 ST Hub which has a TBR built in. So assuming your Nest Wifi router supports Thread and is a TBR, you have two different Thread networks each with their own TBRs. Unless the Nest router supports merging Thread networks, I don’t think what you are trying to do is feasible. I also don’t believe there is any way in the ST platform to have multiple Thread networks with multiple TBRs be managed by the ST platform. I seem to recall @JDRoberts talking about this situation in another topic, but I can’t seem to find it right now. Perhaps he can provide a little more insight.
Hmmmm… there’s a lot to unpack there, and I don’t think it works quite the way you’ve described. You can definitely have multiple thread border routers from different brands and access them all in your smartthings app and everything should work fine for Matter as long as everybody is on the same Wi-Fi network.
( you’re right that you can’t add a third-party thread border router to your existing smartthings thread network, but you shouldn’t have to. They should be able to all be part of your “matter fabric” with one thread border router able to talk to another via Wi-Fi.)
I think at one point @Automated_House had five or six different thread networks showing up, which is why I tagged him.
I agree that none of the stuff about the hub v2 applies, I just think the whole thing works better than the description you gave might indicate.
But again, it can only work if that thread border router is on the same Wi-Fi branch as your smartthings matter controller. So that’s my first question.
Thinking a little bit more about it, I think each of the hub devices will need to support Thread 1.3 to get multi-TBR support. What’s not clear to me is whether a device enrolled with the Nest controller on its Thread network will be visible and manageable by the ST app since the device is under a different Matter administrative domain. Will the device need to enroll with the ST controller in order to be visible and manageable in the ST app?
From the screenshots I’ve seen, it looks like you would see Thread network info somewhere in the device info for your ST hub. This is from another post that shows multiples in the ST app.
Looks like I was incorrect: the thread networks don’t show up in your smartthings app, just the one from your own hub will. But you should still be OK as long as the other brand’s thread border router is on the same Wi-Fi branch as your matter controller (your SmartThings/Aeotec hub).
So that’s the first question: I couldn’t tell from your original post if everything is on the same Wi-Fi.
If it is, then it’s the same as adding any matter device which was started on another platform.
Add the thread device to the matter commissioner for your Google Wi-Fi.
then you have to get the matter code from it.
Then add it to Smartthings, using that matter code.
Oh, and to clear up one thing from your first post, you are not trying to use “add a third-party border router“ which is the thing you have to do if you have a V2 hub.
Your V3 hub already has a Thread Border router.
What you are trying to do is add a device which was initially commissioned by another platform so that you can use Wi-Fi to bridge to the thread network in your outbuilding.
So that’s part of the “multi admin” feature.
You’re not technically expanding your own thread network. You’re just adding the ability to access devices on the other thread network by sending messages via Wi-Fi to the other thread, border router.
Add the thread device to matter controlled by Google Wi-Fi.
Then use the multi admin feature in Google WiFi to get the code You need to add it to a different platform.
The connection between my SmartThings hub and the Nest Wifi is a wired network, rather than Wifi, but I don’t think that should make a material difference in this case.
What I’m still trying to get my head around is where the hubs/controllers need to sit in this setup. My ST v3 Hub is one, and sits on one of the thread networks (lets say Thread Network 1) where it acts as the TBR for that network. The Nest Wifi sits on Thread Network 2 and acts as a TBR for that network. However Nest Wifi is JUST a TBR, it isn’t a hub/controller in the sense that the ST hub is.
I have heard of other people adding additional hubs/controllers (e.g. more ST hubs, Google Wifi or Nest Wifi-Pro) to their networks so that they have multiple controllers. In this case they are relying on the multi-admin feature of Matter but I’m trying to avoid this if possible and have all the devices registered with ST.
thread and matter are two different things. There are Thread devices that don’t support Matter and Matter devices that don’t use Thread.
AFAIK, SmartThings only supports thread devices that use Matter over Thread, not Thread without Matter.
For example, at the time of this posting there is no way to add a WeMo scene controller (which uses Thread, but not Matter) to a SmartThings setup. And the Nanoleaf thread devices which do not use Matter have to be added through a cloud to cloud integration, not locally via Thread.
When you are looking for information about Thread and SmartThings, look for Matter over Thread articles. The Thread group has what’s technically possible for Thread devices, but matter-only implementations are following a somewhat different set of rules. In particular, how they handle sharing security keys (which is not mandated by the thread group specifications.)
SmartThings has recently added a new feature that will allow you to combine Thread networks established by two different SmartThings Station hubs into one, but so far only that specific model. There have been press releases that indicate additional smartthings hub models will eventually be included in that, but nothing about third-party thread networks.
They also weirdly appear to be requiring that the two stations can communicate directly, not over WiFi or Ethernet. I’m not sure what that’s about.
At the time of this writing, the multi admin feature is how you register thread over matter devices to SmartThings that are out of range of the thread network established by your hub.
I’m not familiar with all the various Google devices. If the one you have is NOT a Matter Controller, you would need to add something in that building which is, like a Google nest, nest mini or even a smartthings station. Because smartthings only wants to talk to thread devices that use matter over thread, so you’re going to have to get the thread devices onboarded with Matter to use them in SmartThings.
Once you’ve done that, as long as smartthings perceives them as being on the same LAN, you’ll be able to use the ones from the other building.
The alternative is to add a second smartthings/Aeotec hub in the second building, but tell smartthings it’s in the same “location“ as the first hub. Then add the Eve plug to that second hub. If you do it that way, you don’t have to use the multi admin feature, and the device will show up in your smartthings app. The main issue is that if you use devices from different hubs in one routine, that routine will run in the smartthings cloud, not locally.
theoretically it shouldn’t matter if the two thread border routers are communicating via ethernet or Wi-Fi, but smartthings has been known to only implement part of a standard many times before, and I just don’t know if ethernet only between the two thread border routers will work instead of Wi-Fi.
@csstup or someone else with multiple hubs may know.
——
TL;DR
your link shows what Thread can do, but SmartThings has chosen to only implement Thread for Matter. At the time of this writing, there’s no way for ST to connect a device using a thread border router from another brand to your ST account except via Matter. So what you envision is theoretically possible with thread without matter, but that feature has not been implemented by SmartThings.
To reach Matter over Thread devices in your second building you will need to add them to a matter controller there, and then use multi admin feature to bring them into your SmartThings account. Or add a SmartThings/Aeotec hub in that building and define it as the same smartthings “Location“ as your original hub and add the device to that. Then it should show up in your smartthings app, and will be usable in Routines. Just be aware that any routine that uses devices connected to different hubs but without Matter will run in the cloud, not local.
So if you want to use matter and keep everything local, you have to use the multi admin feature, which means you need to have a Matter admin in that second building so it’s reachable by the eve plug.
If you don’t want to use the Matter multi admin feature, then you need to add a second smartthings/Aeotec hub in the second building and do it that way.
Sorry, I know all of this seems needlessly complex and confusing. It is. Going back to the article link I posted under the first point, this is an industrywide issue because the new matter specifications left some features up to the different home automation platforms, and they all implemented it in slightly different ways that have turned out all too often to be incompatible with each other. and because smartthings has a long history of only implementing part of a third-party standard and then mixing that in with their own proprietary architecture.
Your hubs are the grey Thread Border Router boxes. That diagram matches my experience with Thread so far. For example, I have an Eve motion sensor and Nanoleaf bulb that are connected to my Home Pod mini thread network. After setting them up in the Apple Home app, I was able to share them and add them to SmartThings via Matter since my HomePod Mini and SmartThings hub are on the same LAN.
Good to know, but you’re using the Matter multi admin feature, right? Commissioning the device to matter through Apple Home, and then adding it to the smartthings app using the Matter code you get from Apple.
You may have missed it, but the OP was hoping that they could just create a larger thread network by mixing thread border routers from different platforms, and not use matter’s multi admin feature.
As far as I know, while it’s technically possible to add the multiple thread networks into one larger mesh under the independent third-party thread standard, that’s not how smartthings has implemented it. Or most home automation platforms. They are almost all relying on matter to get from one thread border router to another when third-party thread border routers are involved.
(I think home assistant may be different and actually allow you to build out a thread fabric without matter. But I’m not sure. This stuff is all so new that people are using different terminology and different descriptions in their community reports and sometimes it’s hard to tell what’s going on. )
yeah, not possible since CSA didn’t work with the Thread group to standardize a away to share Thread network keys Hell, not even SmartThings can combine their Thread networks completely. I have 3 separate Thread networks for my 3 SmartThings hubs.
Thanks so much for all your input everyone.
So if I understand this correctly, my fundamental problems is that although my Nest Wifi is a Thread Border Router, I’ve got no way of constructing a Thread Network attached to it. For this I need a Matter Controller which is part of that Thread network.
If I replace my Nest Wifi with a Nest Wifi Pro, which is also a Matter Controller, I should be able to create a second Thread network around it.
I can then use the multi-admin abilities of Matter to make those two networks talk to each other.
If it’s easier or less expensive for you, you should also be able to add any matter controller to your existing nest WiFi and do it that way. Like a nest mini or a SmartThings Station.
If you shop around, The nest mini is available under $40 on some Black Friday deals right now.
Not to necro/bump the thread (no pun intended) but I don’t think it’s an industry-wide problem. It’s just Samsung. I have one thread network with Home Assistant, Apple Hub, and Google’s Nest Hub all together.
And about 3-4 Separate Samsung networks because Multi-Hub doesn’t even work for a good chunk of their devices it’s possible in theory to merge it all in one but they’re a bit behind on that front
I did try to set the system up with a single hub and a thread border router on the “remote” network, but smartthings wasnt having any of it. Every time i tried to add a device to the thread network outside of the range of the hub i got error messages from smartthings.
In the end i came to the conclusion that it was eating up way too much of my time and just went for purchasing a second smartthings hub.
I’m not sure whether the inter-hub communication is going via the internet or is local (i havent tested). If it is local then i have achieved most of my original aim. If its via the internet then this is something id like to address at a future date. But life is too short to spend ages on it while the platforms are still developing so much.
It was definitely an industrywide problem at the time that the posts to which you are replying were written. There was much discussion everywhere, including in official matter and thread group meetings. Lots of news articles about it on the technical blogs.
Since that time the thread group has issued new specifications to create a unified method for exchanging security keys, which should help. And most of the major players, including Samsung, have changed the way they handle new thread requests.
Matter is a rapidly evolving standard, and the rollout has been bumpy. And not just for SmartThings.
and because smartthings has a long history of only implementing part of a third-party standard and then mixing that in with their own proprietary architecture. 
Hell, not even SmartThings can combine their Thread networks completely. I have 3 separate Thread networks for my 3 SmartThings hubs.
it’s possible in theory to merge it all in one but they’re a bit behind on that front