Matter/Thread - ZBT-1 Unable to Add Accessory, Pairing Failed

[sleek quest]

I am setting up matter and thread for the first time. I have two matter/thread devices, an Eve energy plug and a Leviosa blind. I am not able to get either device to pair with HA. I am looking for help with troubleshooting.

I am new to HA. I have a couple of thermostats and a doorbell/camera synced to HA over wifi, and that is pretty much all I have done so far. I am running HAOS on VMware Workstation 17 Pro which is running on Windows 11 Pro. HAOS is 16.2 and Core is 2025.10.4. I have a HA Connect ZBT-1 (purchased after the recall) plugged in with the provided extension cable and the port is passed through to the HA VM. Using the directions here, I added the ZBT-1 to HA and selected the thread firmware.

Following directions here, I made sure the ha thread network is my preferred network and then, from the companion app on my iphone, I shared the credentials with my phone.

Following directions here, I added the Matter integration, then from the companion app, I tried to add the matter devices. In both cases, I scan the QR code on the device, the app then shows that it is setting up the blind/outlet, and then after a few minutes, I get the message Unable to Add Accessory, Pairing Failed.

I have tried removing the ZBT-1, Matter, Thread and OTBR integrations and setting them up again from scratch, but I still get the same error at the end.

My phone and desktop are both connected to the same 2.4 GHz wifi network. IPv6 is enabled on the router.

The Matter addon logs start with this:

 Add-on: Matter Server
 Matter WebSocket Server for Home Assistant Matter support.
-----------------------------------------------------------
 Add-on version: 8.1.1
 You are running the latest version of this add-on.
 System: Home Assistant OS 16.2  (amd64 / qemux86-64)
 Home Assistant Core: 2025.10.4
 Home Assistant Supervisor: 2025.10.0
-----------------------------------------------------------```

After scanning the QR code I see this log statement in the Matter addon logs, then nothing more:
`2025-11-25 20:15:57.214 (MainThread) DEBUG [matter_server.server.device_controller.mdns] Discovered commissionable Matter node: AsyncServiceInfo(type='_matterc._udp.local.', name='C403CEB49A1307CE._matterc._udp.local.', addresses=[], port=5540, weight=0, priority=0, server='FA87EDA21ADD55D8.local.', properties={b'VP': b'5402+4660', b'SII': b'2800', b'SAI': b'1000', b'T': b'0', b'D': b'2281', b'CM': b'0', b'PH': b'36', b'PI': None}, interface_index=None)`

The OTBR logs are [here](https://pastebin.com/7qMgi6yH).
The commissioning attempt starts at 06:44.

Am I missing clues in the logs?  What should I check next?

[rancid isle]

you can see that by 6:55.747 your device is all set up in thread and ready to be commissioned in matter, and then the flow stops. ready to be commissioned here means that the device's respective services are being advertised via mDNS. looks like the matter server can't see them and goes on waiting.
Maybe something in your network/VM setup is blocking/filtering multicast messages?

[sleek quest]

Does the fact that http://homeassistant.local:8123 works from the browser on my windows machine mean that mDNS is working and is not blocked?

[rancid isle]

Damn, I overlooked your matter server log snippet on my phone the other day. I nearly was about to ask you to check http://homeassistant.local:8123/config/zeroconf and try to identify your device in _matterc._udp.local. but the log snippet clearly states that the matter server was able to to see it, which is good. So my previous assumption is void.

The snippet also tells that your device's commissioning service C403CEB49A1307CE._matterc._udp.local. will be addressable on host FA87EDA21ADD55D8.local. port 5540 and you can verify that in the BR logs as well by searching for the non-fqdn host string literals. Meaning on the thread level all is good and well.

OK, what you can do: while the device is in commissioning state try to IPv6-ping the device host
a) from your windows machine
b) from inside HA (e.g. using the SSH and Web Terminal add-on). Maybe in your setup you can log into the matter server container...

Why: The thread border router maintains separate IPv6 subnets to host the thread devices in. And it casts IPv6 router advertisements (RA) to let network participants in your (W)LAN know which TBRs are responsible for the respective network segments. There is a chance that RA fail to pass the boundaries of your VM.

If pinging from your Windows machine works, it means that the RAs reach your (W)LAN.

[sleek quest]

I tried pinging during commissioning from both the HA terminal addon and from windows.

Are these the right addresses to be pinging? I tried pinging several times during the commissioning process, until the phone app showed that commissioning had failed.

[rancid isle]

You most probably have to mDNS resolve the C403CEB49A1307CE._matterc._udp.local address manually before you can ping it. At least your screen shot doesn't show address resolution as a prerequisite for being able to ping. You would have to use an mDNS browser to do so. The Home Assistant Zeroconf Browser does that for you: http://homeassistant.local:8123/config/zeroconf

So, when your device enters commissioning mode, check the zeroconf browser, look for the service name (C403CEB49A1307CE in your example) and copy the IPv6 address from there to ping your device.

[sleek quest]

Zeroconf browser:

Ping attempts:

[coarse veldt]

hmm. so definitely some issues with router announcements from the thread border router then. it's very strange that the ping doesn't work from the haos system itself, since the otbr addon should have resulted in there being local routes to the thread network (it should create a network interface 'wpan0' that allows the system to talk directly to the thread network).

it's possible that there's some sort of configuration issue with the virtual machine network, I haven't ever used vmware on windows for this sort of thing so I couldn't say what to look for there.

virtual machine "bridged networking" has always been problematic on wifi; if possible, please see if moving the machine hosting the virtual machine to a wired connection helps.

the output of the command ip -6 route on the haos machine might be informative.

[untold kestrel]

It's very difficult to configure the network with VMware on Windows in bridge mode.
I don't recommend this approach. You need to use dedicated hardware if you don't fully understand what you're doing.

[sleek quest]

I have been considering moving to proxmox, but I hear you saying dedicated hardware. Would you expect similar issues with proxmox?

[untold kestrel]

Check supported install here:
https://www.home-assistant.io/installation/