Saving BLE Mesh Settings

RE: Saving BLE Mesh Settings

Mttrinh — Fri, 03 Dec 2021 10:08:56 GMT

Hi,

1. Every RPL entry takes ~35 bytes (excluding NVS overhead). But depending on a use case, mesh configuration and deployment, the bigger network may require more entries in the RPL list. Amount of RPL entries to be stored is controlled by CONFIG_BT_MESH_CRPL. RPL entries are stored in settings partition every CONFIG_BT_MESH_RPL_STORE_TIMEOUT. But setting this to -1 will disable automatic store of pending RPL entries. See: https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BT_MESH_RPL_STORE_TIMEOUT.html?highlight=bt_mesh_rpl_store_timeout You can pass specific address to `bt_mesh_rpl_pending_store` if you don't want to store all entries.

2. I assume that you are referring to db_hash_store? What models are you using?

RE: Saving BLE Mesh Settings

SpencerEtn — Wed, 01 Dec 2021 12:09:50 GMT

Hi,

We're using nRF Connect SDK. I'm using v1.5.1

RE: Saving BLE Mesh Settings

Mttrinh — Tue, 30 Nov 2021 15:02:34 GMT

Hi,

Could you provide me with which mesh SDK you are using and SDK version? nRF5 SDK for Mesh or nRF Connect SDK?

RE: Saving BLE Mesh Settings

SpencerEtn — Mon, 29 Nov 2021 12:36:10 GMT

For more context;

1. Similarly related to the second question, the RPL (replay messages) related information is being written to memory. Can we allocate some max memory for replay messages and what is the default value for size of these messages?

We found that in settings.c the bt_mesh_rpl_pending_store() function was writing RPL stuff but we didn't necessarily want to store so much information in the flash related to replay messages.

2. After provisioning and sending control commands such as like the on/off generic light, etc. we have observed that data is continuously being written to flash one after another. We are wondering if it is really necessary to write this sort of information to flash?

We observed in the gatt.c; an example function is db_hash_store() that will write to the flash memory.