There’s two physical switches and one virtual switch between HA and the radio
Thanks for the info 
BTW, Here is a thread, where someone was able to hack a second AddOn instance of ZWaveJS-UI to their system. Maybe will work for OTBR AddOn ???
Oh cool, I was planning on running a second OTBR instance in an LXC container, this would be much more convenient. I’ll give it a try!
I’ve tried forking the original add-on repo and successfully installed a 2nd add-on on Home Assistant, but it didn’t work because OTBR forces port 8081 for the REST API. So, for now, it’s impossible to have 2 instances running on the same server.
I solved the problem by using a standalone Docker image on a VM using Portainer that replicates the HA add-on: GitHub - ownbee/hass-otbr-docker: Stand-alone Home Assistant OpenThread Border Router docker container.
Now I have 2 OTBR integrations:
And two border routers on the same Thread network:
Previously paired devices are working, but now I’m struggling to add a new device to this 2-router setup.
Where can I find this visualisation of my thread network? Is that HA or one of it’s add-ons?
1 Like
I didn’t change the default port, so it should be 8080. But how do I find the correct IP address? Is it the IP address of your HA instance? I don’t find it in my Openthread border add-on settings.
Yes, it’s HA instance IP if you are using the add-on. It defaults to port 8080. Unfortunately, most of the time it displays an incomplete network.
Hmm… I’m getting a connection refused when I go to http://192.168.3.xx:8082.
I use the add-on (not in a separate docker container). Other add-ons that have a web-ui just have a button like this, but this is also missing.
My settings are pretty default:
That usually happens when you are reaching a valid address, but the socket is either not open, or ?perhaps it is already in use by another server for another use?
Maybe try a more random 8xxx port number.
Thanks that worked! I guess many ports already in use on my instance.
And the OpenThread UI is indeed pretty limited.
So is the general consensus that we don’t now and might not ever have multiple TBRs linked via ipv6 over ethernet on the same network?
I really want to get into thread, but without wired backhaul it’s not really doing anything that zigbee cant currently.
my biggest gripe with my zigbee network is the link between devices in my backyard have a weak connect back to the coordinator in the house (everything works, just not ideal LQI). I could setup a second zigbee network with a smlight POE device in my shed, but that has it’s own disadvantages.
I was really hoping with thread we could use IPv6 to expand a single network beyond threads wireless range.
1 Like
You can in theory do what you want to do, that is have a second TBR using Ethernet as a backhaul that is located further away. This scenario uses a Thread networking technology called TREL, but I think the real question is how well does TREL work that it would solve your problem? Your situation may actually be a good test case.
Can someone put some light on this TREL thing compared to Credential Sharing as added by Thread 1.4? Is this basically the same?
In both contexts, putting an Ethernet-based backbone could help to reliably extend a Thread network, if I got it right.
They are separate features:
- TREL (Thread Radio Encapsulation Link aka Thread over Infrastructure) - Thread has the concept of a Thread network, being temporarily “partitioned” into one or more partitions because of communication failures. but allows the nodes within each partition to continue working/networking even though nodes in one partition can’t talk to nodes in another partition. TREL essentially allows Thread nodes in one partition to sorta tunnel across your Ethernet from one TBR to another TBR (i.e. exchange IEEE 802.15.4 packets) to stitch these partitions back together. TREL btw has been out for a few years already.
- Credential Sharing is a feature that allows a user to get access to the Thread credentials that are stored say on a given TBR (say Apple/Google). Once the user has access to these credentials, then they can setup another TBR with the same credentials and thus allow that TBR to join an existing Thread network (otherwise you may end up with each TBR having their own Thread network).
Okay, so to use a second TBR in the sense of a range extender: What is the appropriate function to employ?
I think the Thread 1.4 “credential sharing” concept doesn’t actually give the user access to the full dataset, it just provides a method wherein an ephemeral key is generated and a commissioning window opened so the user can input the key into a second TBR for adding to the mesh. But I’ve only looked into the OTBR implementation; it’s not implemented on many routers yet.
Not really. TREL addresses partitioning, or remote segmentation, and so far its implementations have shown to be problematic so I wouldn’t call it “reliable”. Credential sharing is a UX improvement to add border routers to a mesh which was previously very difficult because every major TBR vendor hid the dataset from the end user, making it almost impossible to combine TBRs from more than one vendor. Also the dataset — unlike a WiFi passphrase — is very long, so the ephemeral key makes the sharing easier on the end user to remember and type. This might technically “extend” the network, but I wouldn’t say it’s as reliable as a basic repeater node because additional border routers introduce additional complexity like routing metrics and path availability for failover, not to mention the aforementioned TREL problems.
If you want to extend your network, add repeater nodes, not border routers. If you have very long / non-diverse paths with multiple hops that risk partitioning, a second TBR might make sense. That said, I have six TBRs because I happened to have them already, but I wouldn’t go intentionally adding more OTBRs due to their maintenance complexity.
Yeah I haven’t looked at the OTBR implementation, so you maybe right … I initially thought as well that it was a way for a TBR to join an existing Thread network but after reading the Thread 1.4 White paper, I read it that credential sharing is a way to get Thread credentials from a TBR so that they can be stored on the mobile device for later commissioning using those credentials. Here are some of the statements in the steps:
- The application assisting the user (called the “Candidate”)
- uses the ePSKc to establish a secure DTLS connection to the Border Router…The Border Router verifies that the correct ePSKc is known by the application and grants access.
- The Candidate (application), now with temporary administrative privileges, can extract the necessary credentials from the existing Thread network, as well as other configuration parameters of the network stored in the Active and Pending Operational Datasets
- Using the Credentials: The extracted credentials can now be securely
stored on key storage on the mobile device running the application – this
is important to make future onboarding of new Thread devices easier.
But if you are saying that the OTBR has a way for itself to be the “Candidate (application)” and thus is a way for it to directly get the Thread creds from another TBR, I would be interested to learn more.
Best Regards!
My recommendation would be to create another HA system that is located remotely and have it only run the OTBR AddOn (w. a Thread USB stick) and have the remoted HA system on the same network as the local HA System (that is already running OTBR AddOn). There are ways to get the Thread credentials off of the local HA OTBR and put them on the remote HA OTBR which will then have both OTBRs running on the same Thread network. TREL is supported in HA’s OTBR (no config required) and this “should” provide a way to connect the two TBRs onto the same Thread network. I say “should” because how well/robust TREL works and how well/robust two TBRs work together is not a well known.