Curious how you found those Apple TV addresses. I only see three addresses on my Thread-enabled Apple TV, the fe80 link-local, and two fdxx “unique local” (non-globally routable) addresses (ULA).
The 2a01:: address space is a “real” globally-routable IPv6 Internet address, likely provided by your ISP and allocated by your router to devices on your LAN. The Matter spec says that if there are no routable addresses on the LAN, then the controller can create a ULA subnet; I guess since your router is handing out global IPs, there was no need for Apple to hand out fdxx addresses.
Either way, none of those is your Thread subnet. Thread border routers are literally just IP routers that pass traffic between different subnets, so Thread has to have a different address range than your WiFi subnet. For example, my primary LAN uses fdc4:: address space, while my Thread devices use fd98:: addresses behind the border routers. On my HA server, I can see this by looking at the IP routing table, which shows five next-hops (all my Border Routers) to get to the fd98:: network:
peter@felix:~$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
fd98:c4e1:4d6e::/64 proto ra metric 1024 expires 1723sec pref medium
nexthop via fe80::8ef:f64:47de:c907 dev vlan.1 weight 1
nexthop via fe80::14ec:f356:bd9b:2df6 dev vlan.1 weight 1
nexthop via fe80::8df:77d1:4e27:3823 dev vlan.1 weight 1
nexthop via fe80::1083:bb8e:87a0:d296 dev vlan.1 weight 1
nexthop via fe80::ad:f719:8883:b087 dev vlan.1 weight 1
fdc4:4aab:e77f:e44c::/64 dev vlan.1 proto ra metric 1024 expires 1789sec pref medium
Thread device IPs are pretty well hidden, however. To view them, you need a mDNS browser such as “Flame” (iOS) or “Discovery” for MacOS, or avahi-browse on linux, and at least one provisioned Matter-over-Thread device online. For example, in the first screenshot below (from the “Discovery” app), you can see my Apple TV has three IPv6 addresses, two on the local fdc4:: subnet, and is a Thread border router (it is advertising _meshcop._udp service). But none of these IPs is the Thread subnet. Update: on second look, the last address ends in “fd98:c4e1:4d6e”, which is the beginning of the Thread subnet, which can’t possibly be a coincidence, I will keep a closer eye on this in the future.
In the next screenshot you see the same IPs in the _matter._tcp section has hostname 344851A4BBC2.local — that’s the Apple TV Matter controller. While another Matter device, 0A18B5D4FAD7546D.local, has an IP address starting with fd98:: which suggests it is on the Thread subnet.
Again on HA server, at the command prompt I can ping6 this Thread device and confirm the pings stop succeeding when it’s unplugged. I can also run traceroute6 and see that there is a hop through one of my HomePod border routers to get to the device.
peter@felix:~$ traceroute6 0A18B5D4FAD7546D.local
traceroute to 0A18B5D4FAD7546D.local (fd98:c4e1:4d6e:0:c367:4d65:5e96:5215) from fdc4:4aab:e77f:e44c:b645:6ff:fe5b:9d68, port 33434, from port 59640, 30 hops max, 60 bytes packets
1 Bedroom-HomePod-0499B9786562.local (fdc4:4aab:e77f:e44c:4ad:5f0a:2036:c714) 5.170 ms 6.781 ms 5.718 ms
2 0A18B5D4FAD7546D.local (fd98:c4e1:4d6e:0:c367:4d65:5e96:5215) 1748.502 ms * 1172.088 ms
That said, all this is working on my network and I still cannot share an Apple Home Matter-over-Thread device with HA. The HA Matter Server must be using some alternative routing scheme that ignores the host Linux route table, or there is some other reason why I am getting the same “Incorrect state” error that you are getting. I’m still troubleshooting, so if you have any tips please let me know. I will probably compile a troubleshooting guide once I finally figure out the problem.
