I tried to create a dedicated matter server by using a raspberry pi but it didn’t go as expected. So, I wanted to know if somebody has an idea.
I tried 2 different approaches:
Installing linux and then the matter server and the openthread border router (both through docker).
Installing full haos with the matter server and border router addon and then exposing the necessary ports (“Show disabled ports” in the config section).
The raspberry pi sits on one vlan (with the matter devices) and my home assistant in a different vlan. Both times I configured the integrations (not the add ons) using websockets.
This seems to work as expected for the matter integration. I can add devices through the companion app, and they are controllable.
For the border router this does not seem to work. If I add the border router to home assistant by providing a URL for the rest api, I get an entry for both the “Open Thread Border Router” and for the “Thread” Integration. The thread integration does show the correct thread network id so the connection seems to be working but it also shows “No border routers were found. Check your border router is configured correctly or reset it to factory settings.”. This results in the integration not working.
Maybe somebody has an idea what went wrong and can help.
Uses multicast DNS (mDNS) to publish mDNS DNS-SD discovery packets on behalf of the thread nodes so they can be discovered on adjacent networks.
Ensure all of your IoT devices and ALL smart hubs/controllers, like Home Assistant, are on the same VLAN. The VLAN can be isolated, with firewalls ports open into the IoT VLAN as needed to access Home Assistant.
It knows you have a TBR, because of the OTBR integration, but if can’t see the mDNS announcements (required for discovery) because they are blocked by the router separating the two servers. This is one case where an mDNS reflector on the router might actually solve your issue (assuming you have ULAs and not just LLAs on the pi vlan).
It’s actually not a requirement that HA “see” the TBR, only that the credentials get synced to the mobile app for commissioning. Another option you might test is direct commissioning via rhe Matter server web console, but that requires setting up a dedicated Bluetooth radio for the matter server container, and keeping the new device within range of the server during setup.
This may be the insight I was missing. I thought manually adding would not require any discovery, because all information would be forwarded from integration to integration.
Did you solve this issue with the mDNS reflection?
I’m planning to do a similar setup to keep the matter-over-wifi devices in the IoT-VLAN while HA stays in its dedicated, different VLAN.
And I have one further question, do you need any additional settings on the open thread border router container in order to communicate with the matter-server? Or does the OTBR communicate directly with homeassistant and does not need a connection to the matter-server?
To clarify, my comment above, mDNS reflecting does not fix Matter-over-WiFi devices across vlans. See my other post explaining why Matter cannot work with vlans/reflectors by design. The HA Matter server must be on the same subnet (vlan) as the devices and TBRs (at least the current implementation). Personally, I use a second network interface on the IoT vlan which has worked fine for years.
The OTBR server (otbr-agent) only communicates with HA, and even that is very limited. The OTBR server and the Matter add-on server never communicate with each other; Matter server just relays information between HA (the Matter Integration, over websockets) and your Matter devices (which, if they are Thread, will be routed through your OTBR — like a router — but not talk to it directly, if that makes sense).
For matter over thread, I did also the “Form thread Network” part.
The matter server works out of the box how I wanted it. You add the integration and point it to the IP address of your matter server and that’s it.
For matter over thread, if you add the integration and point it to the IP address it communicates with the server but after some time shows “no border routers found”. This does not disappear, but it works regardless. The only thing that will not work is transferring credentials. But there is a workaround to that problem.
You can only add devices if they and your matter server have internet. So, I allow full internet access for onboarding and disable it afterwards.
The trick for adding devices via home assistant companion app is:
Your phone needs to be on the same Wi-Fi network as your devices. The Wi-Fi used by the phone is transferred to the devices.
It needs to be able to access your home assistant installation.
Beforehand you need to transfer credentials. Which I did via the app by going to “Companion app” – “Troubleshooting” - “Sync Thread credentials”. This solves the problem of not being able to transfer credentials via integration.
To clarify, my comment above, mDNS reflecting does not fix Matter-over-WiFi devices across vlans. See my other post explaining why Matter cannot work with vlans/reflectors by design. The HA Matter server must be on the same subnet (vlan) as the devices and TBRs (at least the current implementation). Personally, I use a second network interface on the IoT vlan which has worked fine for years.
Thank you for your response! My point about the mDNS reflection was more about using the HA app to pair devices to an external matter server/OTBR, not about fixing the VLAN issues. Thats the reason I was thinking about a dedicated Matter server and OTBR within the IoT-VLAN.
But about your point that Matter cannot work across VLANs by design: I’ve a couple of Shelly devices in my home which can do matter besides the Shelly API for communication to HA. Since these devices are in my IoT-VLAN anyway, I thought why not give it a try and pair some with the Matter server installed on my HA-server (so therefore in a different VLAN). When I have my Phone in the IoT-VLAN, I actually could pair two Shelly plugs via Matter to HA even if they are in a different VLAN than the Matter server. Is this something special about the Shelly devices, or could this be an indicator that it could work?
The OTBR server (otbr-agent) only communicates with HA, and even that is very limited. The OTBR server and the Matter add-on server never communicate with each other; Matter server just relays information between HA (the Matter Integration, over websockets) and your Matter devices (which, if they are Thread, will be routed through your OTBR — like a router — but not talk to it directly, if that makes sense).
This means, if the OTBR stays on the HA machine, the matter-over-thread devices will comunicate with the HA machine. But since they are matter devices, you need the Matter server to talk with them. Meaning in this scenario the signals between the devices in the thread network and reports and commands from homeassistant have to transfer the firewall multiple times since you need the matter server to communicate with them? Therefore, the OTBR should be on the same network as the Matter server. Have I understood that correctly?
Thank you for the details. That is basically the same I wanted to do it, except I propably will use an LXC in the IoT-VLAN for this.
During my research I found this repo on github: GitHub - ownbee/hass-otbr-docker: Stand-alone Home Assistant OpenThread Border Router docker container.
Following the description it basically includes the OTBR implemenation out of HA which includes a couple of quirks and patches for HA. Maybe this could solve your issues with the thread network? I think I will try to host this container alongside with the matter container, maybe it works better than using the official dockerfile.
As network router and firewall I use Unifi. The IoT VLAN is isolated, so access from IoT to HA is restricted. It is only allowed to respond.
Additionally mDNS between VLANs are enabled. Probably what you call mDNS reflecting here.
What caused me the most headache, was a missing route to the Thread network.
The TBR sends an IPv6 Router Advertisement, but the Unifi router did not seem to accept this. The way I fixed it, was to add a route manually.
Currently i have tried it with available docker image that i know but i couldn’t get it to request via dhcpv6-pd… i’ve said that before because i thought OTBR website mention it has dhcpv6 pd for obtaining prefix for thread network. After reading for a while, ive found that dhcpv6 client in otbr by default is being turned off ? and none of dockerfile from docker image i know enable this option when building otbr for their docker image. I still couldn’t find dockerfile for HA addon image tho, so i couldn’t confirm that
…trying to interpret the OTBR dhcp-pd client feature, and it seems to say that DHCP-pd is for requesting prefixes to be used on the Thread network itself, which would mean the Thread devices themselves could be getting GUAs.
Are you wanting the Thread devices to have GUAs?
In my openwrt router, i could filter which available prefix i want to use, so my setup is not dependent on GUA provided by isp (i could specify ula prefix for the router to give). Firewall on the router already block traffic forwarding to internet zone though, we’re strictly talking on vlan setup right ? with isp provided flat network config, no one have choice in what prefix is being provided in their network