Home Assistant is not able to add matter devices that are in a different VLAN.
HomeKit can do it easily.
So it‘s not a Matter issue. It‘s a restriction from Home Assistant.
Can the Matter developers from Home Assistant please take a look at that?
I have noticed this as well but did not realize the fault was with Home Assistant, I thought it was the matter devices I was using. Look forward to what we can hear back - we should put in a bug request in the matter integration - have you done that?
The matter integration normally use the fe80 network, which exist on all your VLANs, but they are different networks.
The fe80 is non-routable, so no option to get it to another network
HA is missing a lot of IPv6 features and they need to be addressed before the matter integration.
A “Year of IPv6” would be nice!
5 Likes
Bummer! I am sure you are right but that is a confusing statement. Can you provide some links to places where we can ready to better understand?
Basically you need to get mDNS resolution on the alternate segments. Look up mDNS reflector and mDNS repeater.
To make it work you basically need mDNS resolution across vlans and a non fe80 network
First off, in general, Matter relies on mDNS, which by its definition uses link-local multicast. Link-local multicast is not designed to traverse network segements. Furthermore, Matter relies on IPv6, and at least Matter devices which use WiFi/Ethernet often use IPv6 link-local addressing. These addresses are only valid within the same segement. If the mDNS packets announce such addresses, they won’t be routable.
So these facts make operating Matter across multiple VLANs challenging.
Since we are already quite busy getting Matter up and running in general, we currently focus mostly on supporting flat network hierachies. That said, I can try my best…
Can you describe in more detail what happens?
Since HomeKit is also a protocol, I am a bit confused. With HomeKit, you mean you can add Matter devices to Apple Home in the same setup?
We rely on commissioning from Apple + on-network commissioning on our Matter Server (the add-on). When you are using the iOS App flow, we scan the network for mDNS announcements. If they make it to the Home Assistant server, and the IP they resolve to are reachable via routing, then things should work…
How does your configuration look like exactly? Like in which VLAN is your device/Home Assistant/Apple Home devices/your Phone? Are hosts dual-homed or do you use routing?
As said initially, there are some challenges operating Matter that way, and we currently are challenged enough by making Matter along with Thread on flat network hierarchies stable and well supported. So our bandwidth on supporting such setups is really limited currently.
That said, there is a technical write-up about challenges around VLAN and Matter in this Pull request discussion: Adding configurability for primary_interface for python matter-server by thardie · Pull Request #3671 · home-assistant/addons · GitHub. Note that this resolves mainly around a problem with Android and link-local addressing, but it might give some insights too.
Yes, but it must be a smart one at that: It needs to filter out fe80 addresses.
I mean, fe80 addresses are always there, but yeah you need a IPv6 network. If your provider doesn’t hand out a global, make sure you have IPv6 enabled on the router along with a ULA prefix configured.
Typically Thread border routers also publish a ULA prefix, so technically it should be enough to have a Thread border router in your network to get IPv6 addressing…
Alternatively: Dual-Home Home Assistant might be a solution. The Matter Server runs on “host network”, means it has access to all network interfaces of the Home Assistant instance. And the Matter SDK by default uses all network interfaces available for mDNS resolution. So, if you add Home Assistant to both networks, it should work. There is only one caveat: If you use Android for commissioning, it may share a link-local address with the Matter Server. We then have to make a guess on what network that device is 
1 Like
Fe80 will be available on all your interfaces, but it might not be the same fe80 network.
This is just one of the things that are different from IPv4 and you can not translate your IPv4 knowledge to IPv6. It is too different.
1 Like
@agners - First let me say, your work on matter is O.U.T.S.T.A.N.D.I.N.G. - it is very robust and very fast. Kudos and hats off to you and I cannot say that enough!
I have HA Supervised running on a RPI 4b 8Gig with an IP Address of 192.168.0.xx, and all of my iot devices (Shelly relays etc) on 192.168.10.xx. I have for example a Leviton D26HD dimmer that was on the 192.168.10.xx network like all the other iot devices connected to HA, but it was the only matter device. Communications between the vlans is blocked except specifically allowing between each iot device and the RPI (explicit firewall rules and all static IP’s). In any event, HA could add the dimmer to HA, but the dimmer worked perfectly otherwise (manufacturers web based app etc.). I also had turned on mdns transmission across vlans but it still didn’t work. That problem completely disappeared when the dimmer was moved to the same vlan as the RPI running HA. So I have all iot devices on a separate iot vlan (192.168.10.xx) - except for the matter based devices which can only be added to HA on the same (192.168.0.xx) vlan.
If I remember correctly, the dimmer was able to get the certificate from HA even, but the last step of getting it actually added to HA would never succeed. Figuring out that it had to be on the same vlan was pretty painful and only was discovered after much hair pulling, device resets, long long waits, teeth gnashing, reboots, ha restarts, nasty looks from other residents, rechecking firewall rules, more hair pulling, router settings study sessions, and other such brain-numbing, eye crossing muttering to myself about the fact it is only a freaking light switch and blowing my brains out crossed the mind… 
I have to admit though, one bad part of the torture was not because of this, but I destroyed three switches and even an electrician at the hardware store couldn’t understand the switch destruction until I realized some of the ancient light sockets in the chandelier were shorting out so I also rewired the entire chandelier and replaced all of the chandelier light sockets as well…
Hope that helps… !
1 Like
Your talkings about VLANs based on IPv4 networks makes little sense in relation to Matter, because IPv6 is just too different.
Matter is forcing us to learn IPv6 to set it up in anything but the most basic automatic single network mode.
1 Like
My Home Assistant is dual-homed to both my Internet and IoT VLANs and I was able to successfully commission Matter devices to the latter VLAN — which is fully isolated/unrouted — as long as I temporarily switch my iPhone over to the IoT WiFi to perform the commissioning. So yes, at least in terms of one guy’s anecdotal feedback, it should work, at least with iOS commissioning of WiFi devices.
1 Like
It might work for now, but because you have no way of in putting the interface part of the IPv6 address in HA, the Matter server and the Thread Border Router, then it is just a question of when some of the parts will choose the wrong network and break it all.
Thank you! 
I guess that should read “could not add…”?
The mDNS transmission accross VLANs is a bit tricky, especially with IPv6: Since there are link-local addresses (which are not routable), those must get filtered out. Maybe the router which implements this mDNS reflection is doesn’t do that properly?
Matter uses IPv6, you definitly need to make sure that you have ULAs assigned to both networks and that routing inbetween works. If your VLAN reflecton filters out link-local IPv6 addresses, and there are routeable alternatives, then, at least in theory, it should work 
In the end mDNS is designed (according to RFC) to be link local, quote:
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link
Any tool which makes it work accross VLANs takes it off-spec, which may or may not work well 
As reported by others, dual-homing your HA installation might work better, as the mDNS resolver then can just work link-local on the IoT VLAN.
Certificates get installed early during commissioning, if you use Bluetooth, even during Bluetooth connection time. Only the final CASE session build-up uses IP(v6). So this makes sense.
1 Like
Yeah, the Matter protocol is based on IPv6 and designed to run in Home network environments. If you run it in environments not intended (routed networks/VLANs), you need to know a bit about networking to get it running or if you want to be able to debug it
But learning IPv6 is not a bad thing! IMHO, IPv6 is an amazing protocol. It is so much better than IPv4:
- Much more auto configuration (automatically assigned link-local addresses, SLAAC). Things just work, nothing needs to be done.
- No funky ARP protocol. L2 resolution is nicely part of IPv6 (ND)
- Finally gets rid of the address space issue, along with automatic network assigned etc (prefix-delegations)
- Built-in mobile IP
- Native anycast support
Unfortunately, software stacks at times are still a bit buggy, and since it is not available everywhere those features can’t be fully relied on just yet 
Thanks for the confirmation!
Today, by default, the Matter Server add-on (which is the only part which communicates with the devices) has host network access, means access to all networks on the Home Assistant installation. And the Matter Server (or rather the SDK) by default uses all network interfaces to do mDNS resolution.
The mDNS resolver does know from which interface a mDNS response comes, so it implicitly knows the interface part of (link-local) IPv6 addresses. A mDNS resolver which “chooses the wrong network” would just be inherently broken.
mDNS is designed to be link-local, and implementations adhere to that fact. So running a single host on two networks, and both networks using mDNS is a supported/known working/proper setup from mDNS perspective.
However, if mDNS packets cross link (network) boundaries it gets tricky: mDNS reflectors which blindly forward mDNS traffic across networks break the assumption above: If mDNS responses come in from a interface where the device is not really connected to, the system picks the wrong interface when its trying to use a link-local address
Supporting multiple network interfaces is something the Matter Server will keep. We might add a interface selection maybe at one point, but then you should just be able to select the two interfaces and things should continue to work.
That said, there is one situation where your environment is tricky: Using Android as commissioner and the trying to commission a WiFi/Ethernet Matter device - The way the Android App is implemented currently, passes the IPv6 address of the device to be commissioned directly to the Server. If the Android device returns a link-local IPv6 address, we need to scope it (define the interface, or basically, guess the interface 
) on Matter Server side. I’d like to change this, but didn’t come around to look into it more in depth. I’ve just created an issue to track progress on that front: Matter commissioning potentially uses link-local addresses · Issue #4528 · home-assistant/android · GitHub. iOS is not affected as the iOS API never returns an IPv6 address but simply a setup code with discriminator.
4 Likes
Terrific, thank you! I have benen doing this with an android. My wife’s phone is IOS, so if I use her phone to adopt the devices into HA from one VLAN to the other you are impliying that might work for me (if my network is set up properly via mDNS)?
No.
The issue is that HA and probably also the Matter server and the Thread Border Router lacks basic IPv6 configuration options.
IPv6 can have and probably will have multiple IPv6 addresses, like a fe80 for configuration of network, fe2 for DNS lookups, a temporary link local address, maybe a DHCP assigned link local address, maybe a DHCP global address, maybe a link local manual/static address, maybe a global manual/static address.
IPv6 is designed so a program can bind to several addresses, so you can have a set of devices that you do not want to communicate with the internet use link local addresses and then have HA use both a link local address to communicate with the devices and a global address to communicate with the internet.
The problem is that I have not found a way to set multiple IPv6 addresses up in HA.
And even if there was a way to do that, then I can not see a solution to use my DHCP-PD assigned addresses over DHCP and at the same time set up my manual/static link local addresses.
With IPv6 it is not either automatic or manual.
It is automatic and/or DHCP and/or manual.
It might have access to all network, but because some networks, like the fe80, which is usually by the Matter/Thread Router, exist on multiple ports without being the same, then it makes no difference, because often the wrong fe80 network is chosen.
Just to be clear, I am one of the main developers of the Matter add-on, and the main developer of the OTBR add-on. What features are you talking about!?
Both add-ons run on host network. The IPv6 configuration is simply whatever the host network configuration is (OS network configuration, in HAOS setup by NetworkManager under the hood, but configurable through Settings → System → Network).
The Matter Server add-on can handle multiple interfaces just fine, that is how the Matter SDK is designed.
Currently, the OpenThread Border Router add-on uses the primary interface by default as backbone network interface. That is something which would be a nice extensions indeed, and there are PRs/discussions in the add-on repository about that.
Not sure if it’s the same problem: I’ve HA in a VLAN and the other devices in a different one. HA can access the devices VLAN.
In this VLAN I’ve the AppleTV4 and a Eve motion, working just fine in HomeKit.
I’ve installed Thread integration in HA and added the AppleTV router as preferred network, but HA cannot discover the Eve motion device.
Is the same problem?