Matter subscription fails after some time causing weird state

RE: Matter subscription fails after some time causing weird state

Susheel Nuguru — Sun, 23 Nov 2025 11:03:41 GMT

Sorry for the delayed reply. Maria is OoO and I will try to help you with this if you still have this issue.

I am not an expert but seems like calling Matter setters from your sensor thread without going through the CHIP thread causes instability. I tis better to schedule a CHIP thread and Call UpdateCo2(matter_co2); from your sensor thread. This runs on the CHIP thread, no lock contention

void UpdateCo2(float co2)
{
    PlatformMgr().ScheduleWork([](intptr_t arg) {
        const float value = static_cast<float>(arg);
        gCarbonDioxideConcentrationMeasurementInstance.SetMeasuredValue(
            chip::app::DataModel::MakeNullable(value));
    }, static_cast<intptr_t>(co2));
}

The other option is to use the stack lock but it might have corner cases if you have long critical sections.

RE: Matter subscription fails after some time causing weird state

Tiit — Tue, 21 Oct 2025 10:01:30 GMT

Hi Maria,

So far the locking seems to have fixed the stability issue.

But subscriptions still seem to be limited to one. See this log from the device:

[00:14:38.393,127] <dbg> chip: LogV: [IM]Received Subscribe request
[00:14:38.395,172] <inf> chip: [IM]Deleting previous subscription from NodeId: 000000000001B669, FabricIndex: 1
[00:14:38.397,888] <inf> chip: [DMG]Subscription id 0xf54ff378 from node <000000000001B669, 1> torn down
[00:14:38.401,397] <inf> chip: [DMG]Final negotiated min/max parameters: Min = 10s, Max = 120s

The weird thing is the device does seem to work correctly if I add it to Home Assistant for example. I can see all sensor values updating and logging correctly. But if I try to use chip-tool to manually subscribe to attributes then there seems to be a limit. And as far as I can tell the limit seems to be on the device side as chip-tool will report a timeout for the old subscription. This timeout leads me to believe that it was not expecting the old subscription to go away.

Should I create a new ticket for the subscription limit issue or is it ok to continue this here? This issue is not blocking me from moving forward with my development but I do find this odd and would like to find the reason for it happening here.

Tiit

RE: Matter subscription fails after some time causing weird state

Maria Gilje — Mon, 20 Oct 2025 12:51:12 GMT

Hi Tiit,

Great find about the Lock/UnlockChipStack functions. I can see now that it is recommended to use them when calling functions which update attributes when you are not already in a Matter context. See this reply to related GitHub issue for some general guidelines for when to use the Lock/UnlockChipStack functions. Note that calling LockChipStack when the stack is already locked can cause a deadlock.

Did you see improvement after letting your updated application run for a while?

Best regards,

Maria

RE: Matter subscription fails after some time causing weird state

Tiit — Wed, 15 Oct 2025 14:25:52 GMT

Hi Maria,

I was optimizing the memory use when I found something that leads me to believe the issue may be data synchronization between threads instead. I followed the memory optimization guide you linked but honestly saving large amounts seems pretty much impossible. Most of the bigger chunks are used up by things that come with Thread, Matter and BLE. Those I have very little control over unless I really want to dive deep into how they work. So for now I just optimized the stacks and cleaned up some unused stuff but it had no effect on the stability. So on suggestion from a colleague I tried just removing some of our own threads temporarily to save bigger chunks of memory. One of these threads was the one pushing new sensor values to Matter. This made it so that the code now doesn't crash at all. So today I tried putting back everything else but just commented out the part where we update matter attribute values. And this is also stable.

What I'm going to try next is just updating Matter attributes one by one starting with co2. If I just run this:

gCarbonDioxideConcentrationMeasurementInstance.SetMeasuredValue(chip::app::DataModel::MakeNullable(float(matter_co2)));

The code will eventually crash. This is called from our sensor thread and I think this is actually meant to be called in some other way or from some other context.

What I'm trying next (and it hasn't crashed so far) is this:

	matter_co2++;
	PlatformMgr().LockChipStack();
    gCarbonDioxideConcentrationMeasurementInstance.SetMeasuredValue(chip::app::DataModel::MakeNullable(float(matter_co2)));
	PlatformMgr().UnlockChipStack();

I'm hoping to see this still running as I come to work tomorrow. If that works I will try to add all the other attribute updates back with the same protection around the matter code. All the examples seem to have a very complex way of structuring the code that I'm having a hard time following. They mostly seem to work with work queues somehow but I have not found a good way to integrate all that with my own code. Ideally I want to just have two functions that my application calls: init and update. I just want to periodically call update to push new sensor values to matter and that's it.

Tiit

RE: Matter subscription fails after some time causing weird state

Maria Gilje — Wed, 15 Oct 2025 14:05:08 GMT

Hi Tiit,

Thank you for your patience.

[quote user="Tiit Ratsep"]Yes, I'm setting up subscriptions in interactive mode. And they do seem to work for a while. And then they randomly stop and I can't subscribe again until I restart the board.[/quote]

Thank you for confirming. We will need to do some more investigations on what could be the cause for the subscription stopping after a while.

[quote user="Tiit Ratsep"]

First the memory report that comes after compiling (that looks ok to me):

Memory region Used Size Region Size %age Used
FLASH: 841456 B 982528 B 85.64%
RAM: 214861 B 256 KB 81.96%
IDT_LIST: 0 GB 32 KB 0.00%

[/quote]

I agree, they seem to be at an OK usage percentage.

[quote user="Tiit Ratsep"]And now the RAM report from the memory report tool that is a bit difficult to share here. But it does say that the total used memory is 288.25 KB which does not seem good. But I don't know how to optimize that.[/quote]

We have a general guide for memory footprint optimization which could be of help here.

[quote user="Tiit Ratsep"]The largest buffers seem to be mostly Matter and Thread which are created by the SDK I guess. I can probably reduce Heap as I don't really use that at all. Maybe I can optimize the stack size of the threads we use (and main) but those are tiny compared to the huge buffers. Do you think this may be the issue? How does it even work at all if the memory use is so much higher than the actual RAM in the SOC. I'm not really sure how variables inside function scope work in Zephyr - are they always allocated or are the temporary variables stored in the stack? I can't really see how big the stack grows here but if the memory is already low maybe stack hits something important in RAM and that's when it breaks? Can you suggest something to debug this situation?[/quote]

I need more time to look into this, but in the mean time some general debugging tips are found in Lesson 2 from the nRF Connect SDK Intermediate course.

Best regards,

Maria

RE: Matter subscription fails after some time causing weird state

Tiit — Mon, 13 Oct 2025 07:47:22 GMT

Hi Maria,

Yes, I'm setting up subscriptions in interactive mode. And they do seem to work for a while. And then they randomly stop and I can't subscribe again until I restart the board.

I have actually never tried the memory report thing before. I took a long time to generate but honestly I don't know how to read that. I will try to share it here so you can look at it and say if this looks ok.

First the memory report that comes after compiling (that looks ok to me):

Memory region Used Size Region Size %age Used
FLASH: 841456 B 982528 B 85.64%
RAM: 214861 B 256 KB 81.96%
IDT_LIST: 0 GB 32 KB 0.00%

And now the RAM report from the memory report tool that is a bit difficult to share here. But it does say that the total used memory is 288.25 KB which does not seem good. But I don't know how to optimize that.

The largest buffers seem to be mostly Matter and Thread which are created by the SDK I guess. I can probably reduce Heap as I don't really use that at all. Maybe I can optimize the stack size of the threads we use (and main) but those are tiny compared to the huge buffers. Do you think this may be the issue? How does it even work at all if the memory use is so much higher than the actual RAM in the SOC. I'm not really sure how variables inside function scope work in Zephyr - are they always allocated or are the temporary variables stored in the stack? I can't really see how big the stack grows here but if the memory is already low maybe stack hits something important in RAM and that's when it breaks? Can you suggest something to debug this situation?

Tiit

RE: Matter subscription fails after some time causing weird state

Maria Gilje — Fri, 10 Oct 2025 12:59:11 GMT

Hi Tiit,

[quote user=""]1. Why does the device always delete the previous subscription when I add a new one? Is this expected behaviour?[/quote]

This seems odd. It should be possible for the chip-tool or other Matter controllers to have several subscriptions running, as long as the subscriber-publisher pair is unique. I'll report this internally to check if anyone else has seen similar issues.

Edit: Just to be sure, you are setting up the subscriptions in interactive mode, right?

[quote user=""]2. Why does the device become unresponsive like this?[/quote]

Like you hypothesize this could be because of memory. What does the memory reports in your build log show? High percentages in that table are good indicators that the device is running out of memory. If this is the case, then make sure that you are using good practices to free up memory where possible.

Best regards,

Maria