Before removing an Aqara hub: a 5-minute HomeKit/Matter dependency check

Apple Home Connect
1

With a larger Aqara setup built mainly around Apple Home and Matter, one of the riskiest troubleshooting steps is removing a hub or bridge before documenting what depends on it. Duplicate accessories or stale Matter entries can make a reset tempting, but a full reset also removes information that can help identify the actual failing layer.

Before removing or re-pairing anything, I would record:

  1. The physical device and room
  2. Its parent Aqara hub
  3. How it connects to that hub: Zigbee, Thread, or Wi-Fi
  4. How it reaches Apple Home: native HomeKit or a Matter bridge
  5. The active Apple home hub or Matter controller
  6. Any automations and scenes that depend on it
  7. The relevant hub firmware, Aqara Home version, and iOS/Home version
  8. Whether the problem appears in Aqara Home, Apple Home, or both

Then I would test one layer at a time:

  • If the device works correctly in Aqara Home but not in Apple Home, I would focus on the bridge or controller path.
  • If it fails in both, I would start with the device or its Aqara hub.
  • If an accessory appears twice, I would check whether the hub was added through both native HomeKit and Matter before deleting anything.
  • I would save screenshots of names, rooms, scenes, and automations, and treat removing or re-pairing the device as the last step.

Has anyone found a convenient way to keep this kind of inventory up to date? Do you normally choose one Apple Home exposure path per Aqara hub, or temporarily keep both while testing?

2 Likes
2

@jamesfengyuyang This is a really solid framework for troubleshooting, and I appreciate you sharing your systematic approach. The duplicate accessory issue you mentioned is particularly common with Matter-capable hubs like the M3—if you add it via both the HomeKit QR code and the Matter QR code, you’ll end up with double entries for all Zigbee child devices while Matter-native devices stay single.

Regarding your question about exposure paths: I’d generally recommend choosing one integration method per hub to keep things clean. Native HomeKit pairing exposes the hub as a security system (alarm), which is useful if you want that functionality in Apple Home. Matter bridging, on the other hand, opens up broader ecosystem flexibility and enables features like the Advanced Bridge for scenes and private functions. Running both simultaneously mostly creates confusion without adding practical benefit.

For inventory management, a simple spreadsheet works, but I’ve seen users have success with Home Assistant’s device registry exports or even just consistent naming conventions in Aqara Home (prefixing by hub/room) to make parent-child relationships obvious at a glance.

Your layered testing approach is spot-on. The “works in Aqara Home but not Apple Home” diagnostic is usually the fastest way to isolate whether you’re looking at a bridge sync issue versus a deeper connectivity problem.