Aqara Door Locks (Matter/Thread) Unresponsive In HomeKit, but only on some devices

[akleopard]

I’ve had both a U200 and U300 for over a year now, connected to Apple HomeKit directly as I don’t own any Aqara hubs. From time to time, both door locks randomly become unresponsive in the Home app on my iPhone, but continue working fine on other Apple devices, including my MacBook and my wife’s iPhone. All other HomeKit devices (though none are Matter/Thread) work normally on all devices. If I don’t bother fixing it, the issue usually resolves itself after a few weeks. However, this obviously sucks if I’m away on a trip.

Setup:
∙ Locks connected via Matter over Thread (no Aqara hub)
∙ Home hub: Apple TV 4K (Wi-Fi only, no Thread)
∙ Also have HomePod minis (Thread-capable)
∙ All devices on same iCloud account

What I’ve tried:
∙ Restarting devices, force quitting Home app
∙ Signing out/in of iCloud on my iPhone (this fixes it, but issue eventually returns)
∙ Removing and re-adding locks (works for months, then issue returns)

The issue is device-specific and intermittent- it works fine for months, then suddenly only my iPhone can’t control them while other devices still can.

I’m guessing this is an Apple/homekit issue, but just wondering if anyone else has experienced this before and has any suggestions?

[motherofcats]

I’ve experienced this kind of issue before since I have many (30+) devices on HomeKit. My eero network couldn’t handle all the devices and so intermittently some devices went offline. I switched to a ubiquity system and added more nodes to my mesh; I rarely encounter this issue now. How many smart devices do you have?

[akleopard]

Ha… I only have 5 or so devices including these 2 locks. The others are Philips devices, so connected via the Philips bridge.

[motherofcats]

You wouldn’t have two WiFi bands with the same name either? Like your 2.4ghz and 5ghz don’t share identical names?

[JohnD]

If you have connected the smart locks using Matter over Thread, it may be due to a change in IP addresses.

@JohnD

Link-Local vs. GUA vs. ULA

Thread strictly relies on IPv6, because only the 6LoWPAN standard compresses protocol headers efficiently enough to save bandwidth, and enables robust mesh routing without vulnerable DHCP servers or NAT barriers through serverless autoconfiguration (SLAAC). In other words: Thread only works via IPv6 addresses and not via IPv4.

However, it is crucial to understand that IPv6 uses different address types with different ranges (scopes), which has concrete consequences for data exchange across network boundaries.

Here are the three IPv6 address types that play a role:

• Link-Local (fe80::): Every device generates this address itself immediately after powering on. It is strictly limited to the physical network segment and is not forwarded by routers. Purpose: Initialization & emergency communication within the same room.
• GUA (2xxx::): The Global Unicast Address is usually assigned dynamically by the provider. It is globally unique, publicly routable, and enables communication across the entire Internet. Purpose: Communication with the Internet.
• ULA (fdxx::): The Unique Local Address is the stable, internal counterpart. The router specifies the network prefix, and the devices generate their own addresses (SLAAC). It is routable throughout the entire home network but not accessible from the Internet. Purpose: Stable communication within the home network, independent of the Internet provider.

What does this have to do with Matter-over-Thread and Matter-over-Wi-Fi? A router that sees a packet with a Link-Local address (fe80::) must discard it if it wants to leave the network. A Thread network is physically a separate subnet, distinct from the WLAN. Therefore, only ULA or GUA addresses work for communication between LAN/WAN and the sensor (Thread), as these are routable. Matter-over-Wi-Fi also works with Link-Local, since both devices are located in the same WLAN segment.

This is where the Primary Thread Border Router comes into play: It receives the ULA/GUA network prefix from the main router and distributes it into the Thread network. Only in this way does every Thread device receive an address that is reachable from the LAN.

The Problem: Many providers do not assign fixed IPs; the GUA prefix changes regularly (forced reconnection, restart). This change often leads to device discovery (mDNS/Discovery) breaking off or routes becoming temporarily invalid. The result: devices do not respond (“No Response”).

The Recommendation for Maximum Stability: To make the Smart Home independent of the Internet provider:

• Enable IPv6 on the router, but disable DHCP Prefix Delegation (PD) (to block external instability).
• Disable Stateful (DHCPv6) and enable Stateless (SLAAC) (so devices manage themselves).
• Activate Unique Local Address (ULA) and set it manually:
  • Router Address: fd00::1
  • Prefix: fd00:: (Length /64)

[bill112]

I went thru this and ended up just buying an Aqara doorbell that is also a Thread border router.

[akleopard]

Did that completely resolve the issue? I’m looking at the upcoming W200 which I think functions as a hub.

[DrSwollington]

I found they are much more reliable in Apple Home when paired to an Aqara hub of some kind. I use the Camera Hub G2H Pro.

[USBen]

Matter devices can be a bit different in their behavior. Changes in ip as mentioned and not enough border routers to spread the load can be problematic. If you’re looking to just keep everything directly in Apple home you may want to purchase a device that is plugged in and has thread border router functionality. The Aqara m100 hub can do this as well as the G410 doorbell. The M3 hub is another one that is amazing.

I’d also take a look and make sure IPv6 is enabled and working on your wireless router/modem.

If you’re not interested in adding door/water leak or any of the sensors then the G410 doorbell can go direct into Apple
Home and act as a thread border router. The bonus is that it’s also a hub in case you ever want to grab sensors as well. (They are excellent btw)

[akleopard]

Thank you for the suggestions. I’m waiting to get the W200 and also looking at the G400 or G410, so hopefully having one of these hubs will prevent this issue in the future.

[USBen]

My pleasure, I’m also waiting on the W200!