Interesting, and yes, I think it’s got google and HA both. I’m not quite sure why it has google, that was automagic I guess, I didn’t tell it to join with google. At least not that I know of.
As to the matter server, before I forget. this is what it logs when it pings:
2025-10-18 15:36:04.608 (MainThread) INFO [matter_server.server.device_controller] <Node:7> The SDK is communicating with the device using fe80::d273:d5ff:fe87:7fdd
I restarted HA and it doesn’t restart the server, so I’m rebooting… (Jeopardy music now playing…)
[15:42:32] INFO: Using 'eth0' as primary network interface.
Of course I suspect it’s in a different docker container, so is that name meaningful when comparing to the HA instance?
But the log shows about a page of stuff like certificate loads, but nothing that looks like any errors.
Ha !! I just tried this again myself and see the same log from Matter Server as you about the SDK communicating using link-local, and the UI shows the ping worked for IPv4, and ULA but it failed for the link-local. So I am now seeing the exact same thing as you.
Sooo… I took a look at the Matter Server code on this (see here) and it is NOT providing the ping command with an interface. I jumped into the matter server container and tried the ping command without providing the interface and it indeed can’t ping the link local, but it can ping link local when the interface is specified. So this is a Matter Server bug.
I seem to recall the python-matter-server add-on has a --primary-interfaceoption which is intended for helping find LLAs that lack “scope”, i.e. a way to know which interface the LLA can be found. I doubt it will make a difference, but I am curious and it might be worth trying before opening a bug report.
If I have identified the ping function correctly (mentioned above) in the Matter Server, the code does not attempt to identify the target address as a link local, and even if it did, it does not have an “interface” parameter to narrow the scope. It would seem to me that this has been a problem for some time, so it is possible I’m missing something, but nevertheless would explain why pinging link locals fails.
It does beg the question what happens for sending control messages, which appear to work… are they going over IPv4? Is it smarter about interface choice for those for some reason?
I really need to set up a packet capture, but HAOS is inside a HyperV VM on Windows and a brief run at that I couldn’t see how to set up a monitor NIC (or I did set it up and got nothing). Hopefully will find some time maybe I can do it at the AP end, never did packet capture on Unifi AP’s, but it’s supposed to be in there.
You may know this already, the Python Matter Server is in the process of being replaced by Matter.JS based matter server. Devs will still entertain bug reporting, but may not get acted on quickly if at all dependent on severity.
Important
We’re excited to share that the Matter Server is being rewritten on top of matter.js! This means that the current project has moved into maintenance mode — we’ll still fix important bugs if they come up, but all new features will land in the new project instead. We’ll post a link as soon as the first alpha version is ready for you to try out.
!! I just tried this again myself and see the same log from Matter Server as you about the SDK communicating using link-local, and the UI shows the ping worked for IPv4, and ULA but it failed for the link-local. So I am now seeing the exact same thing as you.
This means that the current project has moved into maintenance mode — we’ll still fix important bugs if they come up, but all new features will land in the new project instead. We’ll post a link as soon as the first alpha version is ready for you to try out. 