Matter / Thread - Multiple Devices (Eve Energy, Aqara U300) - HomeKit - Can't connect

I’m not sure what I’m missing here…

At some point, I had the Eve Energy working with HA, but it wasn’t working recently so I did some debugging with no luck. I’m not sure how I had it configured before - whether it was via HomeKit or if I had directly connected to it somehow. I factory reset it before recent tests.
I recently got the Aqara U300 and that won’t connect either so I wanted to dig in a bit more.

  1. Right now both devices have been added to Apple Home / HomeKit.
  2. I’m trying to use a pairing code from Apple Home to add to HA.
  3. I can see my Apple Home Thread network in HA and it’s associated border routers (1 Apple TV, 3 HomePods).
  4. I have IPv6 enabled in HA and it has a valid IP.
  5. I have VLANS, and have IPv6 enabled on both the IoT network (where HA resides, and my “main” border router - Apple TV) and default network (where, currently, the other border routers reside until I fix it).
  6. Both VLANs have mDNS enabled.
  7. I have set up very open traffic rules to allow communication between the networks for testing.
  8. I’ve confirmed I can ping devices across the VLANs.
  9. Versions: HAOS 13.2, HA 2024.12.2, Matter Server 6.6.1

Logs:

2024-12-12 10:52:00.323 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning with code using Node ID 26.
2024-12-12 10:52:10.667 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:57007986 on exchange 4771i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-12-12 10:52:13.604 (Dummy-2) CHIP_ERROR [chip.native.SC] PASESession timed out while waiting for a response from the peer. Expected message type was 33
2024-12-12 10:52:30.333 (Dummy-2) CHIP_ERROR [chip.native.CTL] Discovery timed out
2024-12-12 10:52:30.334 (Dummy-2) CHIP_ERROR [chip.native.ZCL] Secure Pairing Failed
2024-12-12 10:52:30.336 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to establish secure session to device: src/controller/python/ChipDeviceController-ScriptDevicePairingDelegate.cpp:89: CHIP Error 0x00000003: Incorrect state
2024-12-12 10:52:30.339 (MainThread) ERROR [matter_server.server.client_handler] [140420776421152] Error while handling: commission_with_code: Commission with code failed for node 26.

Any tips/things I should be testing? Thanks!

You are applying IPv4 logic to an IPv6 setup.
That does not work. You need to study IPv6 to use VLANs and you need to understand the limitations in HA/Matter in regards to IPv6.

HA often use the fe80 network and that exist on all your interfaces, but they are not the same network, so your IPv4 logic fails.

I appreciate the reply, it’s not very actionable though :grimacing:

I agree I was/am using some IPv4 thinking when it doesn’t apply to IPv6 (old habits and all).

You need to study IPv6 to use VLANs and you need to understand the limitations in HA/Matter in regards to IPv6.

HA and the main border router are on the same network, so I’d expect it to work.
I did all the testing I could think of (as documented above) and I don’t know what else to test/look for/change.

The logs seem to indicate an inability to reach… IDK, the border router, or the actual device? I’m not sure.

The logs seems to be from a pairing session and it is important that both the device, the matter server and the commission device (th one providing the Bluetooth connection, like a phone) are on the same network.

I think this is the one of importance, which I believe means that HA Matter Server was waiting to get an IPv6 mDNS-SD from the device (via TBR) and never saw it. mDNS doesn’t cross LAN/VLAN boundries (unless your router has a special mechanism to relay these which often don’t work). So one plausible scenario is that the device was trying to use a TBR that is not on the same LAN/VLAN as HA.

1 Like

With IPv6 you can’t use mDNS reflectors either, because the same networks can exist on multiple NICs without being the same.

1 Like

I had suspected this too, so I was going to eventually try moving the other TBRs over to the correct network (moving HomePods is a bit of a pain to do, that’s why I was delaying this)… So with your note I figured, that’s the next lowest hanging fruit to debug.

And of course, as soon as I did this, it fixed things. So thanks for the push!

Thanks for everyone else commenting as well - I’m still very green in IPv6 :grimacing:, and heck a novice at best with IPv4 too haha.