Aqara p2 sensors - status changes to "unavailable"

dduff617 · June 13, 2024, 2:20pm

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.

agners · June 14, 2024, 9:43am

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)?

dduff617 · June 14, 2024, 6:57pm

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.

dduff617 · June 19, 2024, 7:16pm

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

dduff617 · June 22, 2024, 2:19pm

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.

agners · June 23, 2024, 10:25am

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?).

dduff617 · June 23, 2024, 4:52pm

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.

agners · June 23, 2024, 5:18pm

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 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?

dduff617 · June 23, 2024, 9:58pm

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.

dduff617 · June 30, 2024, 4:43pm

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.

agners · July 2, 2024, 6:48am

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.

dduff617 · July 5, 2024, 6:51pm

my network is already pretty dumbed-down. for now at least, i have no VLANs set up. i’ve done my best to turn off any Unifi features that seem to try to optimize or restrict broadcast traffic or mDNS. Security features designed to isloate networks or devices are not enabled.

dduff617 · July 10, 2024, 6:42pm

Ok, I had previously heard/read general info that suggested that matter devices sometimes did not behave well when you use them with multiple controllers.

Then in trying to do deeper research and troubleshooting of the aforementioned problem, in another forum, I stumbled across a recommendation to add matter devices first to HomeKit, then share them with Home-Assistant. I did this. It was very easy smooth at each step - remove from HA, add to HK, then re-add to HA by sharing from within HK. It only took a minute or two for each device and I was done.

Since then, I have seen no more unavailability problem within HA. Otherwise, everything is basically the same from the HA perspective, The same devices still show up under the HA Matter integration.

As an aside, doing this migration actually fixed another minor cosmetic issue I was having with the Aqara matter sensors. Previously, for some reason there were multiple instances of the sensor entities for each sensor appearing in HA. It was easy enough to work around, but kind of messy. After this migration, everything seemed to work as expected - duplicate entities were gone.

So overall, this proved to be a very good workaround for my problem. I not really call it a solution however. I think there is still a problem with AppleTV acting as thread border router, with Home-Assistant’s interface to matter/thread devices, or some interaction between the two.

agners · July 12, 2024, 7:16am

Uh that is interesting. In fact I have my devices also connected to Apple Home, so maybe that is the reason I can’t reproduce this

I’ll remove all my device from Apple Home and see if that makes the problem appear here too.

If that is true, it sounds like just the presence of an Apple controller somehow affects communication with this Thread device. I’ve recently seen Apple Thread Border Router to behave somewhat strange, e.g. inhibit certain types of communication (Matter updates). Not sure if the communication with our controller somehow gets dropped/rejected, but as soon as Apple Home is active too this doesn’t happen anymore

This is likely from a earlier commissioning attempt. Deleting the extra entities manually usually solves this too.

dduff617 · July 13, 2024, 5:09pm

a hypothesis that seems consistent with available data:

there is nothing wrong with any of my devices and nothing wrong nor with HA Matter integration per se.

AppleTV is capable of acting as a thread border router and will allow pairing of matter/thread devices in HA, however it may not become fully stable/active as a bridge for use in HA until/unless Apple Home tells it (somehow?) it has a matter/thread device it cares about.

thus it could be that putting just one matter/thread device into HomeKit would suffice to fix the problem. …or it could also be that all matter/thread devices need to be multi-admin’d in HomeKit to function reliably in HA. I’m not sure which.

agners · July 15, 2024, 9:48am

So I did that, and my Aqara Door and Window Sensor P2 with 1.0.0.0 firmware stayed available for the last three days. So there is not a generic issue with devices going unavailable with Apple border routers when devices are not paired with Apple Home.

It seems more likely that this is related to your networking gear.

There are other folks with Unifi gears having intermittent Thread problems, in a recent discussion on thread on Discord one user had Google Border routers. He disabled the “multicast enhancements” under WiFi settings which made devices to stay available. I also just found this blog post about Unifi and Matter issues, which actually suggest the exact opposite .

dduff617 · July 21, 2024, 6:43pm

i agree the problem could be related to Unifi networking. i made effort to ensure that the unifi features related to broadcast traffic optimization were turned off, but could have missed something.

i also note that there were two distinct cases:

caseA: matter/thread devices were added directly to HA. appleTV acting as the thread border router.

caseB: matter/thread devices were added to HomeKit, then shared with HA. appleTV acting as the thread border router.

so if the problem is to any degree a Unifi problem, it still seems likely to be related to some detail of how HA interacts with Unifi networking that differs from how HomeKit does it for “native” HomeKit matter devices.

Wolvboot · August 1, 2024, 10:55pm

Somewhat peripherally related response here; I had a similar problem where it used to work then became unavailable, and I do use Unifi networking.

My problem was I assumed my device (a cheap Jinvoo matter powerstrip) was Thread, and I guess somehow it’s wifi. So I had an unexplained “espressif” device on my network, which I blocked, and that screwed me straight to the wall. Anyway, don’t do that.

Also you will need to be on the correct SSID you want the device to use when you add it. There is no way to change this other than dropping and re-adding.

dduff617 · August 2, 2024, 4:44pm

so almost two weeks later, another update.

my previous hypothesis that adding matter-over-thread devices to Apple Home first, then sharing them from Apple Home (AH) to Home Assistant (HA) would result in stable operation eventually proved to be false.

things looked promising and the devices remained up and stable for a week or so, however after about a week of working reliably, matter-over-thread units became “unavailable” again in both AH and HA. there was nothing i could do to bring them back and ended up having to do a hardware-reset on the device followed by a re-add to both AH and HA.

for now, i’ve decided for now to simply remove the Matter-over-thread devices. these were basically an experiment to test the current state of Matter devices and at least for my home, my situation, and my network, i reluctantly have to declare the experiment a failure.

what does work:
matter-over-wifi devices have been 100% reliable.

what specifically does not work for me:
matter-over-thread devices could be added to the network quickly/easily but would later drop off the network. this happened for devices added directly to HA. it also happened for devices added to AH and shared with HA.

possibly-relevant details:

Unifi network using a Unifi Dream Machine Pro as router/DHCP/firewall.
AppleTV acting as thread border router.
Matter server 6.3.1 HA add-on
Matter (BETA) HA integration - version as of July 2024.
Aqara P2 motion/light and door sensors
Onvis-brand smart plug

so this will be my last update for a while to this thread - at least until i hear of some significant changes that may yield better results.

Wolvboot · August 2, 2024, 4:54pm

Yeah, I’m returning that powerstrip too. I did get matter over IP to work in home assistant alone (no homekit) after a great deal of difficulty (there was a whole thing with IPv6), but I try to avoid wifi IoT devices whenever possible. Getting the zigbee version instead.