Tip on some problems with Thread devices and Homekit

[JRS54]

When Homekit sudenly tells you that a Thread device is not responsive and the device seams to work in the Aqara app.

The first thing to do is to check the Network Information of that device in the Aqara app.
If the Aqara app gives a Network Failure, restart the Border Router.

Most likely the problem in Homekit will then be solved.

If I’ve done that it would have saved me a few hours of troubleshooting.

[JohnD]

This may be the cause of your problem:

@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”).

If possible, configure your internet router to use a self-assigned IPv6 prefix (ULA) rather than the IPv6 prefix used by your internet provider (GUA) in your home network.

[ludovic_boue]

Be careful not to confuse the Home app with the HomeKit protocol.
It is indeed confusing because the app used to have the same name. This is no longer the case since the Matter protocol has been supported.

[JRS54]

@JohnD
I changed the config of my router, hope it helps.

Troubleshooting with no or little knowledge can be very frustrating.

What I wanted to share that if I first had checked that my Thread network was still up and running or not, I could have “solved” my problem in minutes.
When it happens again, I can “solve” it quickly and dive deeper in what the real solution will be.
What also didn’t help is that I only have one Thread device, so there was no indication that my Thread network was down.

Starting at the wright point can be less frustrating.

[JohnD]

@JRS54

When it happens again, I can “solve” it quickly and dive deeper in what the real solution will be.

I completely understand the relief of finding a quick fix when you’ve been frustrated with troubleshooting. It feels great to just see it working again.

Just a small technical note though: While restarting the Border Router gets things back up, keep in mind that it might actually make “diving deeper” harder later on.

A restart usually clears the current state (routing tables, caches, logs), so you effectively wipe the evidence of the error. If you want to find the root cause next time (like verifying the IPv6 prefix issue), it would be better to check router logs or mDNS discovery tools before rebooting.