Aqara on Matter over Thread = Laggy App

[Andrei.C]

It is just me, or maybe there are some others with this problem?

I recently replace everything in my house with Aqara products. I choose to connect them thru Matter over Thread instead of Zigbee. I will list down all the products, if have any importance. The problem is the app have a big delay. No to mention sometimes is not even taking the commands. One night i had to get out of bed to manually turn off a light because from the phone was unresponsive to command. Not to mention that sometime I get an error message. I will attach a photo.

I like to mention that I do not have internet connection problems, previous products were respond instantly, even if they were cheaper quality (Tuya)

I know there is the option to connect them thru Zigbee, I just chose Thread, so telling me to switch to Zigbee won’t help.

Products list:
Aqara Hub M3 - 1 pcs
Aqara Camera Hub G3 - 3 pcs
Aqara Climate Sensor W100 - 4 pcs
Aqara Door and Window Sensor P2 - 6 pcs
Aqara Doorbell Camera Hub G410 - 1 pcs
Aqara Smart Lock U200 - 1 pcs
Aqara Water Leak Sensor - 3 pcs
Aqara Radiator Thermostat W600 - 6 pcs
Aqara Light Switch H2 EU 2 gang - 5 pcs
Aqara Light Switch H2 EU 1 gang - 5 pcs
Aqara Wireless Remote Switch H1 - 2 pcs
Aqara T1 10A EU - 2 pcs
Aqara Adjustable Cylinder (AL-D04E) - 1 pcs

Error photo:

[david]

Looking at your setup it seems to me you’ve a distinct lack of borter routers.

You’ve some switches H2 switches that could possible route thread network but it seems really limited and you’ve many end devices.

I think I’d place a couple of m100 hubs to extend your thread network in strategic places.

[JohnD]

That looks like a connection drop.

Adding more thread border routers might help stabilize your thread network.

You should also check whether the devices are receiving IPv6 ULA addresses (Unique Local Addresses). And switch from a DHCPv6 server to SLAAC. For me, this has eliminated connection drops, as it makes the Matter network independent of the ISP’s frequently changing IPv6 prefixes.

[Andrei.C]

There are 10 switches in all apartment, and the distance between them does not exceed 4-5 meters, every room have at least 2 switches.

[Andrei.C]

Looks like it is on SLAAC

[JohnD]

Yes, but those are GUA, not ULA. Those are exactly the addresses that are causing problems.

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

[Andrei.C]

Yea… This Matter was supposed to make things more easy to use, but look like it’s just opposite…

[JohnD]

It should actually be pretty simple. But I see you have a TP-Link router. Unfortunately, that’s a problem. According to the information I found, TP-Link has included this on their roadmap, but it seems that as of today, you still can’t assign a ULA prefix.

[Andrei.C]

Yes, it’a a Tp-Link. It’s just strange how this thing was supposed to be a plug and play become a scout and modify router settings. I wasn’t expecting to that when I decided to use the Matter over Thread. Looks like sometime I’ll have to encourage myself and do the ugly part, to re-add all thru Zigbee….

[david]

Hello John,

My ISP does not have IP6 they are IP4 only, I do not have issues with my Thread setup but was wondering if there is some guide I need to follow for the IPV6 configuration on a setup with ISP IPV6?

I’ve a Mikrotik router and IPv6 is enabled but I’ve not actually configured anything on it.

Below are some end devices as well as my Home Assistant network does this all look ok?

Node ID:
153
Network type:
Thread
Device type:
Sleepy end device
Network name:
AqaraHome-e2a8
MAC address:
8a:0e:52:5b:3b:dd:ac:fe
IP address(es):
fd2a:2498:25ff:1:4d0:2cbf:be10:13ec

Node ID:
130
Network type:
Thread
Device type:
Sleepy end device
Network name:
AqaraHome-e2a8
MAC address:
c6:2c:1e:d8:55:45:e7:fe
IP address(es):
fd2a:2498:25ff:1:7533:8ae5:fdf5:d4d6

Node ID:
112
Network type:
Thread
Device type:
Unknown
Network name:
O 
MAC address:
62:55:1f:20:c2:6c:81:25
IP address(es):
fd2a:2498:25ff:1:6ae7:dc04:bc04:efb4

Home Assistant
Detected: eth0 (192.168.8.10/24, fd4f:9e82:e302:e2c2:f146:31fa:baa8:d767/64, fe80::2a26:b199:d168:c894/64)

[JohnD]

@david

fd2a:2498:25ff:1:4d0:2cbf:be10:13ec

Looks good! As the addresses start with fd, they are Unique Local Addresses.

Problems only arise if there is no ULA prefix and global unicast addresses have to be used instead, and if the ISP keeps changing the prefix.

It would be even more problematic if your ISP doesn’t support IPv6 and your router can’t manage a ULA prefix — as seems to be the case with TP-Link routers. There are also some very heated discussions online about the fact that you can’t use Thread in that situation.

[Andrei.C]

So, what do you think would be a better solution? Change the router with something else than Tp-Link? What do you recommend from known brands, easy setup, probably mesh, around 85-90 square meters.

[JohnD]

@Andrei.C

So, what do you think would be a better solution?

I think you definitely have the following options:
a) Switch to Zigbee
b) Wait for the firmware update from TP-Link (promised since last year, with no timeline announced)
c) Buy a new router

It’s hard to say which is the best option.
a) Takes time
b) Takes patience
c) Costs money

Which one is the least painful for you?

@Andrei.C

What do you recommend from known brands, easy setup, probably mesh, around 85-90 square meters.

I personally use an AVM FRITZ!Box as my router, along with a FRITZ!Repeater. By default, the router assigns a ULA prefix if there is no active IPv6 internet connection. If there is an active connection, however, you have to manually assign a ULA prefix and configure the settings in FRITZ!OS yourself. So, it’s not exactly plug-and-play.

Google Nest Wifi Pro and Amazon eero 6+ might be good alternatives. Both systems have a Thread Border Router (TBR) built directly into the hardware right out of the box. From what I understand, both are easy to set up, and the ULA prefix is supposed to be enabled by default—which makes perfect sense since Thread is on board.

I’d also like to add a quick note about Ubiquiti UniFi. It is extremely popular among people with a lot of IoT devices because it offers advanced features like VLANs to isolate smart home traffic. However, it’s definitely not a simple plug-and-play solution and requires a much more complex setup process compared to standard consumer mesh systems.

[daniel_wahlsten]

i Agree

[Andrei.C]

I was thinking for this Amazon eero 7 dual-band mesh Wi-Fi 7 router , 3-Pack 560 M2

[JohnD]

If you have Wi-Fi 7 devices or want to be future-proof, that should work out fine. But didn’t you mention something about 90 square meters? The 3-pack covers up to 560 square meters. If you set up too many mesh nodes in a confined space, they can actually interfere with each other and noticeably degrade your network.

[Andrei.C]

You think it’s too much? I am thinking in the condition that i already have a tp link mesh extender, and here are the results between near the router and the extender. I was hoping to get a better connection.