Advanced Functions of FP300 via thread

I just bought an FP300, and found functions like AI learning are not available under thread. However, those functions are available via zigbee.

I heard one explanation that Aqara is trying to follow standard cluster definitions within the matter protocol. However, matter also allows custom cluster definitions, that can be used with supported matter servers. This is similar to what aqara is doing on zigbee.

The point is, adding custom cluster definitions for matter over thread does not break compatibility for the core functions on those platforms that only supports those core functions. An example is the inovelli matter over thread dimmer, which implements a lot of configurations via custom clusters.

I would appreciate clarifications from aqara that if there is any plan supporting those advanced functions under matter/thread.

2 Likes

Yes, the Matter standard does allow custom cluster definitions, but there is an important limitation to consider.

The problem is that custom clusters need to be interpreted by the hub or controller — they don’t just work automatically. This means Aqara would have to implement these custom clusters not only in the FP300’s firmware, but also in the firmware of all their hubs. And here’s the critical point: other manufacturers will most likely never implement Aqara’s custom clusters, simply because they are not part of the official Matter standard. So you would be entirely dependent on an Aqara hub for those advanced features to work at all.

But that actually raises the question of whether this approach makes any sense in the first place. If you need an Aqara hub anyway, you could just as easily connect the FP300 via Zigbee to the Aqara hub and then expose the hub itself as a Matter bridge. The result would be exactly the same: all the advanced settings would be configurable via Zigbee, and the sensor would still be accessible via Matter to your smart home platform of choice.

So for now, connecting via Zigbee + Matter bridge seems like the more practical solution if you want access to all features — and one can only hope that manufacturers will eventually agree on a common standard that includes these kinds of advanced settings for presence sensors.

3 Likes

While using standardized clusters would certainly be preferred, I would definitely prefer to have the option to use custom clusters instead of a severely dumbed-down device in Thread mode.

Lots of Aqara customers seem to rely on Home Assistant. Just as it requires some integration work for ZigBee, it could be easily expanded to support all the device’s features in Thread mode till Matter catches up.

3 Likes

Yes, you’re right about that—it would save you from needing a Zigbee stick in HA. However, I’m not sure if that justifies the integration effort, only to throw out the custom clusters later and replace them with standard clusters that are likely coming in the foreseeable future anyway. Plus, the maintenance overhead would be twice as high to support all options across both Thread and Zigbee firmware. Aqara’s developers could spend that time on other, more important things. Just my opinion.

1 Like

Thank you for the explanation! I was trying to migrate devices in my home from zigbee to thread because of latency and self healing.

Plus, the maintenance overhead would be twice as high to support all options across both Thread and Zigbee firmware.

Agreed. But that should be expected when they advertise a product to support both zigbee and thread.

Anyway, it looks like zigbee is the only option for now. If aqara’s plan is to only support advanced functions in zigbee, I would refrain from buying more fp300s.

1 Like

I would argue that with an Aqara M3 Hub connected via LAN, you should hardly notice any latency difference in normal day-to-day use. Thread/Matter still has its own share of challenges and rough edges, such as IPv6/GUA-related issues.

Out of curiosity, what problems were you experiencing with Zigbee that made you consider migrating?

Quite some zigbee devices randomly disconnects when I have ~ 30 zigbee devices in my network. Currently I have ~ 20 thread devices and they are pretty stable.

Another reason is that thread supports multiple border routers. Previous I have zigbee coordinator directly connected to my HA, if my HA is down, everything is down. With thread, I can still control them with apple home.

Okay, the number of devices probably doesn’t play such a major role; around 50 devices really shouldn’t be a big problem. Your issues are likely more related to their spatial distribution and how far away they are from the coordinator. Theoretically, you should be able to solve these problems with a mains-powered Zigbee device, like a smart plug, because those act as routers and extend the Zigbee mesh (similar to how it works with Thread). However, if you already have several Thread Border Routers, making the switch obviously makes a lot of sense too.

I don’t know why your HA would go down, but maybe a system health monitoring integration (like HAGHS, Watchman or Spook) could help, or you could try letting an AI analyze your setup and logs.

My setup is built quite differently to avoid exactly these kinds of dropouts:

Network Structure & Bridging: I use multiple Aqara Hubs (Zigbee + TBR), and every sensor is directly connected to its nearest hub. I also use several Zigbee smart plugs to extend the signal within their respective meshes. Each of these hubs is then integrated into Home Assistant (HA) as a Matter Bridge. For any non-Aqara devices, I run an additional, dedicated Zigbee coordinator and a Z-Wave stick directly on my HA server.

Redundancy & Fallbacks: On top of that, I have several Apple Home Hubs acting as Thread Border Routers. If one fails, the others seamlessly take over. I am currently also considering getting an Aqara M3 Hub. It would take over the lead role in the Aqara network, and if it ever goes down, my existing hubs would just act as fallbacks.

Ecosystems & Automations: All my sensors and devices are connected to Aqara Home, Apple Home, and HA simultaneously. I distribute my automations across the different ecosystems depending on the specific use case. This makes a complete system failure highly unlikely; if something goes down, it only affects a small subsection.

Hardware: My HA instance runs on relatively powerful hardware (a Synology+ NAS) and has literally never gone down. Theoretically, I could set it up to be completely fail-safe with high availability, but honestly, it runs so stably that doing so would basically just be a waste of money.

2 Likes

Thank you for sharing and I understand that your setup works well.

However, matter/thread does provide a better experience for me over zigbee for the reasons I shared.

Nevertheless, it is less about whether zigbee or thread is better: they have their pros and cons. My only question to aqara is whether it is designed that thread provides an inferior functionality compared with zigbee. After all, FP300 is advertised to “support” both zigbee and thread.

Let me try to break down my previous thoughts a bit more clearly to help answer your question:

a) Transparency on Features (Zigbee vs. Thread) Yes, Aqara advertises that the FP300 supports both Zigbee and Matter over Thread. However, they are also very transparent on the product page about which advanced features are available exclusively on Zigbee and which basic functions are currently supported via Thread. So, if you check the specs before buying, you know exactly what functionality to expect for your specific setup.

b) The Issue with Custom Clusters & Hub Requirements Since there is currently no official Matter standard for those advanced radar settings, the only way to implement them via Thread would be through custom clusters. Here is why that is problematic:

  • Ecosystem Lock-in: These custom clusters would primarily only be understood by Aqara’s own system, meaning you would inevitably need an Aqara Hub. This kind of defeats the purpose of choosing Thread over Zigbee, as you could just use Zigbee with those hubs anyway.
  • Target Audience: While power users and community projects on platforms like Home Assistant (HA) might find a way to reverse-engineer and utilize these custom clusters, they represent a smaller portion of the user base. Aqara seems to focus heavily on the mass market (like Apple users), which also explains why there isn’t an official HA integration yet.

c) The Future of Matter & Developer Resources I am pretty sure Aqara will only integrate clusters that are natively supported by major platforms like Apple Home. But right now, Apple doesn’t even support all standard Matter device types, simply because Matter is still an evolving standard.

This begs the question of how the standard will develop:

  • Will more advanced clusters be added to the official standard soon?
  • Does it make sense to build proprietary custom clusters now, only to discard them later once an official standard is released?

Ultimately, for a company like Aqara, it makes no economic or technical sense to invest expensive developer resources into proprietary Thread custom clusters right now. It makes far more sense to focus their capacity on already standardized Matter features—like the upcoming Matter cameras or updating their existing hubs to Matter 1.4 and Thread 1.4.