BLE Bonding after power cycle

RE: BLE Bonding after power cycle

Hung Bui — Fri, 21 Mar 2025 12:43:07 GMT

Hi Subu,
I'm not so familiar with the Matter code so I don't have an idea what could be wrong. But you may have to step into the code and check whty NOMEM is returned.
There could be an issue on the configuration of the Bluetooth ID.

I quote here an answer from one of my colleague. She made a sample for this, the code following is provided as is.
======

Matter uses an advertising arbiter, which manually sets the Bluetooth ID for the advertisement set to be that of the Matter Bluetooth services ID (BLEAdvertisingArbiter.cpp#L63). This arbiter does not provide support for using extended advertisement with multiple advertisement sets.

I have discussed this with the developers, who agreed that the best solution would be to pass the Bluetooth ID as part of an advertising request structure to the InsertRequest() method. You can see an example usage of the InsertRequest() method in the NUSService::Init() and NusService:StartServer() functions in the Matter NUS service (bt_nus_service.cpp#L47-L106). However, this requires changing the Matter SDK files, which I would normally not recommend. The developers are looking into addressing this issue, but I cannot comment on the schedule since this needs to be prioritized against other tasks.

In the meantime, one option is not to use the arbiter; instead, you can handle the advertisement yourself directly in the service using the extended advertisement API.
For bonding and extended advertisement, the following configurations must be set

You need to set the following in prj.conf:

CONFIG_BT_BONDABLE=y
CONFIG_BT_EXT_ADV=y
CONFIG_BT_EXT_ADV_MAX_ADV_SET=2
CONFIG_BT_SETTINGS=y

Additionally, you should create a config called BT_ID_MAX in the project Kconfig file and set the default value to 2.

config BT_ID_MAX
	default 2

For the code itself, using the NUS service as an example, you would have to replace parts of bt_nus_service.cpp. The following code should create an advertisement set for Bluetooth ID 0, which supports bonding:

#define MATTER_NUS_DEVICE_NAME "MatterNUS"
static struct bt_le_ext_adv *nus_adv;

static struct bt_le_adv_param nus_adv_param = {
	.id = BT_ID_DEFAULT,
	.options = BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_USE_NAME,
	.interval_min = BT_GAP_ADV_FAST_INT_MIN_2, /* 100 ms */
	.interval_max = BT_GAP_ADV_FAST_INT_MAX_2, /* 150 ms */
};

static const struct bt_data nus_ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_NUS_VAL),
};

static int nus_advertise()
{
	int err;
	struct bt_le_ext_adv_start_param ext_adv_start_param = {0};

	err = bt_set_name(MATTER_NUS_DEVICE_NAME);
	if (err) {
		LOG_ERR("Failed to set device name (err %d)", err);
		return err;
	}

	err = bt_le_ext_adv_create(&nus_adv_param, NULL, &nus_adv);

	if (err) {
		LOG_ERR("Failed to create advertising data (err %d)", err);
		return err;
	}
	
	err = bt_le_ext_adv_set_data(nus_adv, nus_ad, ARRAY_SIZE(nus_ad),
				     NULL, 0);
	if (err) {
		LOG_ERR("Failed to set advertising data (err %d)", err);
		return err;
	}

	return bt_le_ext_adv_start(nus_adv, &ext_adv_start_param);
}

This code is not thoroughly tested or qualified and should be considered provided “as-is”. I have tested that this works with bonding by calling advertising_set_create() instead of InsertRequest() in StartServer(). There are still some issues with the code, and it does not play well with the Matter Bluetooth services right now, but I hope it can help as a starting point.

I also recommend looking at the Bluetooth: Multiple advertising sets to see how the extended advertisement API is used there.

====

RE: BLE Bonding after power cycle

SubuMuthu — Thu, 20 Mar 2025 15:10:07 GMT

Hi Huang Bui,

Thanks for the answers.

On #2,

we do not have any IO capabilities in the product. The BLE is the only means of connection.
When the customer installs the product or wants to configure the product, BLE/mobile app is used.
The ("custom") BLE is always active. Event if it is shutdown, it will be temporary.
BLE is also used to start the Matter commissioner (which will start the Matter BLE services). This is one of the reason for me to use the Matter Arbiter.
1. After BLE initiate the Matter commissioner, the product joins the Matter/Thread network and expect to work with Matter/Thread and also with the "custom" BLE service.

I have implemented the extended BLE advertisement as you recommended but the Matter commissioner does not start. To summarize,

BLE stack is initialized, advertises and connects to mobile. Mobile performs the initial configuration and then, sends a custom message to the lock to start the Matter commissioner.

The matter commissioning fails. I have disconnected the BLE connection before starting the matter commissioner , stopped the Advertisement and it does not help!

Starting Matter Commissioner 
I: 4967 [DIS]Updating services using commissioning mode 1
E: 4972 [DIS]Failed to remove advertised services: 3
I: 4977 [DIS]Advertise commission parameter vendorID=65521 productID=32774 discriminator=3840/15 cm=1 cp=0
E: 4986 [DIS]Failed to advertise commissionable node: 3
E: 4991 [DIS]Failed to finalize service update: 3
E: No valid legacy adv
E: 4998 [DL]Failed to start CHIPoBLE advertising: -12
I: 5002 [DL]CHIPoBLE advertising already stopped
E: 5007 [DL]Could not start CHIPoBLE service due to error: 200000c

The above was tested using Matter Door lock sample. The error code -12 indicates ENOM - out of memory. Do I need to increase stack size?

Thanks

RE: BLE Bonding after power cycle

Hung Bui — Thu, 20 Mar 2025 14:24:30 GMT

Hi Subu,

I don't see a problem with approach #1. You can also implement a timer, if after a certain time the link it not secured with level 2 , you can terminate the connection. To remove only one bond you can use bt_unpair(). You can specify the exact address you want to unbond. I believe the function will also terminate the connection.

Please give more info on issue #2. You plan to add the Matter BLE service after the link is secured ? My suggestion is to instead make sure the service has been configured to require encryption (security level 2 and up). You can be sure that it will only be accessible if the link is encrypted. Then you can have the timer. It's better than dynamically add and remove services which is more complicated and may not be supported by the peer ( to rediscover the attribute table).

RE: BLE Bonding after power cycle

SubuMuthu — Wed, 19 Mar 2025 22:35:20 GMT

H Hung Bui,

It works and i am able to verify it in my application. Appreciate the quick response.

Two more questions:

#1.

Sometime, the security level is not reached (I set Level 2: Unauthenticated pairing, and only Security level of 1 is reached). When it happens, the BLE connection is not terminated and both Lock and the App remain connected till the App disconnects. This is not good for us and we would like the BLE connection to terminate and restart.

What is the best way to restart the advertisement? I have implemented the below.

1. In security_changed call back, detect the error aka if the level is 1 or not.

2. If the level is 1,

- remove the bond (is there a way to remove the current bond only, preserving the rest?).

- unref the current connection.

- initiate a disconnect.

- restart the adv.

Is there a better way to do this? Sometimes, the app and lock reconnect, but the security level is not reached and it goes through repeated disconnect -> connect -> fail loop.

#2.

When Matter's BLE service is started, will there be an issue since Matter BLE is handled by Arbiter which gives priority to Matter BLE service. we plan to start and stop the Matter BLE service.

Subu

RE: BLE Bonding after power cycle

Hung Bui — Mon, 17 Mar 2025 12:48:02 GMT

Hi Subu Muthu,
If you take a look at this ticket: RE: Adding custom BLE services to Matter

You can find that "Bonding cannot be enabled for Matter BLE services, as this makes it non-compliant with the Matter specification due to the requirement that a static random address shall be used for Matter BLE service advertising purposes."

So when you reset your device the address (static random address) will be changed and the phone won't be able to detect the board as previously bonded and will make a new bond as you already noticed.

One option to solve the issue is not to use the Matter's arbiter; instead, you can handle the advertisement yourself directly in the service using the extended advertisement API. You would need to create one extra Bluetooth ID and use this Bluetooth ID to do advertising with the address that the peer can recognize (either static address or resolvable random address.