I’d also recommend at least taking a look at a standalone border router based on OTBR such as GL.iNet GL-S20, currently under $50. This is fully compatible with the existing REST API so there is no need for v1.4 credential sharing support.
EDIT: I had an extra esp32-h2 lying around so I setup another OTBR to try this, and it would seem the app-in-the-middle is in fact required to use ePSKc for OTBR to retrieve credentials, it cannot get them directly from another TBR. You can however use OTBR to create an ePSKc for other TBRs to join (via an app).
One example I found is the below article demonstrating the IKEA DRIGERA app which lets you join an existing network using a passcode, or generate a passcode to add a new device (e.g. TBR). Unfortunately I can’t test it because I have enough border routers… But if someone has DRIGERA I would encourage them to try the the ot-ctl ba ephemeralkey PASSCODE command to see if the first command lets the DRIGERA join the OTBR mesh, or conversely, enter the passphrase provided by IKEA into the joiner command to join the IKEA mesh. UPDATE: the joiner command is radio-only so cannot see the mDNS announcements about the ePSKc. (again note that this requires OTBR supporting Thread v1.4 which, as of today, is only the docker version whereas HAOS add-on has a pending CR for support).
Why run the border router in a container under Linux? An Open Thread Border Router will run on and ESP32-S3. Espressive sells OTBRs for $10 each.
For a little more they will sell you an Ethernet daughter card that lets you route Thread to Eithernet
The device needs power. So you also need to add low-power phone charger and USB-C cble
There really is no reason at all to install a Thread radio or Thread USB dongle on you HA server. If the server has Ethernet then it can access your Thread network. If ther BR is Thread/WiFi then the data goes through the BR to your WiFi router, then to Ethernet and then to HA. If the BR is Thread/Ethernet then the data travels more directly.
Here is a link to the device, thery sell for $10, more or less depending on shipping ESP Thread Border Router | OpenThread. Be warned that “some assembly required.”
The Ikea article sheds a little bit of light on this, so thanks for pointing it out. After reading the article and perusing the Thread 1.4 spec, what I believe is happening is the following… perhaps a bit too long to read
I’ll use the article as an example, so let’s say there is an existing Dirigera TBR running an existing Thread network and their is a Dirigera App on a mobile device. For the moment let’s say the mobile device does not have any Thread credentials. The user then purchases a new ABC TBR and with it, they have a companion ABC App on the same mobile device.
To get the ABC TBR to join the existing Dirigera Thread network:
The User uses the Dirigera App and chooses the “Share network Credentials” option.
The Dirigera App then makes a request to the Dirigera TBR to generate an ephemeral key and from the key the Dirigera TBR provides the Dirigera App with a one-time-passcode. Whether the app does this in a proprietary way, or actually makes a Thread compliant DTLS connection to the Dirigera TBR, I don’t know. I did find that the regular meschcop._udp records have a new flag in 1.4 to indicate that the TBR is “ephemeral key capable” so its possible the Dirigera App listens for this and makes a DTLS connection to the Dirigera TBR.
After The Dirigera TBR generates the ePSKc/Passcode, Dirigera TBR puts itself into an “ephemeral key” mode, and then it starts sending out mesh-e._udp advertisements (this is new) which provides connectivity information to reach the Dirigera TBR only for an ePSKc session.
The user gets the OTP from the Dirigera app and copy/pastes the OTP into the ABC app (in the Thread spec this ABC App is called the “Candidate” and in the white paper it is sometime called the “Candidate (application)” ).
From the OTP, the ABC App generates an ePSKc key, and the ABC App then starts listening for these mesh-e advertisements and gets it and with the information from the advertisement it then makes a secure DTLS connection using the ePSKc key.
The Dirigera TBR checks and accepts the connection. The ABC App then requests the credentials and the Dirigera TBR provides them to the ABC App. Afterwards, the connection is torn down and the Dirigera TBR exits the “ephemeral key” mode and stops sending meschcop-e advertisements.
The ABC App stores these credentials within the mobile device (for future IOT device commissioning), and also provides these credentials to the ABC TBR (the Thread spec says this can be done in a vendor specific way), at which point the ABC TBR can now join the Dirigera Thread network.
Yes, this was my take as well, thanks for the clarification. Unfortunately there’s no “ABC App” for HAOS/OTBR to perform this type of join (my hopes doing it via CLI now dashed), and I’m not certain whether the HA app & OTBR even have the underlying infrastructure to put it on the roadmap, so it could be a while. In the mean time you have to “send credentials to HA” then “join preferred network” to get OTBR onto a third-party mesh.
My suspicion is that going in the opposite direction should work — that you can enter CLI commands on OTBR to create an ephemeral key passcode (i.e. without an app) and the IKEA app should be able to accept that code, obtain the credentials, and pass them to Drigera to join the OTBR mesh? I can at least confirm my OTBR does broadcast _mechcop-e._udp advertisements when I enter the ba ephemeralkey start secretkey command, but I don’t have a third-party v1.4-compatible border router to complete the join test.
No telling if/when this will work its way into the HA Thread UI, but this could be a much easier way to get third-party devices to join an existing HAOS/OTBR mesh once their associated apps support the ePSKc UX workflow like IKEA has.
I also have the need to add a second border router as the distance between the devices is high and I would need to add multiple smart plugs to be able to extend the network. But it seems that this is the only way to handle that for now? There are really not other options?!
In principle I could run for some time a second HA instance via docker just for that reason (even this is really not preferred). But not sure how I can setup then the network and also the devices (2 Zemismart Matter over Thread Roller Shade Motors) which I pair would be then on the “wrong” HA instance available. Not sure how to make them then available to my “real” HA instance.
The manufacturers of the border routers are limiting the options.
Open Thread Border Router (OTBR)
Using the REST API and/or the Web GUI, you can theoretically join OTBR to any arbitrary existing mesh if you know the target TLV credentials dataset. This is the only TBR I am aware of with this level of flexibility.
Compatible routers include: HAOS+add-on, OTBR docker container (both with dongle), the esp32 TBR board, or GL.iNet GL-S20.
OTBR does not support itself joining another mesh using v1.4 credential sharing, because the spec requires a mobile app and there is no generic mobile app for OTBR. Maybe the companion app will support this…someday
OTBR does appear to support allowing other devices to join its mesh via v1.4 credential sharing, but only via the CLI and only via the docker container release (not HAOS at the moment). Again maybe a GUI…someday.
Apple and Google TBRs
Thread credentials are stored in their respective platform database (Apple = iCloud keychain, Google = Play Services). Note the databases support multiple entries, but there is no UI to choose which one you want, so try to keep it to one entry.
HA companion apps can “sync” credentials from HA to the phone platform and vice versa.
Reports suggest Apple/Google can join existing HA Thread networks, as long as you have synced creds to your keychain prior to setting up the new device (HomePod / Apple TV / Google Hub) — they can see the network in the database and will (maybe?) use it.
Amazon TBRs
Eero doesn’t appear to let you pick or change credentials, but it does have an option to sync to the platform database (iCloud keychain/Play Services).
Eero allegedly uses OTBR under the hood but I believe the REST API is disabled.
I am unfamiliar with Echo border routers to know what options they provide
Since you cannot join these to another mesh, their credentials de facto become the credentials that all your other TBRs must use on your network.
IKEA TBR
DRIGERA uses OTBR under the hood but disabled the REST API last year.
DRIGERA now supports joining another mesh using v1.4 credential sharing via the IKEA mobile app
SmartThings TBR
SmartThings TBR supports joining another mesh using v1.4 credential sharing via the SmartThings mobile app.
My advice would be to stick with a single vendor, or choose a vendor from the list above that should integrate with whatever you currently have.
I also have the need to add a second border router as the distance between the devices is high and I would need to add multiple smart plugs to be able to extend the network.
I have the same problem. Threads/HA integration is extremely poorly thought out. The network stays flat despite multiple nodes in the network struggling for a good signal and dropping out for hours at a time. Meanwhile the network is like “nah all good”
I think I have the same issue.
I would like to have a Matter device (plug) at location A, reacting on a Matter device (temperature) at location B. The locations are 100 km separated.
On one location a raspberry PI 5 with HA OS is running. There I want to make the logic in and I bought 2 x SLZB-MRW10 (one for each location) to have all Matter devices at the HA available.
Both locations are linked through two fritzboxes running wireguard on it.
But if I try to add a new service to the device Open Thread Border Router it is not working. I am asked for an URL but no matter what I tried it is not working.
And as I am desperate I tried this: http://192.168.1.98:7638 (It takes 10 seconds to deliver Connection failed) http://192.168.1.98:8080 (KI suggestion) (very fast answer with connection failed) http://192.168.1.98:8081 (KI suggestion) (very fast answer with connection failed)
socket://192.168.1.98:7638 (KI suggestion) (very fast answer with connection failed)
socket://192.168.1.98:8080 (KI suggestion) (very fast answer with connection failed)
socket://192.168.1.98:8081 (KI suggestion) (very fast answer with connection failed)
192.168.1.98:7638 (my try) (very fast answer with connection failed)
192.168.1.98:8080 (my try) (very fast answer with connection failed)
192.168.1.98:8081 (my try) (very fast answer with connection failed)
So why is there a button for adding a service if this is not possible?
As far I could understand what’s written here, it is like that, right?
Maybe somebody of you has a different aprouch to get the Matter information from one location to the other. Maybe I am just thinking to complicate about the whole topic.
Many Thanks if anybody can give me a nudge to the right side
As I understand this, you are going over the Internet (100km and Fritzboxes) to reach the remote location (presumably over a VPN).
Connecting an OTBR to an SLZB via tcp/ip is not really recommended due to the delay/jitter, versus directly connected USB/Serial, but many find that tcp/ip works for them because they use it within the home where the delay/jitter is not too bad. However, I would say trying go over the internet just makes the delay/jitter worse, so would not recommend this.
I believe you are referring to the OTBR “Integration”, right? The OTBR Integration wants to talk to an OTBR (AddON/App), and the SLZB is not an TBR, instead its a radio to be used by the OTBR AddON. What HA is not so good at is spinning up second instances of AddOn/Apps so you won’t be able to add a second OTBR/AddOn to your HA.
SLZB-MR4U – Zigbee - Matter over thread
First location Same network - same home assistant
SLZB-06 – Zigbee + SLZB-06 – Matter over Thread -
Second location Same network - same home assistant.
I can run two zigbee networks no problem. It sounds like I can’t for some reason just run another Openthreadborderrouter on the second location with the 06 running Matter over thread??
As far as the internet could tell me what the Layer2 is, I don’t think that I have this. Fritzbox at location one IP is 168.192.1.1 and at the second location is 168.192.2.1. Or how can I find this out?
Thx so far.
I also have read that somebody could install two instances from an Add on in the app store. It was possible because the repository from " Home Assistant Community Apps" can be integrated twice and then you can have a second instance from this App (I don’t remember exactly I think it was Z-Wave or Zigbee, I also tried it to make sure this can work on my system). But as the “OpenThread Border Router” is in the “Official apps” repository which can not be integrated twice I could not make it like that.
Thanks for your advice.
Here I found it with the two add ons, but as I said for OTBR it was not working for me
Yeah, this is not layer2. So there is no way to add a second OTBR in this scenario.
What may be possible to do is to have a second HAOS instance at the remote location that runs both OTBR and Matter Server AddOn. At the local location, I think (but not 100% sure) that you can create a second instance of the Matter “Integration” where you will specify the IP address of the Remote Matter Server AddOn. So in theory you will have one HA Core at the local site that can use Matter/OTBR at the local site and Matter/OTBR at the remote site. You will also need two phone, one to do Matter/Thread commissioning at the local site, and a second phone to do Matter/Thread commissioning at the remote site.
Just for context, your scenario has Ethernet at the first and second site…
Adding a second OTBR AddOn/App instance is do-able, its just not so easy, and maintenance likely will be an issue. Assuming you want to use the SLZB at the second location, the easier thing to do would be to have another HAOS instance running OTBR at the second location. If you are more technical you could instead spin up an OTBR on a Docker container, or even some ESPs. The key to all of this is TREL connecting the first location OTBR to the second location OTBR. AFAIK, TREL works in theory, but I think the jury is still out for how well it actually peforms.
Thanks for this information, very interessting. Seems to be very hard. A second Phone is a problem for me but i will have a try. Many thanks
I just found the thing with remote HA integration. Then i will have two thread meshes which are not directly linked but i can get the entities from two locations in one HA OS.
I think this will make sense to my use case.
The only more HW I need is a second Raspberry Pi
