I’m trouble shooting an issue with Nanoleaf downlights in Apple Home. I noticed that whilst it was patchy in Apple Home it was pretty consistent with Aqara.
The lights are all set up via Matter. Initially added to the Nanoleaf App, then connected to Apple Home, and then shared with Aqara M3 Hub.
I have 2 H2 EU double switches in decoupled mode where the buttons cause automations to run which turn on 8 downlights each (8 in the kitchen, 8 in the dining room).
I noticed that when lights went unreachable in Apple Home, they’d still work with Aqara.
I logged a call with Nanoleaf and I was running Beta 27.2 at the time. Now running production release and it has not improved. This is part of their response:
Why Aqara Stays Stable While Apple Home Drops Reachability
In a Matter Multi-Admin setup, your 16 downlights join a single, shared Thread mesh network. However, Apple Home and Aqara communicate across two distinct Matter fabrics:
- Direct Controller Unicast vs. Apple Home mDNS Polling: The Aqara hub typically communicates with the downlights via direct IPv6 unicast commands, which execute reliably whenever a button triggers an automation. Apple Home, by contrast, relies on continuous background Bonjour / mDNS multicast queries over IPv6 between your active Apple Home Hub (Apple TV or HomePod) and all 16 endpoints to track real-time status.
- Cluster Polling Regressions in OS Betas: As you noted with the 27.2 beta, Apple Home’s Matter/Thread stack in preview and beta builds has experienced known regressions with mDNS multicast traffic and standby hub arbitration—particularly across larger clusters of 10+ Thread endpoints. If the active Apple Home Hub experiences packet drops or timing delays while sweeping all 16 lights, it prematurely marks random bulbs as unreachable, even though the bulbs are online and listening on Thread.