When an Aqara child device is online in Aqara Home but missing from Apple Home or Home Assistant through a Matter bridge, I avoid resetting the device or bridge first. I compare three lists:
- child devices shown online under the Aqara hub;
- devices the hub says it currently exposes through its Matter bridge;
- accessories the target controller actually received.
For each item I record the model, a temporary unique name, room, and controller path. If a device is missing from list 2, repeated commissioning on Apple Home or Home Assistant cannot expose it; the question is bridge support or hub firmware. If it appears in list 2 but not list 3, I focus on the Matter commissioning and controller side. If it appears in all three but control is stale, I test one on/off command in each app and timestamp the results.
Before removing anything, I also note which automations and scenes reference the accessory. That preserves enough evidence to choose the failing layer without turning a visibility problem into a larger rebuild.
1 Like
@jamesfengyuyang This is a solid diagnostic framework — methodical and saves a lot of unnecessary resets. The layered approach of isolating bridge exposure vs. controller reception vs. stale control is particularly sharp.
A couple of things worth keeping in mind from the reference side:
-
Bridge support isn’t universal — only specific Aqara Zigbee devices can be exposed through a Matter bridge, even with compatible hubs like the M2, M1S Gen 2, M3, or M100. If a device isn’t on that supported list, it simply won’t appear in list 2 regardless of firmware.
-
Hub firmware and network alignment matter — for Matter-related offline or visibility issues, Aqara’s troubleshooting points to keeping hub firmware current and ensuring multiple hubs share the same LAN. Your list-2 gap aligns well with that first check.
-
Same-LAN requirement for controllers — especially with Apple Home, the Aqara hub and Apple Home Hub (Apple TV/HomePod) need to be on the same local network segment; AC+AP setups can trip this up even when everything looks connected. Worth verifying when list 2 shows the device but list 3 doesn’t.
Your timestamped on/off test for stale control is a nice touch — gives you concrete data before deciding whether the issue is command latency, state sync, or something deeper in the automation layer.
Have you found particular device families or hub firmware versions where list-2 gaps are more common? Would be useful to cross-reference against the supported bridge device matrix.