Remote OTBR

[wraith mural]

Whats the best way to connect an OpenThread Border Router to Home Assistant if the border router is NOT the same device? My HA server runs inside hyper-v, but my border router is a raspberry pi.

[upper lark]

As long as your network correctly passes ipv6 router announcements and mdns queries/responses, home assistant should automatically discover nearby standard openthread border routers. in some cases, you may have to add a service via the 'open thread border router' integration to manually set the url of the otbr rest api, if you want home assistant to be able to retrieve credentials and configure thread networking on it.

You can double-check some of that on the home assistant haos network config page: https://my.home-assistant.io/redirect/network/ - in the "Network adapter" section it should include an ipv6 address in the prefix announced by your otbr, and under Network discovery > Zeroconf browser it should show an entry for _meshcop._udp.local.

[wraith mural]

Yep, its got both of those. It sees the OTBR instance on the pi, but doesn't seem to be seeing the sensors connected to it.

[cold robin]

I've got similar issues. Both my Home Assistant and Matter Server are running in containers on Talos Linux (Kubernetes). IPv6 RA is setup on that vlan and both HA and MS and each exposes an IP address in that vlan (both ipv4 and ipv6). I can see my google home devices in the ZeroConf browser under _meshcop._udp.local..

I'm running into the issue where I can add Matter devices to HA. It seems to get through the process but then fails at the end.

it gets stuck on Checking Network Connectivity

[jovial cape]

This sounds more like you didn't sync the PAN credentials to your companion app before commissioning the device.

[cold robin]

I've done that a bunch of times, but the result is always the same

[robust verge]

You mentioned the dreaded V word. So - is your phone on that VLAN as well?

[cold robin]

yeah, i switch to that wifi network before attempting to add the device

[robust verge]

It’s the one that gets forgotten so have to triple check

Are you using multus and macvlan to give HA and MS direct access to the vlan or are you doing host network?

And you mention RA, but have you verified ip -6 route from the HA and MS containers (taking care to use the real iproute2 not the busy box fake one). You should see a /48 route with multiple vias, which should match the number of google home devices.

If you see ipv6 addresses in the vias list that aren’t real then you need to make sure forwarding is turned off (iirc for “all”) because it puts your ipv6 stack into a slightly different mode where it won’t detect dead nodes and it will still try to use expired ipv6 addresses.

[cold robin]

yes, I'm using multus with both HA and MS so that they pull ip addresses in that vlan

HA is detecting the multus adapter

MS is also detecting it correctly:

5: net1@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:8c:ae:86:6e:8a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.50.9/24 brd 192.168.50.255 scope global net1
       valid_lft forever preferred_lft forever
    inet6 2601:40:cb81:45c2:a88c:aeff:fe86:6e8a/64 scope global dynamic mngtmpaddr 
       valid_lft 86397sec preferred_lft 86397sec
    inet6 fe80::a88c:aeff:fe86:6e8a/64 scope link 
       valid_lft forever preferred_lft forever

ms is started with the flag --primary-interface=net1

i'm gonna try to verify the route now

I'm guessing the routing isn't working correctly:

home-assistant-0:~$ ip -6 route
2601:40:cb81:45c2::/64 dev net1  metric 256  expires 0sec
fe80::/64 dev eth0  metric 256 
fe80::/64 dev net1  metric 256 
default via fe80::ae8b:a9ff:fe6d:d177 dev net1  metric 1024  expires 0sec

network is unifi, btw

[robust verge]

And the google home devices are on the same vlan as HA and MS?

[cold robin]

Yes

[robust verge]

So they should send out icmp6 packets to the whole vlan, next step probably tcpdump at MS or HA and verify that you see them

Rate varies, but you should see one within 20 mins. And if you set tcpdump to verbose it should be able to decode it enough to see the /48

That’ll tell you if unifi or something is dropping the RAs or if your k8s config is just ignoring them

[cold robin]

I'll have to see if those containers have tcpdump

[robust verge]

I think ha does and if it doesn’t apk can install it

[cold robin]

Gotcha

[robust verge]

You’ve got your net attach def set up with the sysctls?

(I use the tuning cni on top of the macvlan cni to make sure accept_ra_rt_info_max_plen and accept_ra are set for whatever interface the macvlan creates)

[cold robin]

hmm, no, do you have an example config I can look at for that?

here's my fluxcd helm release for ha at the iot vlan annotation: https://github.com/dmfrey/home-gitops/blob/main/kubernetes/homelab-k8s-001/apps/home/home-assistant/app/helmrelease.yaml#L199

and the net-attach-def: https://github.com/dmfrey/home-gitops/blob/main/kubernetes/homelab-k8s-001/apps/network/multus/networks/networkattachment-iot.yaml

[cold robin]

@robust verge Thank you so much, that fixed it! I found I could add the sysctl section to my tuning section. Now when I added the device it ran all the way through and added to HA

I've been messing with this for months now

[robust verge]

Sorry was past midnight here so couldn’t give you an example from my manifests! Glad you got it working. Looks like mine now.