Matter device become offline in multi-fabric when multiple devices are provisioned

[Jayant Tang]

Hello DevZone,

One customer meets an issue. Needs an expert about Matter.

There are 5 Matter over Thread window covering devices which are already commissioned in 2 fabrics, the Apple HomePod & Google Home.

When only 1 device is powered on. The device is working fine.

When they turned on another device, the first device become unstable and was offline on Apple Home App.

(They have passed the Matter certification. And I'm sure all the 5 devices have different DAC and discriminators)

NCS version: v2.9.2

Here is the log:
2025.12.30.txt

Some useful information to read this log:

1. Timestamp: 

 There are 2 types of timestamp in the log. One is from device log.
Like `[17:55:39.053,527]`, it is the hours since the device starts.
Like `[08:13:23.326]`, it is the local time from PC serial communication tools.

2. Fabrics

There are 2 fabrics at the beginning: Fabric 1 (DEC758BE) and Fabric 3 (50E8938D)

But I don't know which one is Google, and which one is Apple.

3. Preliminary analysis by AI

 

What the customer did at 17h59m is just turning on another device.

Best regards,
Jayant

[Maria Gilje]

Hi Jayant, 

I have started to look into this, but I did not get very far today unfortunately.

Do you know if the instability also happens when only the Google Home ecosystem is running? 

Also, I found a slightly old post internally where some issues with persistent subscriptions were mentioned for Apple ecosystems. It could be relevant since the customer is using NCS v2.9.2 (the internal post was from summer 2024, so not an exact match, but close to v2.9.2). 

Apologies for the short reply. I will return to this on Friday! 

Best regards,

Maria

[Jayant Tang]

Hello Maria,

Maria Gilje said:

Do you know if the instability also happens when only the Google Home ecosystem is running? 

We didn't test that way. But when there is only Apple Home ecosystem, the device is stable.

Is there any progress of this issue?

Best regards,
Jayant

[Susheel Nuguru]

Hi Jayant,

I am unable to clarify and associate Fabric 1 to Google or Apple. Can you clarify what this fabric is associated to?
In case it is Google, can you verify of there are multiple Google controllers (hub and phone) active? If so they can created repeated sessions.

Can you try to increase CHIP_IM_MAX_NUM_SUBSCRIPTIONS by increasing CHIP_CONFIG_MAX_FABRICS in CHIPProjectConfig.h and see if that helps?

 

[Jayant Tang]

Hi Susheel,

I can clarify that now:

Environment:
-  1 iPad(AppleHome APP + GoogleHome APP)

- 1 Apple HomePod

- 1 Google Nest

- 5 Matter Window Covering

Test method:

Add some apple home automation tasks in Apple Home APP. Running whole night. In the morning we will see some devices are offline. 

Susheel Nuguru said:

Can you try to increase CHIP_IM_MAX_NUM_SUBSCRIPTIONS by increasing CHIP_CONFIG_MAX_FABRICS in CHIPProjectConfig.h and see if that helps?

We will try that later

[Susheel Nuguru]

Thanks Jayant for that additional info. Please write back here on the results of increasing those configs. 

[Jayant Tang]

Hello Susheel.

After testing, those configs don't help.

Larry has told me that Apple doesn't have good support for SSED. So I helped the customer change to SED.

Now they met issues like:
ReceivedTofile-COM38-2026_1_8_11-11-47.DAT

Meanwhile, Larry has built an environment that has 3 fabric and several DKs configured as SED. It was running the whole weekend, and no errors happens.

So I think there may be something wrong in customer's code. I will compare customer's code with the NCS v2.9.2 samples and see what is different.

[Marte Myrvold]

Hi Jayant,

Susheel is out of the office, so I have been assigned to the ticket.

It seems like the customer is running out of memory, since "DataVersionFilter pool full, ignore this filter" is printed when you get CHIP_ERROR_NO_MEMORY. It could be because of insufficient heap or too small packet buffer pool.

They can enable Matter memory profiling to see actual heap/stack usage and where they are running out:

CONFIG_CHIP_MEMORY_PROFILING=y

If the failure happens because of insufficient heap, they can increase the heap with:

CONFIG_CHIP_MALLOC_SYS_HEAP_SIZE=

If the issue is due to the packet buffer pool, they can increase this with:

CONFIG_CHIP_SYSTEM_PACKETBUFFER_POOL_SIZE=

If the customer has not already done so, I would also recommend going through the Memory footprint optimization guide to optimize their application.

Best regards,
Marte