There’s addons which might not be perfect but have available code, then there’s blackbox hardware devices with no source available online. I know which I trust more.
That is like hiring ten one-arm, one-legged, blind men, that you know somewhat, to work in you garden and then be worried they will break in through your security front door, so you want to fence them in in the garden.
Yet at the same you have ten fully able strong men you know nothing about working in your garage/workshop that is connected directly to your house through a flimsy door and not worry about them.
It might be that of the ten disabled men in the garden 80% of them would try to break in if it was risk, but they risk getting caught and going to jail, so only 4% dare to try a bit.
Of the ten able men in the garage only 1% of them wants to break in, but it is pretty risk-free for that 1%, because you have no clue who they are.
If you worry about the ten disabled men, then you should also worry about the 10 able men and move the garage away from the house and into the fenced of area.
1 Like
Are we still talking about home automation, sounds like you have moved into running a private prison? 
I would rather that Matter offered routing, seems like an oversight for a protocol used by so many big players.
Well, you can use other types of IPv6 addresses, if you have a router announcing the config on your network, even global unicast addresses.
The issue with Matter and so many other things is discovery protocols.
Matter use mDNS over IPv6.
I have a fully IPv6 network, guess the discovery is what is hampering me, if I could employ SLAAC or DHCPv6 and treat it as any other client device then this would be much easier.
As it is, even with mDNS forwarding and 2 functioning IPv6 segments I was not able to put HA on one segment and the Matter device on the other. Chromecast is able to work fine with the mDNS forwarding, but Matter does not.
I’m so frustrated with the Matter thermostat that I would rather build my own using a mains relay and ESP32 next time. Currently the Matter device sits on its own dedicated SSID and bridges directly to the HA network, which is exactly the type of lazy home network design that I have been struggling to avoid.
1 Like
Agreed, i would rather not use the matter device than open up security loopholes. As for the analogy of the garden and front door, you have no idea what the person (untrusted Chinese Company) in your garden is doing with when they have access to your wifi in the garden
The analogy was the the one-legged, one-armed blind man was a Matter device.
It is really not much you can do and store on those devices.
And the security front door is your network side of your server that it also have to find a way through. Network servers are pretty hardened today.
On the other hand the fully abled man in the house-connected garage is an integation or addon installed on your HA server.
Al though the HAOS is somewhat tweak to be more slim, it is still a Linux OS with many programs available, including compilers and libraries to built new ones.
And most a vaaaaaaast majority of home networks are flat by adding that to spec they complicate the testing logarithmically and it would probably be another three years for the to release something. I personally will put a well maintained and understood flat network up against any layperson segmented one because I have never looked at a laypersons network with segmentation and not found at least one bad hole they didn’t know was there because they were trying something advanced and did it wrong.
It was designed flat on purpose. Matter wasn’t designed to be run inside a corporate firewall with a multisegmebted routed vlan-d network personality as bad as matter has been I can’t imagine how awful it would be had they tried routing
1 Like
So I’ve bought a Shelly Leak Sensor (Gen4), and it’s my first Matter-over-Wifi device!
My network is also separated in multiple VLAN’s. The relevant ones in this context are:
- VLAN40
- Server VLAN;
- Home Assistant and Matter-add-on is here (also the TBR);
- mDNS is on;
- No Wifi SSID;
- IPV4 range: 192.168.40.0/24
- IPV6 range: fd12:xxxx:xxxa:40::/64 (with SLAAC and RA is on);
- VLAN30
- IoT VLAN;
- My Shelly should be here;
- mDNS is on;
- Wifi SSID “My Wifi - IoT”;
- IPV4 range: 192.168.30.0/24
- IPV6 range: fd12:xxxx:xxxa:30::/64 (with SLAAC and RA is on);
I used the following approach to add it to Home Assistant:
- Temporarily assign the SSID “My Wifi - IoT” to my server VLAN (40). This means that devices that are not connected to my IoT wifi will get an address in the 40-range (instead of 30);
- Connect my iPhone to the IoT Wifi;
- This means all stakeholders (Home Assistant, iPhone and soon Shelly) will be in the same VLAN;
- Add Shelly as a matter device to HA via “add new matter device” in the compagnion app;
- Verify that HA and Shelly are able to communicate (check);
- Add my “My Wifi - IoT” SSID back to my IoT VLAN (30);
- Reboot Shelly - it now has an IPV4 and IPV6 in the 30-range (which is good);
- Communication between Home Assistant and Shelly is lost!
- However:
- When I ping the Shelly matter device from the HA UI, it correctly has identified the new IPV4/IPV6 IP address of the Shelly (in the 30-range). Ping to IPV4 has succeeded, ping to IPV6 has failed;
- I can ping from any other device in the Server-VLAN to the ULA IPV6 of the Shelly;
- In my Unifi Network, I see that Home Assistant has both an ULA and a Link-Local. Same for the Shelly (and also the Proxmox host HA is running on);
- I assumed that once we were passed the discovery phase (hence I had them all in the same VLAN for a moment), and the ULA of the Shelly is known to HA, it would be fine…
So I think my network has been setup fine, but the Matter add-on is not using the IPV6 ULA to communicate to the Shelly device.
For now, I have added the Shelly device to Home Assistant using the Shelly integration itself. That works fine.
You have not understood the routing.
You have mDNS on in both VLANs, but if that is just to allow mDNS and not actually route it, then there are no mDNS connection between the VLANs.
mDNS is not routable with standard IP routing and Matter and many other protocols rely on it as a discovery protocol.
mDNS is indeed not routable, but the real issue is that Matter continues to rely on mDNS and link-local addressing even after commissioning. So even with proper IPv6 ULA routing, cross-VLAN Matter communication remains unreliable in HA today. This is a protocol/runtime limitation, not a routing misconfiguration.
The Matter server an the devices use mDNS to announce their services.
It is a design choice and that you have to accept.
It is true it is not a routing misconfiguration, because the protocol is not meant to be routed.
2 Likes
You’ve discovered precisely why this, and dozens of other topics, recommend either not using vlans, or setting up a dual-homed (Matter) server.
If the LLA is part of the mdns discovery payload, Matter will always use that. I seem to remember investigating this and finding the actual source code where the HA Matter Server chooses the LLA over the ULA. It wasn’t clear whether this was a (Matter) protocol or a HA-specific limitation, but it certainly means routing doesn’t work — by design.
I suspect the reason Thread TBRs can successfully route Matter traffic is because the TBR 1.3 spec mandates mdns reflection to either masquerade the LLA onto the other subnet, or more likely, it strips out any LLAs from the reflection so Matter is forced to use the ULA, but I haven’t investigated further yet. To my knowledge no “normal” reflectors do this. In fact while searching for one, I found an issue to add the feature — note the submitter — but it remains unimplemented.
1 Like
Yes, this is important if you use VLAN’S. Dual-homing your Home Assistant is the simplest way to make Matter pairing work. This is especially true for Leviton switches, which otherwise won’t pair “across a VLAN” for the reasons discussed here.
Until you find out that both your NICs in HA have a link-local address in the FD80 range and your mDNS entry list is filled with those addresses, which is where HA just choose a random NIC that fits the address and tries it and fails at random times, because it chose the wrong NIC that time.
if matter controller have receive list of ip address from mdns why it didn’t exhaust all option until it found one it can connect to ? why fixate on link local ? i thought matter were built for ipv6 network ?
it is - a link local ipv6 network…
oof… but that shouldn’t hinder good practice for software development that use ipv6 tho, whether link local, unique local, or global unique address. Currently i cant find issue regarding unreachable device because of link local preference in python-matter-server repo, so i have hard time believing that matter controller used by HA is not ready for ipv6 because of that issue. Otherwise matter over thread would not be usable from the time since matter exist because by their title they’re a router not a bridge.
Matter is not a router.
Thread Border Router is a router.
IPv6 come with big difference compared to IPv4.
One thing is the ability to have the same subnet ID on several NICs without the physical subnets being the same.
In order to handle those cases IPv6 use an interface ID in the NIC handle, so it can differentiate between the different subnets.
The problem is that services also needs to be aware of the interface NIC to handle multiple NICS and many of the discovery services, like mDNS, are not.
The solution is to run multiple services and bind them to a interface NIC each, but HA do not provide this solution.
Is this problem only exhibit in HAOS install ? can you replicate the issue in docker installation as well ? Also afaik with ULA or GUA there is no need to specify interface id as its guarantee unique within the scope of local network or global network. The problem of routing can also show same symptomps of unable to pair matter device.