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

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

Simonr — Mon, 12 May 2025 10:19:30 GMT

Okay, are you able to establish persistent subscriptions on the SiLabs device reliably? Our devs don't think this is related to BLE as BLE must be turned off after commissioning (BLE referring to service/advertising for Matter).

Best regards,

Simon

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

brobin88 — Fri, 09 May 2025 12:29:24 GMT

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 🙂

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

Simonr — Fri, 09 May 2025 12:14:49 GMT

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

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

brobin88 — Wed, 07 May 2025 19:19:21 GMT

It definitely was working for a while in v2.9.1 of the SDK. If you have a look at my other ticket here:

https://devzone.nordicsemi.com/f/nordic-q-a/120060/matter-generic-switch-not-working-on-reset

Turning on persistent subscriptions did work for a while (sadly I didn't capture the logs) but then suddenly it wasn't working. Then I found some guidance on the Silicon Labs forum that said to restart the Apple TV, which again worked for a while and then wasn't working. Now nothing seems to make a difference.

My Code is quite small so I'll put it in below:

app_task.cpp

#include "app_task.h"

#include "app/matter_init.h"
#include "app/task_executor.h"
#include "board/board.h"
#include "lib/core/CHIPError.h"
#include "lib/support/CodeUtils.h"


#include <setup_payload/OnboardingCodesUtil.h>
#include <app/clusters/identify-server/identify-server.h>
#include <app/clusters/switch-server/switch-server.h>
#include <app-common/zap-generated/attributes/Accessors.h>

#include <zephyr/logging/log.h>

LOG_MODULE_DECLARE(app, CONFIG_CHIP_APP_LOG_LEVEL);

using namespace ::chip;
using namespace ::chip::app;
using namespace ::chip::DeviceLayer;

namespace 
{
constexpr EndpointId kSwitchEndpointId = 1;
constexpr EndpointId kSwitchEndpointId2 = 2;

Identify sIdentify = { kSwitchEndpointId, AppTask::IdentifyStartHandler, AppTask::IdentifyStopHandler,
		Clusters::Identify::IdentifyTypeEnum::kVisibleIndicator };


#define SWITCH_BUTTON_1 DK_BTN2_MSK
#define SWITCH_BUTTON_2 DK_BTN4_MSK

}

void AppTask::IdentifyStartHandler(Identify *)
{
	Nrf::PostTask(
		[] { Nrf::GetBoard().GetLED(Nrf::DeviceLeds::LED2).Blink(Nrf::LedConsts::kIdentifyBlinkRate_ms); });
}

void AppTask::IdentifyStopHandler(Identify *)
{
	Nrf::PostTask([] { Nrf::GetBoard().GetLED(Nrf::DeviceLeds::LED2).Set(false); });
}

void AppTask::ButtonEventHandler(Nrf::ButtonState state, Nrf::ButtonMask hasChanged)
{
	uint8_t currentPosition = 1;
    // Check if the application button (e.g., DK_BTN2) has been released.
    // The button is considered released when its bit is cleared in the current state.
    if ((SWITCH_BUTTON_1 & hasChanged) && !(state & SWITCH_BUTTON_1))
    {
		DeviceLayer::SystemLayer().ScheduleLambda([currentPosition] {
			Clusters::Switch::Attributes::CurrentPosition::Set(kSwitchEndpointId, currentPosition);
			Clusters::SwitchServer::Instance().OnInitialPress(kSwitchEndpointId, currentPosition);
		}); 
    }

    if ((SWITCH_BUTTON_2 & hasChanged) && !(state & SWITCH_BUTTON_2))
    {
		DeviceLayer::SystemLayer().ScheduleLambda([currentPosition] {
			Clusters::Switch::Attributes::CurrentPosition::Set(kSwitchEndpointId2, currentPosition);
			Clusters::SwitchServer::Instance().OnInitialPress(kSwitchEndpointId2, currentPosition);
		}); 
    }
}

CHIP_ERROR AppTask::Init()
{
	/* Initialize Matter stack */
	ReturnErrorOnFailure(Nrf::Matter::PrepareServer());

	if (!Nrf::GetBoard().Init(ButtonEventHandler)) {
		LOG_ERR("User interface initialization failed.");
		return CHIP_ERROR_INCORRECT_STATE;
	}

	/* Register Matter event handler that controls the connectivity status LED based on the captured Matter network
	 * state. */
	ReturnErrorOnFailure(Nrf::Matter::RegisterEventHandler(Nrf::Board::DefaultMatterEventHandler, 0));

	return Nrf::Matter::StartServer();
}

CHIP_ERROR AppTask::StartApp()
{
	ReturnErrorOnFailure(Init());

	while (true) {
		Nrf::DispatchNextTask();
	}

	return CHIP_NO_ERROR;
}

prj.conf

# Enable CHIP
CONFIG_CHIP=y
CONFIG_CHIP_PROJECT_CONFIG="src/chip_project_config.h"
# 32768 == 0x8000 (example Product ID added temporaly,
# but it must be changed with proper PID from the list:
# https://github.com/project-chip/connectedhomeip/blob/482e6fd03196a6de45465a90003947ef4b86e0b1/docs/examples/discussion/PID_allocation_for_example_apps.md)
CONFIG_CHIP_DEVICE_PRODUCT_ID=32768
CONFIG_STD_CPP17=y

# Enable Matter pairing automatically on application start.
CONFIG_CHIP_ENABLE_PAIRING_AUTOSTART=y

# Enable Matter extended announcement and increase duration to 1 hour.
CONFIG_CHIP_BLE_EXT_ADVERTISING=y
CONFIG_CHIP_BLE_ADVERTISING_DURATION=60

# Add support for LEDs and buttons on Nordic development kits
CONFIG_DK_LIBRARY=y

# Bluetooth Low Energy configuration
CONFIG_BT_DEVICE_NAME="MatterTemplate"

# Other settings
CONFIG_THREAD_NAME=y
CONFIG_MPU_STACK_GUARD=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_CHIP_LIB_SHELL=y
CONFIG_NCS_SAMPLE_MATTER_TEST_SHELL=y

# Disable NFC commissioning
CONFIG_CHIP_NFC_COMMISSIONING=n

# Reduce application size
CONFIG_USE_SEGGER_RTT=n

# Enable Factory Data feature
CONFIG_CHIP_FACTORY_DATA=y
CONFIG_CHIP_FACTORY_DATA_BUILD=y

###############
# Issue occurs with or without persistent subscriptions, 
# power management or ICD config
###############
# Persistent Subscriptions
CONFIG_CHIP_PERSISTENT_SUBSCRIPTIONS=y

# Configure Power Management
CONFIG_PM_DEVICE=y
CONFIG_RAM_POWER_DOWN_LIBRARY=y
CONFIG_POWEROFF=y

# Settings for ICD with LIT
CONFIG_OPENTHREAD_MTD=y
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MTD=y

CONFIG_CHIP_ENABLE_ICD_SUPPORT=y
CONFIG_CHIP_ICD_LIT_SUPPORT=y
CONFIG_CHIP_ICD_IDLE_MODE_DURATION=900
CONFIG_CHIP_ICD_ACTIVE_MODE_DURATION=500
CONFIG_CHIP_ICD_SLOW_POLL_INTERVAL=30000
CONFIG_CHIP_ICD_FAST_POLLING_INTERVAL=1000
CONFIG_CHIP_ICD_ACTIVE_MODE_THRESHOLD=5000
CONFIG_CHIP_ICD_CLIENTS_PER_FABRIC=2

Here are the logs from the nrf52840 when the device is rebooted:

devzone.nordicsemi.com/.../3630.nrf52.log

Here are the logs from the EFR32MG24 when the device is rebooted:

devzone.nordicsemi.com/.../silabs2.log

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

Simonr — Wed, 07 May 2025 13:41:51 GMT

Okay, thank you for clarifying. I'll run this by the developers then. Likely something snuck in one of the latest versions. You haven't by chance caught when this was introduced if it worked fine in older versions of the SDK?

Best regards,

Simon

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

brobin88 — Wed, 07 May 2025 11:04:00 GMT

Also forgot to mention, I’m seeing this behaviour in V2.9.0 and v3.0.0 of the sdk

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

brobin88 — Wed, 07 May 2025 10:59:50 GMT

No This is actually based on the matter template project and I’ve created matter generic switch endpoints. But I think the ble advertising behaviour is embedded in the matter sdk not in the sample code.

If it’s any help I actually see the same behaviour on the esp32-c6 with the esp matter sdk with their icd_app sample project.

i feel like apple has changed something recently because it was working fine on the nrf52840 and now it’s not. For some reason it hasn’t affected the silicon Labs MG24

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

Simonr — Wed, 07 May 2025 09:28:42 GMT

Just to make sure, can you confirm which sample/demo project you're working on here? I'm assuming it is the Matter: Light Switch one, but please confirm before I report this as a bug to the development team.

It should also be possible to enable scanning again after the commissioning is complete to avoid this on your end.

Best regards,

Simon