Matter Commissioning vs Usage & Understanding

I have been playing around with a couple of Matter (over WiFi) devices just to see and wanted to get a bit of a deeper understanding as to what is going on. Everything I read talks about talks about needing mDNS, IPv6,… but having had a play I am not clear on what is only necessary for commissioning and what is necessary for devices to function.

This is both to understand what is going on at a protocol level and also to think about how this works when you throw Docker, VLANs etc into the mix and then to look at seeing where I can help out.

I believe the Matter server is a gateway between HA and the fabric so needs to be up all the time to allow HA to communicate with the Matter devices. It looks like HA only needs a websocket to communicate with the server but I am less clear how the server communicates with the devices.

Then what is actually necessary once the device has been commissioned. (can you disable IPv6 once commissioned, can you move the server onto a VLAN it can’t get mDNS traffic etc.)

I know the advice is to avoid Docker and VLANs etc. but this is just more understanding what is going on.

Matter requires DNS-SD/mDNS to successfully commission and control devices. Matter also requires IPv6 to communicate between devices. Your ISP or home router does not need to provide any IPv6 configuration, but it must not block IPv6. For devices attached to the same Wi-Fi / Ethernet link, link-local IPv6 is sufficient.

I have matter/thread w/home assistant and apple border routers running on vlans and in docker. Here is what I learned.

  1. Wifi/matter does not need ipv6. Thread/matter needs ipv6.
  2. to work properly (unless you are a network genious that has figure out a bunch of rules), your Thread Border Routers (Apple, OTBR, Google …) need to be in the same vlan as the matter-server. If you are running docker, you run the matter-server as a seperate container and as such you can set it up to be in whatever vlan you have your Thread border router and then HA just talks to it over IPv4 ip address websocket.
  3. you have to have ipv6 setup on your router and not block ipv6 on any vlans that you are establishing thread devices and border routers/matter-server.
  4. when you commission a device, you should put your phone used for commissioning (scan QR code) in same vlan while doing commissioning. This seems to work better. When you don’t sometimes you have to try a couple of times like first try the client gets an IP but you don’t see it becaue you are in another vlan, then next time it reports it ip it has and doesn’t fail …
  5. make sure you wifi network is not clobbering whatever channel your thread border router is using for thread communication.

So my setup is.

Vlans: Client, IOT, IOT Trusted, HA Server, Network equipment, Cameras

  • HA is in HA Serever Alan
  • Matter-Server is in IOT Trusted with my AppleTVs (it is trusted because I need it to have access to the IOT vlan and some things like cameras but don’t want IOT to have access to same stuff.
  • HA talks to Matter-server via it’s IP address and port over IPv4
  • I commission all devices to HA first, then share them if necessary.
  • ipV6 is on in the client, HA Server, IOT Trusted and IOT vlans

I have in the distant past done network admin so I understand most things (or at least used to) but IPv6 is all a bit new to me (hence part of the desire to learn here)

I guess what I was really looking at is a next level down from

what components are sending what messages and using what protocols at each of these stages. So you have the device you want to add, a phone, Matter Server and HA all taking part at various stages and I wanted what they are doing during this. I guess HA is probably the simplest as I presume that at the end of the process once the device has been added to the fabric then the Matter Server then just tells HA about. The other bits are less clear as to what is talking to what and what they are sending.

Then on top of that in general use I presume this is very similar to say Zigbee2MQTT where Z2M takes input from HA and converts that into messages to target endpoints and clusters to control them and convert messages from these endpoints and clusters back into HA. So ultimately HA only talks to the Matter server which talks to the devices and handles responses so you only have HA <-> Matter Server <-> Device and HA doesn’t talk to the devices directly?

I do need to look at IPv6 link local stuff as I can’t quite get me head around that and how that relates to if you do setup local IPv6 with SLAAC

May I ask, what do you mean by this?
I have not seen a definitive case where Matter Server can talk to a Matter device only using IPv4.

I maybe wrong about that. The devices do commission and I could control them but I quickly enabled ipv6 so it probably would have caused issues based on research.

What I have come across with another user is that their HA UI said IPv6 was disabled and they commissioned a Matter/WiFi device, but we found out that HA actually had a IPv6 link-local address anyway even though the UI said IPv6 was disabled.

Yeah, I had IPv6 explicitly turned off and I found out when I started trying to commission thread deviceS.

I’m running a docker HA instance and my raspberry pi running my docker swarm HA cluster didn’t have any ipv6 addresses At the os level

What about your Matter Server?

gonna see if I can tidy up the conversation. I installed matter server (via docker) on my swarm. That is how I was able to commission my first wifi matter device. Without the matter server I could not have commissioned a device. That matter server is in my docker swarm which did not have ipv6 installed initially and I could not commission thread devices. After that I went down the road of getting ipv6 setup so that any devices in my network had ipv6. As an example, my wife had problems with her work vpn because when I turned on ipv6 the vpn tried to use ipv6 and it didn’t work with her company network. So before I enable ipv6 on the network, nothing had ipv6 turned on and I verified that initially by seeing if my raspberry pis running the docker swarm had any ipv6 addresses which they did not.

I’m not 100% what you are trying to figure out, but I did commission a tapo wifi plug without ipv6 and was able to turn it on and off from home assistant, but that didn’t persists long as I started trying to commission thread and got ipv6 setup.

No problem, I’ll try to explain …

The Matter standard says:

“2.1. Overview
Matter aims to build a universal IPv6-based communication protocol for smart home devices.”

and when going through the spec, one will see that IPv6 is a requirement, but there are some tolerances for IPv4, but I can not find anywhere that says an IPv4 only system is supported by Matter.

As a minimum, I would expect that the HA Matter Server’s interface to have an IPv6 address (which for WiFi need only be link-local which are self generated and need not have the home router’s IPv6 enabled, etc), as well as the Matter device needs to have an IPv6 address (which for WiFi can also be only link-local).

But:

and

seems to go against the Matter standard.
This is what I am trying to figure out.
Best Regards.

1 Like

As noted, Matter Specification requires IPv6 support. Matter Certification also ensures IPv6 support. That said, it is possible for devices to support IPv4, but this is vendor-specific and does not ensure interoperability.

You should not try to overcomplicate things. Matter was designed to work plug and play. With ipv6 link-local addressing, and mdns, it basically does that. There are some rules, but it has abosolutely nothing to do with your router:

  • Everything NEED to be in the same layer 2 network. Meaning in one VLAN. IF you want to use other matter fabrics, like apple homekit or google home, not just Home assistant.
  • Your layer2 networking devices should not block ipv6 multicast. That means you switches, and specifically your wifi access points.

If you want to get more technical, i recommend this 3 part blog series: Part 1
I read it all, and that explains everything pretty well.

1 Like