Aqara p2 sensors - status changes to "unavailable"

Configuration Matter/Thread
, , ,
1

i have two new-ish aqara p2 sensors - one each door/window sensor and motion/light sensor. i was able to add these devices to home assistant quickly - no problems. after a while however, i observe their status is “unavailable”.

last night, i essentially re-added one of the devices (repeated essentially the same process i originally used to add them) and it came back online again for a while but now again status reports as “unavailable”.

system details: i have a fairly new installation running on yellow hardware. i have other matter devices, but only two matter-over-thread devices and they both seem to having this same issue. the other matter-over-wifi devices in my config are working fine. those other devices also happen to be non-sleepy devices. afaik, i am not using the yellow as thread border router (“802.15.4 radio multi protocol support” is unchecked and i’m using the local radio only for zigbee).

in home-assistant>settings>thread>configure, it appears that home-assistant is using the thread network created by my AppleTV. network name is “MyHome30” and it shows my AppleTV device as the border router.

any help/suggestions welcome. i’m particularly interested in what i can do to keep devices available and what actions i can take to fix/diagnose the problem when it happens.

2

Is the device dropping offline after 10 minutes or does it take more time?

The reason I ask is that for battery operated Thread devices our Matter Server asks for a liveness check-in every 10 minutes. So if it already drops offline after 10 minutes, it means that this first liveness check-in fails.

If the device drops out sometime after 10 minutes, at random, then it could be a RF or IP routing issue.

To diagnose: The device page shows the IPv6 address of the device, you can try ping that address (either from the device page directly, which causes a ping from the device the Matter Server add-on is running on, or you can copy the address and try it from a different host. Both can be interesting data points).

Another thing you can check is the Matter Server logs, it might have indication why the device went offline.

How does your setup looks exactly (type of installation etc)?

3

i have HA Yellow hardware. software is up-to-date. my understanding is i am not using the local Thread radio (instead using it for zigbee only). jn my house, I have AppleTV devices (two actually) which I understand to be acting as my Thread border routers. when i look at settings>devices & services>matter, i don’t see anything about my thread network or routing. when i look at settings>devices & services>thread>configure, it shows the name of the local thread network (“MyHome30”) and it sees one border router, which shows with an apple logo and a hostname that corresponds to one of my AppleTV devices.

when the device shows with status “unavailable” and i try pinging the device, i get no response.

looking at the Logbook for the device, i can see that it has shows some occupancy reports ~12 hours ago, then reports it become unavailable an hour ago. so from that, i would assess the pattern does not appear to show it is always going offline after 10 minutes.

4

Update after a few additional days of watching. The device has gone “unavailable”, sometimes for only a few minutes, other times multiple hours. There have been several unavailable periods per day for the last several days.

Btw, i did not mention, but my AppleTV is connected over switched ethernet to network and to my HA server.

Logs seem to show some issues. On inspection, I can see that my two battery-powered matter-over-thread devices are nodes 1 (Aqara P2 motion sensor) and 7 (Aqara P2 door/window sensor). I see numerous “node could not be discovered” messages, but offhand, I don’t know what it means. I’m sharing in case any has any insights.

2024-06-19 10:11:52.675 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:11:52.684 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:12:40.565 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:12:40.571 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:14:24.627 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:14:24.630 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:15:19.757 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:15:19.761 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:19:44.198 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:19:45.166 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:19:45.170 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:20:49.418 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:20:49.423 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:25:42.562 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:25:42.567 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:28:18.458 (Dummy-2) CHIP_ERROR [chip.native.DMG] Subscription Liveness timeout with SubscriptionID = 0x705901cd, Peer = 01:0000000000000007
2024-06-19 10:28:18.459 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 0 ms...
2024-06-19 10:29:28.596 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423387 on exchange 25297i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:29:35.385 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:30:41.889 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423388 on exchange 25298i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:30:52.114 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:30:52.115 (Dummy-2) CHIP_ERROR [chip.native.DMG] Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:560: CHIP Error 0x00000032: Timeout'
2024-06-19 10:30:52.117 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 8939 ms...
2024-06-19 10:31:13.390 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:31:13.391 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:32:12.831 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25300i with Node: <0000000000000007, 1>
2024-06-19 10:32:12.833 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 7312 ms...
2024-06-19 10:32:12.833 (MainThread) INFO [matter_server.server.device_controller] Marked node 7 as unavailable
2024-06-19 10:33:30.882 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423393 on exchange 25301i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:33:39.673 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:35:01.796 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25303i with Node: <0000000000000007, 1>
2024-06-19 10:35:01.797 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 18552 ms...
2024-06-19 10:35:56.974 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25305i with Node: <0000000000000007, 1>
2024-06-19 10:35:56.976 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 14472 ms...
2024-06-19 10:36:47.096 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25307i with Node: <0000000000000007, 1>
2024-06-19 10:36:47.098 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 23343 ms...
2024-06-19 10:39:17.044 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25309i with Node: <0000000000000007, 1>
2024-06-19 10:39:17.046 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 66835 ms...
2024-06-19 10:40:56.374 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25311i with Node: <0000000000000007, 1>
2024-06-19 10:40:56.377 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 57727 ms...
2024-06-19 10:42:59.580 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423404 on exchange 25312i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:43:11.534 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:44:19.188 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423405 on exchange 25313i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:44:28.263 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:44:28.263 (Dummy-2) CHIP_ERROR [chip.native.DMG] Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:560: CHIP Error 0x00000032: Timeout'
2024-06-19 10:44:28.265 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 157440 ms...
2024-06-19 10:48:40.476 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25315i with Node: <0000000000000007, 1>
2024-06-19 10:48:40.478 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 252612 ms...
2024-06-19 10:49:02.816 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:49:02.820 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:49:47.209 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:50:26.101 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:50:26.107 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:51:58.793 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:51:58.799 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:53:07.268 (MainThread) INFO [matter_server.server.device_controller] Node 7 discovered using fallback ping
2024-06-19 10:53:07.269 (MainThread) INFO [matter_server.server.device_controller.node_7] Setting-up node...
2024-06-19 10:53:09.096 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:53:09.106 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:54:11.245 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:54:11.252 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:54:14.622 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423408 on exchange 25316i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:54:24.199 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:55:29.265 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423409 on exchange 25317i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:55:40.925 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:55:40.929 (Dummy-2) CHIP_ERROR [chip.native.DMG] Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:560: CHIP Error 0x00000032: Timeout'
2024-06-19 10:55:40.931 (MainThread) INFO [matter_server.server.device_controller.node_7] Previous subscription failed with Error: 50, re-subscribing in 411755 ms...
2024-06-19 10:55:43.933 (MainThread) INFO [matter_server.server.sdk.node_7] Attempting to establish CASE session... (attempt 2 of 2)
2024-06-19 10:56:48.985 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:216423410 on exchange 25318i with Node: <0000000000000000, 0> sendCount: 4 max retries: 4
2024-06-19 10:57:00.860 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 4
2024-06-19 10:57:43.317 (MainThread) INFO [matter_server.server.device_controller.node_7] Setting up attributes and events subscription.
2024-06-19 10:57:48.658 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:57:48.659 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 10:58:57.472 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 25320i with Node: <0000000000000007, 1>
2024-06-19 11:00:36.449 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:122232369 on exchange 25322i with Node: <0000000000000007, 1> sendCount: 4 max retries: 4
2024-06-19 11:01:03.210 (MainThread) INFO [matter_server.server.device_controller.node_7] Subscription succeeded with report interval [0, 300]
2024-06-19 11:31:06.227 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 12:01:09.234 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 12:14:00.241 (MainThread) INFO [matter_server.server.device_controller.mdns] Node 8 re-discovered on MDNS
2024-06-19 12:14:00.242 (MainThread) INFO [matter_server.server.device_controller.node_8] Setting-up node...
2024-06-19 12:14:00.252 (MainThread) INFO [matter_server.server.device_controller.node_8] Setting up attributes and events subscription.
2024-06-19 12:14:06.634 (MainThread) INFO [matter_server.server.device_controller.node_8] Subscription succeeded with report interval [0, 60]
2024-06-19 12:31:12.243 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 13:01:15.253 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 13:31:18.263 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 14:01:21.270 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 14:31:24.281 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 14:58:32.017 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 14:58:32.020 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
2024-06-19 15:01:27.294 (MainThread) INFO [matter_server.server.device_controller.node_1] Node could not be discovered on the network, returning cached IP's
5

another update. i had a mild suspicion that possibly what i was seeing was caused by weak signal. in other words, that the cause of my two battery-powered matter/thread devices becoming unavailable was that they were simply too far from my appleTV thread border router.

so i purchased a few Onvis-brand matter/thread smart switches. i added one to my network. it paired quickly/easily. i plugged it in half way in between my appleTV and one of my Aqara sensors. i tested it. in short test, it worked well. seemed to have pretty low latency and worked fine.

now a while later, i look and see that the new Onvis smart plug is also sporadically changing to “unavailable” status - at first glance, seemingly following the same pattern as the two Aqara sensors. looking at device history graph, it looks like status was “unavailable” about 40% of the time over the last ~12 hrs with ~10 observed unavailable intervals ranging from about 4 to 70 minutes in duration.

so the gist of this new update is: whatever the problem is… a) it does not appear to be specific to one brand of matter/thread device. b) it does not appear to be specific to sleepy devices. c) it seems pretty unlikely that it is caused by RF signal strength or range issues.

6

I assume pinging works then they are available?

What type of IP addresses are shown when pinging? Is the IP different when available vs. unavailable?

Matter uses mDNS to find the operational devices on the network. It seems that from HA’s perspective, the device sometime disappear from the network entirely.

Hm, or in other words, it seems to be Matter over Thread specific in general.

My best guess here is that somehow the AppleTV and the HA instance don’t communicate with each other at times.

Does unavailable maybe correlate with Apple TV is in use? Do you use HomePods as audio output with this AppleTV device? In the Thread panel you can see the hostname of your AppleTV. Can you ping the device at all times (when things get unavailable too?).

7

pinging works when available? yes. (* see further detail below)

what type of addresses are shown when pinging? not sure exactly what you are asking about w.r.t. “type” of address. they are v6 addresses, obviously. for my Aqara P2 door/window sensor, i see IP address fde6:224:a244:0:f5af:f61b:c62:871. for my Onvis smart plug, i see IP address fde6:224:a244:0:e30e:5c57:b6ee:62a. for some reason, for my Aqara P2 light/motion sensor, HA shows a mac address but no IP address so i can’t ping it.

does unavailable correlate with apple tv in use? not as far as i can tell. however, i suppose it is possible that the appleTV could be “in use” in ways that are not obvious to me - i.e., other than simply when i’m using AppleTV to stream something. for example, when i look at history for my P2 door sensor, i see it was unavailable 03:36 to 04:50 local time this morning and my entire family was asleep at that time.

do you use HomePods as audio output? no.

can you ping the device at all times? i presume you are asking about the appleTV device. when i look at the appleTV device in my network it appears to have a v4 address and a large number (36) v6 addresses, which i can see are a mix of link-local and globally routable addresses. tbh, i don’t fully understand what’s going on with all the different v6 addresses, but when i took a quick stab at pinging some them, i found them to be not pingable - i saw either “no route to host” or just no response. however, the v4 address is and in my experience always has been reliably pingable, thus i think the (ethernet) connection to the lan is reliable.

other variables that possibly may be related: i use Unifi networking gear. for ipv6 addressing, i’m using SLAAC (not DHCPv6). the devices in question were added directly to matter in HA and are not using multi-admin - they have not been shared with HomeKit or anything.

when i look at the history of the two sensors, their periods of being unavailable seem to match exactly. in other words, it seems consistent with entire matter/thread network dropping at the same time.

here are a few specific oddities observed while i drafted the above text: i have two new Aqara brand P2 sleepy matter/thread devices - one light/motion sensor, one door/window sensor. seemingly nearly identical, but one shows an IP address, the other does not. also, one of the devices shows “share device” link (used if i want to add the device to another matter network such as HomeKit) where the other instead shows “show thread network” button in the same location.

so in summary, at this point the matter integration seems to working fine with matter-over-wifi devices, however it is unreliable for all three of the matter-over-thread devices in my network, with all of them sporadically and simultaneously becoming “unavailable”. matter-over-thread is also dependent on my border router, which is an AppleTV.

8

Yeah that is what I thought. This kinda proves that the problem is indeed not RF related, and most likely a communication issue between your AppleTV and Home Assistant.

I wouldn’t read to much into the frontend not showing an IP. Afaik, we do not refresh this dialog, so it might be outdated.

Uh, 36 addresses is really excessive! Something causes the device to jump/switch IPv6 addresses all the time it seems :thinking: How did you determine the IP addresses?

I actually have a AppleTV here too, and run Home Assistant on a Yellow as wellI. I’ve just checked the IP addresses asigned to my AppleTV 4K device using resolvectl query -6 from my Linux. It has 4 addresses assigned: Two global (2a02:something in my case). One seems to be assigned via DHCPv6 and one via SLAAC. Then I see one link-local (fe80) and one in the ULA range (fd7a). My AppleTV is a a 4K 3. Gen, Wi-Fi + Ethernet, 128 GB device.

What a Thread border router typically does is assign your network a ULA automatically if there is no IPv6 addressing available. Maybe somehow the AppleTV determines no IPv6 available every now and then which causes it to constantly resign new addresses? :thinking:

9

ip addresses for the appleTV were found by using the Unifi application (that’s Unifi’s network management app for configuring firewall, wifi, etc.). there are two link-local addresses (beginning fe80:). there are two ULA addresses (beginning fd8a:). the rest i think are all globally routable from the /64 assigned by my ISP.

10

I’m the original poster. A few weeks have passed. This problem remains unresolved. Below is a summary of where things stand.

I started using matter with a few matter-over-wifi devices. They paired easily and are working well. No problems.

Later I tried adding a few matter-over-thread sensors. Pairing devices worked fine. Initially, the devices seemed to be working. I later noticed that automations were failing and devices were sometimes showing in HA as unavailable.

I tried adding a matter-over-thread smart plug to act as a thread-router and hoped it would reduce any chance of a thread signal strength problem. It did not help. I observe that all of my matter-over-thread devices become unavailable at approximately the same times. It’s now been a few weeks and I can see roughly 3-5 unavailable periods per day, sometimes short (15 minutes), sometimes longer (multiple hours). I’m seeing this on multiple devices, multiple brands (Aqara and Onvis), both sleepy and always-on. One thing they have in common is they are matter over thread. Matter-over-wifi devices work fine and don’t show the same problem.

At this point, absent any obvious things to do or try, I am considering pulling the matter-over-thread devices from my system and switching to something else.

I’m open to suggestions on how to diagnose/troubleshoot/fix.

11

I’ve connected an Aqara P2 sensor yesterday to my Apple TV border router, and the device stayed available through the night. So I can with high certainty say that this is not generally a Matter Server issue, Apple TV issue or Aqara P2 sensor issue.

There are two/three things which need to work to communicate with the Thread border router: mDNS needs to be properly propagated and IPv6 Neighbor Discovery needs to reach your Matter controller. And finally, the gateway pushed via IPv6 Neighbor Discovery needs to be reachable again, so the packet can flow to the Thread network.

As for mDNS: Unify is kinda known for messing with mDNS. Make sure that you have everything in a single broadcast domain (as in no VLANs) and disable DNS reflection or similar features. These typically don’t work well with Thread Border routers/HA.

As for IPv6 Neighbor Discovery/Routing: It would surprise me if Unify/some other parts of the network gear would mess with this. But you can check this by constantly pinging a Thread device. If it becomes suddenly unreachable, something is probably off with routing or address assignment. You’d need to check the IPv6 routing table on the HA host to see if the route disappeared or similar.

In general, try to “dumb down” the network. In most extreme case, you could connect HA with the Apple Border Router directly through a switch only, to see if that setup works. And then build up from there.