Do I need an (Open) Thread border router?

[hearty crag]

I've got a SkyConnect ZBT-1 and two tado X thermostats. All I want is to connect them together locally, via the Thread mesh network and set up a few simple rules via HA. I don't need control via my WLAN nor control from the Internet. Also the Thread devices should not be able to access the Internet.

In this scenario, do I even need a Thread border router? From my naive thinking, I don't want any routing except the automatic mesh networking of Thread.

The ZBT-1 is already on the latest Thread firmware, is plugged into the machine that runs HA inside Docker and detects the ZBT-1 just fine. However, the installation process somehow insists to install a component called "Open Thread border router" and fails: "The OpenThread Border Router addon can only be installed with Home Assistant OS"

What are my options? Can I skip a border router in my scenario, and how? If not, how can I have a border router without having to install an entire OS?

[lilac dew]

the zbt-1 would act as the radio for the thread border router software that would run as an addon inside Home Assistant OS. i think it is a terrible idea to attempt running OBTR outside of an HAOS context.

you can certainly try. there's (intentionally) no documentation for this but in essence, you'd run OTBR as another docker container and have that talk to another container running the Python Matter Server which would then talk to your Home Assistant container

the reason why it is a terrible idea is because Thread networking and Matter uses some parts of IPV6 networking that the stock Linux kernel is bad at and requires some kernel patches that are not applied by default

if you really want to try this you should first read the documentation on the Python Matter Server github https://github.com/home-assistant-libs/python-matter-server

then follow this documentation for running OTBR in docker https://openthread.io/guides/border-router/docker/run

BUT REALLY you should just run HAOS in a VM and not bother with all this shit

A radio does not just do the networking on its own, this is akin to saying that all you need for a functioning WiFi network is an 802.11 radio. The ZBT-1 radio would be controlled by a Thread Border Router which is what actually functions as a network router and control unit, just like a WiFi router is a box with a CPU that controls the 802.11 radio and manages the local network

there is one crazy person who has documented his attempt to do all this within docker and his github post might be helpful to you. i have to stress once more that you should not do this and just run HAOS in a VM https://github.com/orgs/openthread/discussions/10311

[hearty crag]

Thanks a lot for all the links – I will have a look at them and try my luck.

I'm a bit sad that given Thread+Matter is meant as a replacement for Bluetooth- and Zigbee-based IoT protocols, the requirements are pretty high in comparison. Having to maintain an entire OS – virtualized or not – just for a couple of switches, sensors and actors is out of question for me.

[lilac dew]

in practice HAOS is the thing in my home networking life that requires the least amount of maintenence

don't knock it till you try it

the additional complexity of Thread is a feature of the standard. it was appealing to several parties that the mesh networking functionality of Thread was independent of the control layer, unlike Zigbee where they are one and the same. Thread and Matter are often confused for each other but the reality is Matter is merely one control layer that can function over Thread. There's Homekit-over-Thread devices, there's KNX-over-Thread devices, on the market today.

[little rapids]

so what you are saying is, get a Thread radio - ZBT1 or similar - plug it into the HA host and configure the HA OTBR and Thread Integrations? Anything else? (I'm about to pull the trigger on a bunch of Tado-X kit, and have included their TBR - do I need to, though? (although I dont have a Thread radio in HA, yet!))

[kind star]

if your home is very large you will need Thread routers (repeaters?) to extend the range of the network, as battery powered devices don't usually extend the mesh. The tado TBR acts as such a router, but you can also use e.g. eve Energy plugs. Other than this range consideration I see no reason why you'd need multiple TBRs-capable devices.

[little rapids]

I built a TBR. With an SMLIGHT radio, connected it all up, and got it working… but range is an issue. I have got all my TRVs into HA, and working, however the furthest one is joining the matter ‘mesh’ via an Alexa. The Alexa is in its own matter network, not the HA network. By doing so, that TRV cannot get to the Tado servers, presumably because Alexa has not implemented NAT64?

How can I get the Alexa network to ‘join’ the HA one? And use the TBR that has NAT64?

Or is that not possible? If it’s not, can I add a second radio to the OTBR HA Add-On?

[kind star]

Did you intentionally connect it via the Alexa, or did that happen by accident? Merging existing Thread networks is not possible I think, at least I have not seen it been done yet. Some Alexa versions do support proper NAT64, might be worth checking if the firmware is up to date. Including an incomplete TBR into the mesh is potentially risky, as all todays Thread networks I've seen so far only allow a single active TBR, and if that TBR ends up being a limited Alexa instance then all devices are cut off from the cloud. It might be worth not using this Alexa Thread network at all and finding another way. I'm very happy with the aforementioned eve Energy plugs - they're stable, not very expensive, and really only route Thread data within the network and not dabble in the TBR business.

[steady eagle]

Where have you seen that ‘all todays Thread networks so far only allow a single active TBR‘?

This is my Apple Thread network and all 7 TBRs are talking to each other using the TREL protocol.

However… I am the same opinion. Do not use Alexa TBRs. Reset devices that are paired to an Amazon Thread network and re-add it to the Thread network you typically use.

[kind star]

What I mean is multiple TBRs all at the same time providing border router functionality. E.g. a HA with SkyConnect and a tado bridge - only one of them seems to bridge Thread data to the outside world at any single time. But I haven't played with multi-Apple TBR networks yet, quite possible they have some extra tricks or some features implemented that are missing from the tech I've used so far.

(I do not question that TBR-capable devices can all act as simple packet routers within the Thread network at the same time. My statement above was intended to only reference the border router functionality.)

[naive spindle]

with multiple TBRs, traffic going out from the thread network should be routed via the nearest thread border router. But for traffic from outside going in to the thread network, the computers outside will generally pick one of the thread border routers basically at random to use.

This is where TREL steps in - if your thread border routers support TREL, then if one gets a packet for the thread network but knows a different thread border router has a better route, it can forward that packet to the other thread border router.

(TREL also theoretically allows messages from one thread device to a different thread device to go to one TBR, then be forwarded across the non-thread network to the other TBR, to reduce the amount of thread relaying needed)

Note that because of how the linux network stack is set up, if you have HAOS with the OTBR add-on, HA will always use the local OTBR for outgoing thread traffic.

[kind star]

Interesting! I stand corrected. 🙂 Looks like one of the TBR implementations I'm playing with does not support TREL, let's see if that can be changed.

You don't happen to have tried how this all interacts in case you have multiple TBRs and set up a VPN on an Apple TV that's also a TBR? Do all devices in the Thread network then 'route around' the no-longer-working TBR due to TREL?

[naive spindle]

if you have one thread border router in your network which is still in the thread network but can't talk to your lan, then everything just breaks

I've seen some reports of issues when mixing OTBR with apple thread border routers on the same thread network, that might be something that you should avoid regardless of the vpn.

[kind star]

FWIW, looks like TREL support was merged into ESP-IDF only recently and is scheduled for the upcoming 5.4 release, so probably no wonder some TBRs don't support it yet.

I've seen quite a few cases of Apple TV with VPN causing trouble as TBRs, but e.g. HomePod Mini has not been showing up as a troublemaker that much for me. If you have further info or pointers on how such issues looked like together with OTBR I'd be curious to know more. Thanks!