Matter CASE resumption delayed 10+ minutes on nRF52840 due to BLE-first serial fabric fallback

[brobin88]

Hi everyone,

I'm developing a matter generic switch and I’ve run into a puzzling behavior when commissioning an nRF52840 DK with Apple Home via an Apple TV Thread border router. After the switch reboots, it takes over ten minutes before the device finally becomes responsive again. By contrast, a similar Silicon Labs EFR32MG24 demo re-establishes secure channels in under a minute.  I got ChatGPT to compare the serial output of the EFR32MG24 and NRF52840 and here is the summary of what it thinks the issue is:

1. Two Fabrics in Apple Home Commissioning

When you commission with Apple HomeKit (Matter), you actually end up with two fabrics on your accessory:

1. iOS Fabric (Fabric 0)

   • Established via Matter-over-BLE (CHIPoBLE) when your iPhone pairs and commissions the device.

   • Allows your phone to issue commands, OTA updates, diagnostics, etc., over BLE.

2. Apple TV Fabric (Fabric 1)

   • Established via Thread when the Apple TV (or HomePod mini) acts as a Thread border router.

   • Provides full home-wide connectivity and lets the TV/hub control the device over the mesh.

Each fabric gets its own CASE session keys and ACLs, so your accessory must securely handshake with both controllers.

---

2. What the nRF52840 Demo Does (Wrong)

On reboot, the nRF52840 sample app:

1. Disables BLE advertising immediately (assumes “production” Thread-only mode once commissioned).

2. Calls Resuming 2 subscriptions in 0 seconds:

   • First it tries the iOS/BLE fabric → fails to connect (no BLE adv!) → times out with error 32.

   • Only after exhausting the BLE back-off (minutes!) does it try the Thread fabric → succeeds.

This serial fallback (BLE → fail → Thread) blocks your accessory for the entire BLE timeout before Thread CASE can even begin.

---

3. How the EFR32MG24 Demo Does It (Right)

The Silicon Labs demo on the same network:

• Keeps BLE advertising enabled for a window on boot, and immediately advertises over Thread once SRP is ready.

• This effectively rings both iOS (BLE) and Apple TV (Thread) controllers in parallel, so whichever controller responds first wins the race.

• As a result, CASE Sigma1 arrives in seconds, not minutes.

ChatGPT suggests turning on bluetooth extended advertising to ensure bluetooth is enabled to advertise to fabric 0 (iOS) but those settings are enabled by default in the matter template project. 

Any suggestions on what might fix this?

[Simonr]

Hi Ben

Our developers came back with a suggestion today, and we suspect that these 10 minutes delay you're seeing is actually the subscription interval set by the Apple Ecosystem, and after ~10 minutes the controller tries to establish a CASE session and the previous one times out. To trigger faster subscription re-establishment, accessory maker may enable what is called Persistent subscriptions which are described here:  https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/getting_started/advanced_kconfigs.html#persistent_subscriptions

We have not enabled this by default, and for all we know Silicon Labs has. In the past this was not well supported across ecosystems and also had some negative issues in large network set-ups. Although it's perfectly fine to use it.

Best regards,

Simon

[brobin88]

Thanks but if you take a look at the ticket that I linked here that was suggested to me in the past to turn on persistent subscriptions and it *did* work for a while and now it’s no longer working.

With persistent subscriptions I get an error message about case persistent subscription resumption failing with error 32 which indicates that it can’t find the controller and it still takes 10+ minutes to become responsive. I think this is because of the dual fabrics that Apple sets up as part of HomeKit.

fabric 0 is between the matter device and the iOS device that commissioned it. But because the iOS device doesn’t have thread and the nrf52840 doesn’t have wifi and turns off chipoble advertising after commissioning it can’t advertise its state on fabric 0 and therefore the sigma handshake isn’t received on fabric 0 because it can’t reach the iOS device.

the nrf52840 attempts to reconnect to fabric 0 for 10 minutes until finally failing and then reconnecting to fabric 1 which is the thread based fabric.

At least that’s my theory… I need that to be validated if possible