2019-06-30 04:39:00 -04:00
|
|
|
if BLE_MESH
|
|
|
|
|
|
|
|
config BLE_MESH_HCI_5_0
|
|
|
|
bool "Support sending 20ms non-connectable adv packets"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
It is a temporary solution and needs further modifications.
|
|
|
|
|
|
|
|
config BLE_MESH_USE_DUPLICATE_SCAN
|
|
|
|
bool "Support Duplicate Scan in BLE Mesh"
|
2019-10-21 08:18:21 -04:00
|
|
|
depends on BT_BLUEDROID_ENABLED
|
2020-05-25 04:29:48 -04:00
|
|
|
select BTDM_BLE_SCAN_DUPL
|
|
|
|
select BTDM_BLE_MESH_SCAN_DUPL_EN
|
2019-06-30 04:39:00 -04:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to allow using specific duplicate scan filter
|
2019-10-30 05:01:18 -04:00
|
|
|
in BLE Mesh, and Scan Duplicate Type must be set by choosing the
|
|
|
|
option in the Bluetooth Controller section in menuconfig, which is
|
|
|
|
"Scan Duplicate By Device Address and Advertising Data".
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-07-01 22:53:07 -04:00
|
|
|
choice BLE_MESH_MEM_ALLOC_MODE
|
|
|
|
prompt "Memory allocation strategy"
|
|
|
|
default BLE_MESH_MEM_ALLOC_MODE_INTERNAL
|
2020-01-19 05:57:13 -05:00
|
|
|
help
|
2020-07-01 22:53:07 -04:00
|
|
|
Allocation strategy for BLE Mesh stack, essentially provides ability to
|
|
|
|
allocate all required dynamic allocations from,
|
|
|
|
|
|
|
|
- Internal DRAM memory only
|
|
|
|
- External SPIRAM memory only
|
|
|
|
- Either internal or external memory based on default malloc()
|
|
|
|
behavior in ESP-IDF
|
|
|
|
|
|
|
|
Recommended mode here is always internal, since that is most preferred
|
|
|
|
from security perspective. But if application requirement does not allow
|
|
|
|
sufficient free internal memory then alternate mode can be selected.
|
|
|
|
|
|
|
|
config BLE_MESH_MEM_ALLOC_MODE_INTERNAL
|
|
|
|
bool "Internal DRAM"
|
|
|
|
|
|
|
|
config BLE_MESH_MEM_ALLOC_MODE_EXTERNAL
|
|
|
|
bool "External SPIRAM"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
|
|
|
|
config BLE_MESH_MEM_ALLOC_MODE_DEFAULT
|
|
|
|
bool "Default alloc mode"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
help
|
|
|
|
Enable this option to use the default memory allocation strategy when
|
|
|
|
external SPIRAM is enabled. See the SPIRAM options for more details.
|
|
|
|
|
|
|
|
endchoice # BLE_MESH_MEM_ALLOC_MODE
|
2020-01-19 05:57:13 -05:00
|
|
|
|
2020-07-03 04:33:36 -04:00
|
|
|
config BLE_MESH_FREERTOS_STATIC_ALLOC
|
|
|
|
bool "Enable FreeRTOS static allocation"
|
|
|
|
depends on FREERTOS_SUPPORT_STATIC_ALLOCATION && ESP32_SPIRAM_SUPPORT
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Enable this option to use FreeRTOS static allocation APIs for BLE Mesh,
|
|
|
|
which provides the ability to use different dynamic memory (i.e. SPIRAM)
|
|
|
|
for FreeRTOS objects.
|
|
|
|
If this option is disabled, the FreeRTOS static allocation APIs will not
|
|
|
|
be used, and internal DRAM will be allocated for FreeRTOS objects.
|
|
|
|
|
|
|
|
choice BLE_MESH_FREERTOS_STATIC_ALLOC_MODE
|
|
|
|
prompt "Memory allocation for FreeRTOS objects"
|
|
|
|
depends on BLE_MESH_FREERTOS_STATIC_ALLOC
|
|
|
|
help
|
|
|
|
Choose the memory to be used for FreeRTOS objects.
|
|
|
|
|
|
|
|
config BLE_MESH_FREERTOS_STATIC_ALLOC_EXTERNAL
|
|
|
|
bool "External SPIRAM"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
help
|
|
|
|
If enabled, BLE Mesh allocates dynamic memory from external SPIRAM for
|
|
|
|
FreeRTOS objects, i.e. mutex, queue, and task stack. External SPIRAM
|
|
|
|
can only be used for task stack when SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
|
|
|
|
is enabled. See the SPIRAM options for more details.
|
|
|
|
|
|
|
|
endchoice # BLE_MESH_FREERTOS_STATIC_ALLOC_MODE
|
|
|
|
|
2020-10-15 22:19:31 -04:00
|
|
|
config BLE_MESH_DEINIT
|
|
|
|
bool "Support de-initialize BLE Mesh stack"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
If enabled, users can use the function esp_ble_mesh_deinit() to de-initialize
|
|
|
|
the whole BLE Mesh stack.
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_FAST_PROV
|
|
|
|
bool "Enable BLE Mesh Fast Provisioning"
|
|
|
|
select BLE_MESH_NODE
|
|
|
|
select BLE_MESH_PROVISIONER
|
|
|
|
select BLE_MESH_PB_ADV
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Enable this option to allow BLE Mesh fast provisioning solution to be used.
|
2019-10-30 05:01:18 -04:00
|
|
|
When there are multiple unprovisioned devices around, fast provisioning can
|
|
|
|
greatly reduce the time consumption of the whole provisioning process.
|
|
|
|
When this option is enabled, and after an unprovisioned device is provisioned
|
|
|
|
into a node successfully, it can be changed to a temporary Provisioner.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_NODE
|
|
|
|
bool "Support for BLE Mesh Node"
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Enable the device to be provisioned into a node. This option should be
|
|
|
|
enabled when an unprovisioned device is going to be provisioned into a
|
|
|
|
node and communicate with other nodes in the BLE Mesh network.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_PROVISIONER
|
|
|
|
bool "Support for BLE Mesh Provisioner"
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Enable the device to be a Provisioner. The option should be enabled when
|
|
|
|
a device is going to act as a Provisioner and provision unprovisioned
|
|
|
|
devices into the BLE Mesh network.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
if BLE_MESH_PROVISIONER
|
|
|
|
|
|
|
|
config BLE_MESH_WAIT_FOR_PROV_MAX_DEV_NUM
|
|
|
|
int "Maximum number of unprovisioned devices that can be added to device queue"
|
2020-03-18 03:54:03 -04:00
|
|
|
default 10
|
2019-06-30 04:39:00 -04:00
|
|
|
range 1 100
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This option specifies how many unprovisioned devices can be added to device
|
|
|
|
queue for provisioning. Users can use this option to define the size of the
|
|
|
|
queue in the bottom layer which is used to store unprovisioned device
|
|
|
|
information (e.g. Device UUID, address).
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_MAX_PROV_NODES
|
2019-10-30 05:01:18 -04:00
|
|
|
int "Maximum number of devices that can be provisioned by Provisioner"
|
2020-03-18 03:54:03 -04:00
|
|
|
default 10
|
2019-10-21 10:53:25 -04:00
|
|
|
range 1 1000
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This option specifies how many devices can be provisioned by a Provisioner.
|
|
|
|
This value indicates the maximum number of unprovisioned devices which can be
|
2020-02-12 05:21:09 -05:00
|
|
|
provisioned by a Provisioner. For instance, if the value is 6, it means the
|
2019-10-30 05:01:18 -04:00
|
|
|
Provisioner can provision up to 6 unprovisioned devices.
|
|
|
|
Theoretically a Provisioner without the limitation of its memory can provision
|
|
|
|
up to 32766 unprovisioned devices, here we limit the maximum number to 100
|
|
|
|
just to limit the memory used by a Provisioner. The bigger the value is, the
|
|
|
|
more memory it will cost by a Provisioner to store the information of nodes.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
if BLE_MESH_PB_ADV
|
|
|
|
config BLE_MESH_PBA_SAME_TIME
|
2019-10-30 05:01:18 -04:00
|
|
|
int "Maximum number of PB-ADV running at the same time by Provisioner"
|
2019-06-30 04:39:00 -04:00
|
|
|
default 2
|
|
|
|
range 1 10
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This option specifies how many devices can be provisioned at the same time
|
|
|
|
using PB-ADV. For examples, if the value is 2, it means a Provisioner can
|
|
|
|
provision two unprovisioned devices with PB-ADV at the same time.
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
endif # BLE_MESH_PB_ADV
|
|
|
|
|
|
|
|
if BLE_MESH_PB_GATT
|
|
|
|
config BLE_MESH_PBG_SAME_TIME
|
2019-10-30 05:01:18 -04:00
|
|
|
int "Maximum number of PB-GATT running at the same time by Provisioner"
|
2019-06-30 04:39:00 -04:00
|
|
|
default 1
|
|
|
|
range 1 5
|
|
|
|
help
|
|
|
|
This option specifies how many devices can be provisioned at the same
|
2019-10-30 05:01:18 -04:00
|
|
|
time using PB-GATT. For example, if the value is 2, it means a Provisioner
|
|
|
|
can provision two unprovisioned devices with PB-GATT at the same time.
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
endif # BLE_MESH_PB_GATT
|
|
|
|
|
|
|
|
config BLE_MESH_PROVISIONER_SUBNET_COUNT
|
2019-10-30 05:01:18 -04:00
|
|
|
int "Maximum number of mesh subnets that can be created by Provisioner"
|
2019-06-30 04:39:00 -04:00
|
|
|
default 3
|
|
|
|
range 1 4096
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This option specifies how many subnets per network a Provisioner can create.
|
|
|
|
Indeed, this value decides the number of network keys which can be added by a Provisioner.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_PROVISIONER_APP_KEY_COUNT
|
2019-10-30 05:01:18 -04:00
|
|
|
int "Maximum number of application keys that can be owned by Provisioner"
|
2020-01-19 05:57:13 -05:00
|
|
|
default 3
|
2019-06-30 04:39:00 -04:00
|
|
|
range 1 4096
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This option specifies how many application keys the Provisioner can have.
|
|
|
|
Indeed, this value decides the number of the application keys which can be added by a Provisioner.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-11-16 21:41:15 -05:00
|
|
|
config BLE_MESH_PROVISIONER_RECV_HB
|
|
|
|
bool "Support receiving Heartbeat messages"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When this option is enabled, Provisioner can call specific functions to enable
|
|
|
|
or disable receiving Heartbeat messages and notify them to the application layer.
|
|
|
|
|
|
|
|
if BLE_MESH_PROVISIONER_RECV_HB
|
|
|
|
|
|
|
|
config BLE_MESH_PROVISIONER_RECV_HB_FILTER_SIZE
|
|
|
|
int "Maximum number of filter entries for receiving Heartbeat messages"
|
|
|
|
default 3
|
|
|
|
range 1 1000
|
|
|
|
help
|
|
|
|
This option specifies how many heartbeat filter entries Provisioner supports.
|
|
|
|
The heartbeat filter (acceptlist or rejectlist) entries are used to store a
|
|
|
|
list of SRC and DST which can be used to decide if a heartbeat message will
|
|
|
|
be processed and notified to the application layer by Provisioner.
|
|
|
|
Note: The filter is an empty rejectlist by default.
|
|
|
|
|
|
|
|
endif # BLE_MESH_PROVISIONER_RECV_HB
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
endif # BLE_MESH_PROVISIONER
|
|
|
|
|
|
|
|
# Virtual option enabled whenever Generic Provisioning layer is needed
|
|
|
|
config BLE_MESH_PROV
|
|
|
|
bool "BLE Mesh Provisioning support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to support BLE Mesh Provisioning functionality. For
|
|
|
|
BLE Mesh, this option should be always enabled.
|
|
|
|
|
|
|
|
config BLE_MESH_PB_ADV
|
|
|
|
bool "Provisioning support using the advertising bearer (PB-ADV)"
|
|
|
|
select BLE_MESH_PROV
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over the
|
2019-10-30 05:01:18 -04:00
|
|
|
advertising bearer. This option should be enabled if PB-ADV is
|
|
|
|
going to be used during provisioning procedure.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_PB_GATT
|
|
|
|
bool "Provisioning support using GATT (PB-GATT)"
|
|
|
|
select BLE_MESH_PROXY
|
|
|
|
select BLE_MESH_PROV
|
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over GATT.
|
2019-10-30 05:01:18 -04:00
|
|
|
This option should be enabled if PB-GATT is going to be used during
|
|
|
|
provisioning procedure.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
# Virtual option enabled whenever any Proxy protocol is needed
|
|
|
|
config BLE_MESH_PROXY
|
|
|
|
bool "BLE Mesh Proxy protocol support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to support BLE Mesh Proxy protocol used by PB-GATT
|
|
|
|
and other proxy pdu transmission.
|
|
|
|
|
2019-09-27 05:07:05 -04:00
|
|
|
config BLE_MESH_GATT_PROXY_SERVER
|
|
|
|
bool "BLE Mesh GATT Proxy Server"
|
2019-06-30 04:39:00 -04:00
|
|
|
select BLE_MESH_PROXY
|
2019-10-21 10:53:25 -04:00
|
|
|
depends on BLE_MESH_NODE
|
|
|
|
default y
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
This option enables support for Mesh GATT Proxy Service, i.e. the
|
|
|
|
ability to act as a proxy between a Mesh GATT Client and a Mesh network.
|
2019-10-30 05:01:18 -04:00
|
|
|
This option should be enabled if a node is going to be a Proxy Server.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_NODE_ID_TIMEOUT
|
|
|
|
int "Node Identity advertising timeout"
|
2019-09-27 05:07:05 -04:00
|
|
|
depends on BLE_MESH_GATT_PROXY_SERVER
|
2019-06-30 04:39:00 -04:00
|
|
|
range 1 60
|
|
|
|
default 60
|
|
|
|
help
|
|
|
|
This option determines for how long the local node advertises using
|
|
|
|
Node Identity. The given value is in seconds. The specification limits
|
|
|
|
this to 60 seconds and lists it as the recommended value as well.
|
|
|
|
So leaving the default value is the safest option.
|
2019-10-30 05:01:18 -04:00
|
|
|
When an unprovisioned device is provisioned successfully and becomes a
|
|
|
|
node, it will start to advertise using Node Identity during the time
|
|
|
|
set by this option. And after that, Network ID will be advertised.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-01-19 05:57:13 -05:00
|
|
|
config BLE_MESH_PROXY_FILTER_SIZE
|
|
|
|
int "Maximum number of filter entries per Proxy Client"
|
|
|
|
depends on BLE_MESH_GATT_PROXY_SERVER
|
|
|
|
default 4
|
|
|
|
range 1 32767
|
|
|
|
help
|
|
|
|
This option specifies how many Proxy Filter entries the local node supports.
|
|
|
|
The entries of Proxy filter (whitelist or blacklist) are used to store a
|
|
|
|
list of addresses which can be used to decide which messages will be forwarded
|
|
|
|
to the Proxy Client by the Proxy Server.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-01-19 05:57:13 -05:00
|
|
|
config BLE_MESH_GATT_PROXY_CLIENT
|
|
|
|
bool "BLE Mesh GATT Proxy Client"
|
|
|
|
select BLE_MESH_PROXY
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option enables support for Mesh GATT Proxy Client. The Proxy Client
|
|
|
|
can use the GATT bearer to send mesh messages to a node that supports the
|
|
|
|
advertising bearer.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_NET_BUF_POOL_USAGE
|
2020-10-09 23:05:29 -04:00
|
|
|
bool
|
2019-06-30 04:39:00 -04:00
|
|
|
default y
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Enable BLE Mesh net buffer pool tracking. This option is used to introduce another
|
|
|
|
variable in the bottom layer to record the usage of advertising buffers of BLE Mesh
|
|
|
|
devices. Recommend to enable this option as default.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_SETTINGS
|
2020-01-19 05:57:13 -05:00
|
|
|
bool "Store BLE Mesh configuration persistently"
|
2019-06-30 04:39:00 -04:00
|
|
|
default n
|
|
|
|
help
|
2020-01-19 05:57:13 -05:00
|
|
|
When selected, the BLE Mesh stack will take care of storing/restoring the BLE
|
|
|
|
Mesh configuration persistently in flash.
|
|
|
|
If the device is a BLE Mesh node, when this option is enabled, the configuration
|
|
|
|
of the device will be stored persistently, including unicast address, NetKey,
|
|
|
|
AppKey, etc.
|
|
|
|
And if the device is a BLE Mesh Provisioner, the information of the device will
|
|
|
|
be stored persistently, including the information of provisioned nodes, NetKey,
|
|
|
|
AppKey, etc.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
if BLE_MESH_SETTINGS
|
2020-01-19 05:57:13 -05:00
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_STORE_TIMEOUT
|
|
|
|
int "Delay (in seconds) before storing anything persistently"
|
|
|
|
range 0 1000000
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
This value defines in seconds how soon any pending changes are actually
|
|
|
|
written into persistent storage (flash) after a change occurs.
|
2019-10-30 05:01:18 -04:00
|
|
|
The option allows nodes to delay a certain period of time to save proper
|
|
|
|
information to flash. The default value is 0, which means information
|
|
|
|
will be stored immediately once there are updates.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_SEQ_STORE_RATE
|
|
|
|
int "How often the sequence number gets updated in storage"
|
|
|
|
range 0 1000000
|
2020-09-16 23:22:49 -04:00
|
|
|
default 0
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
This value defines how often the local sequence number gets updated in
|
|
|
|
persistent storage (i.e. flash). e.g. a value of 100 means that the
|
|
|
|
sequence number will be stored to flash on every 100th increment.
|
|
|
|
If the node sends messages very frequently a higher value makes more
|
|
|
|
sense, whereas if the node sends infrequently a value as low as 0
|
|
|
|
(update storage for every increment) can make sense. When the stack
|
|
|
|
gets initialized it will add sequence number to the last stored one,
|
|
|
|
so that it starts off with a value that's guaranteed to be larger than
|
|
|
|
the last one used before power off.
|
|
|
|
|
|
|
|
config BLE_MESH_RPL_STORE_TIMEOUT
|
|
|
|
int "Minimum frequency that the RPL gets updated in storage"
|
|
|
|
range 0 1000000
|
2020-09-16 23:22:49 -04:00
|
|
|
default 0
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
This value defines in seconds how soon the RPL (Replay Protection List)
|
2019-06-30 04:39:00 -04:00
|
|
|
gets written to persistent storage after a change occurs. If the node
|
|
|
|
receives messages frequently, then a large value is recommended. If the
|
|
|
|
node receives messages rarely, then the value can be as low as 0 (which
|
2019-10-30 05:01:18 -04:00
|
|
|
means the RPL is written into the storage immediately).
|
2019-06-30 04:39:00 -04:00
|
|
|
Note that if the node operates in a security-sensitive case, and there is
|
|
|
|
a risk of sudden power-off, then a value of 0 is strongly recommended.
|
|
|
|
Otherwise, a power loss before RPL being written into the storage may
|
|
|
|
introduce message replay attacks and system security will be in a
|
|
|
|
vulnerable state.
|
2019-10-30 05:01:18 -04:00
|
|
|
|
2020-04-04 04:45:40 -04:00
|
|
|
config BLE_MESH_SETTINGS_BACKWARD_COMPATIBILITY
|
|
|
|
bool "A specific option for settings backward compatibility"
|
|
|
|
depends on BLE_MESH_NODE
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option is created to solve the issue of failure in recovering
|
|
|
|
node information after mesh stack updates. In the old version mesh
|
|
|
|
stack, there is no key of "mesh/role" in nvs. In the new version
|
|
|
|
mesh stack, key of "mesh/role" is added in nvs, recovering node
|
|
|
|
information needs to check "mesh/role" key in nvs and implements
|
|
|
|
selective recovery of mesh node information. Therefore, there may
|
|
|
|
be failure in recovering node information during node restarting
|
|
|
|
after OTA.
|
|
|
|
|
|
|
|
The new version mesh stack adds the option of "mesh/role" because
|
|
|
|
we have added the support of storing Provisioner information, while
|
|
|
|
the old version only supports storing node information.
|
|
|
|
|
|
|
|
If users are updating their nodes from old version to new version,
|
|
|
|
we recommend enabling this option, so that system could set the flag
|
|
|
|
in advance before recovering node information and make sure the node
|
|
|
|
information recovering could work as expected.
|
|
|
|
|
2020-11-24 07:51:09 -05:00
|
|
|
config BLE_MESH_SPECIFIC_PARTITION
|
|
|
|
bool "Use a specific NVS partition for BLE Mesh"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When selected, the mesh stack will use a specified NVS partition instead of
|
|
|
|
default NVS partition. Note that the specified partition must be registered
|
|
|
|
with NVS using nvs_flash_init_partition() API, and the partition must exists
|
|
|
|
in the csv file.
|
|
|
|
When Provisioner needs to store a large amount of nodes' information in the
|
|
|
|
flash (e.g. more than 20), this option is recommended to be enabled.
|
|
|
|
|
|
|
|
config BLE_MESH_PARTITION_NAME
|
|
|
|
string "Name of the NVS partition for BLE Mesh"
|
|
|
|
depends on BLE_MESH_SPECIFIC_PARTITION
|
|
|
|
default "ble_mesh"
|
|
|
|
help
|
|
|
|
This value defines the name of the specified NVS partition used by the
|
|
|
|
mesh stack.
|
|
|
|
|
|
|
|
config BLE_MESH_USE_MULTIPLE_NAMESPACE
|
|
|
|
bool "Support using multiple NVS namespaces by Provisioner"
|
|
|
|
depends on BLE_MESH_PROVISIONER
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When selected, Provisioner can use different NVS namespaces to store
|
|
|
|
different instances of mesh information.
|
|
|
|
For example, if in the first room, Provisioner uses NetKey A, AppKey
|
|
|
|
A and provisions three devices, these information will be treated as
|
|
|
|
mesh information instance A. When the Provisioner moves to the second
|
|
|
|
room, it uses NetKey B, AppKey B and provisions two devices, then the
|
|
|
|
information will be treated as mesh information instance B.
|
|
|
|
Here instance A and instance B will be stored in different namespaces.
|
|
|
|
With this option enabled, Provisioner needs to use specific functions
|
|
|
|
to open the corresponding NVS namespace, restore the mesh information,
|
|
|
|
release the mesh information or erase the mesh information.
|
|
|
|
|
|
|
|
config BLE_MESH_MAX_NVS_NAMESPACE
|
|
|
|
int "Maximum number of NVS namespaces"
|
|
|
|
depends on BLE_MESH_USE_MULTIPLE_NAMESPACE
|
|
|
|
default 2
|
|
|
|
range 1 255
|
|
|
|
help
|
|
|
|
This option specifies the maximum NVS namespaces supported by Provisioner.
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
endif # if BLE_MESH_SETTINGS
|
|
|
|
|
|
|
|
config BLE_MESH_SUBNET_COUNT
|
|
|
|
int "Maximum number of mesh subnets per network"
|
|
|
|
default 3
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many subnets a Mesh network can have at the same time.
|
2019-10-30 05:01:18 -04:00
|
|
|
Indeed, this value decides the number of the network keys which can be owned by a node.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_APP_KEY_COUNT
|
|
|
|
int "Maximum number of application keys per network"
|
|
|
|
default 3
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys the device can store per network.
|
2019-10-30 05:01:18 -04:00
|
|
|
Indeed, this value decides the number of the application keys which can be owned by a node.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_MODEL_KEY_COUNT
|
|
|
|
int "Maximum number of application keys per model"
|
|
|
|
default 3
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies the maximum number of application keys to which each model
|
|
|
|
can be bound.
|
|
|
|
|
|
|
|
config BLE_MESH_MODEL_GROUP_COUNT
|
|
|
|
int "Maximum number of group address subscriptions per model"
|
|
|
|
default 3
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies the maximum number of addresses to which each model can
|
|
|
|
be subscribed.
|
|
|
|
|
|
|
|
config BLE_MESH_LABEL_COUNT
|
|
|
|
int "Maximum number of Label UUIDs used for Virtual Addresses"
|
|
|
|
default 3
|
|
|
|
range 0 4096
|
|
|
|
help
|
|
|
|
This option specifies how many Label UUIDs can be stored.
|
2019-10-30 05:01:18 -04:00
|
|
|
Indeed, this value decides the number of the Virtual Addresses can be supported by a node.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_CRPL
|
|
|
|
int "Maximum capacity of the replay protection list"
|
|
|
|
default 10
|
|
|
|
range 2 65535
|
|
|
|
help
|
|
|
|
This option specifies the maximum capacity of the replay protection list.
|
|
|
|
It is similar to Network message cache size, but has a different purpose.
|
2019-10-30 05:01:18 -04:00
|
|
|
The replay protection list is used to prevent a node from replay attack,
|
|
|
|
which will store the source address and sequence number of the received
|
|
|
|
mesh messages.
|
2020-03-18 03:54:03 -04:00
|
|
|
For Provisioner, the replay protection list size should not be smaller than
|
|
|
|
the maximum number of nodes whose information can be stored. And the element
|
|
|
|
number of each node should also be taken into consideration. For example, if
|
|
|
|
Provisioner can provision up to 20 nodes and each node contains two elements,
|
|
|
|
then the replay protection list size of Provisioner should be at least 40.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_MSG_CACHE_SIZE
|
|
|
|
int "Network message cache size"
|
|
|
|
default 10
|
|
|
|
range 2 65535
|
|
|
|
help
|
|
|
|
Number of messages that are cached for the network. This helps prevent
|
|
|
|
unnecessary decryption operations and unnecessary relays. This option
|
|
|
|
is similar to Replay protection list, but has a different purpose.
|
2019-10-30 05:01:18 -04:00
|
|
|
A node is not required to cache the entire Network PDU and may cache
|
|
|
|
only part of it for tracking, such as values for SRC/SEQ or others.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_ADV_BUF_COUNT
|
|
|
|
int "Number of advertising buffers"
|
|
|
|
default 60
|
|
|
|
range 6 256
|
|
|
|
help
|
|
|
|
Number of advertising buffers available. The transport layer reserves
|
|
|
|
ADV_BUF_COUNT - 3 buffers for outgoing segments. The maximum outgoing
|
|
|
|
SDU size is 12 times this value (out of which 4 or 8 bytes are used
|
|
|
|
for the Transport Layer MIC). For example, 5 segments means the maximum
|
|
|
|
SDU size is 60 bytes, which leaves 56 bytes for application layer data
|
|
|
|
using a 4-byte MIC, or 52 bytes using an 8-byte MIC.
|
|
|
|
|
2020-02-13 06:41:42 -05:00
|
|
|
config BLE_MESH_SUPPORT_BLE_ADV
|
|
|
|
bool "Support sending normal BLE advertising packets"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When selected, users can send normal BLE advertising packets
|
|
|
|
with specific API.
|
|
|
|
|
|
|
|
if BLE_MESH_SUPPORT_BLE_ADV
|
|
|
|
|
|
|
|
config BLE_MESH_BLE_ADV_BUF_COUNT
|
|
|
|
int "Number of advertising buffers for BLE advertising packets"
|
|
|
|
default 3
|
|
|
|
range 1 255
|
|
|
|
help
|
|
|
|
Number of advertising buffers for BLE packets available.
|
|
|
|
|
|
|
|
endif # BLE_MESH_SUPPORT_BLE_ADV
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_IVU_DIVIDER
|
|
|
|
int "Divider for IV Update state refresh timer"
|
|
|
|
default 4
|
|
|
|
range 2 96
|
|
|
|
help
|
|
|
|
When the IV Update state enters Normal operation or IV Update
|
|
|
|
in Progress, we need to keep track of how many hours has passed
|
|
|
|
in the state, since the specification requires us to remain in
|
|
|
|
the state at least for 96 hours (Update in Progress has an
|
|
|
|
additional upper limit of 144 hours).
|
|
|
|
|
|
|
|
In order to fulfill the above requirement, even if the node might
|
|
|
|
be powered off once in a while, we need to store persistently
|
|
|
|
how many hours the node has been in the state. This doesn't
|
|
|
|
necessarily need to happen every hour (thanks to the flexible
|
|
|
|
duration range). The exact cadence will depend a lot on the
|
|
|
|
ways that the node will be used and what kind of power source it
|
|
|
|
has.
|
|
|
|
|
|
|
|
Since there is no single optimal answer, this configuration
|
|
|
|
option allows specifying a divider, i.e. how many intervals
|
|
|
|
the 96 hour minimum gets split into. After each interval the
|
|
|
|
duration that the node has been in the current state gets
|
|
|
|
stored to flash. E.g. the default value of 4 means that the
|
|
|
|
state is saved every 24 hours (96 / 4).
|
|
|
|
|
|
|
|
config BLE_MESH_TX_SEG_MSG_COUNT
|
|
|
|
int "Maximum number of simultaneous outgoing segmented messages"
|
|
|
|
default 1
|
|
|
|
range 1 BLE_MESH_ADV_BUF_COUNT
|
|
|
|
help
|
|
|
|
Maximum number of simultaneous outgoing multi-segment and/or reliable messages.
|
2019-10-30 05:01:18 -04:00
|
|
|
The default value is 1, which means the device can only send one segmented
|
|
|
|
message at a time. And if another segmented message is going to be sent, it
|
|
|
|
should wait for the completion of the previous one.
|
|
|
|
If users are going to send multiple segmented messages at the same time, this
|
|
|
|
value should be configured properly.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_RX_SEG_MSG_COUNT
|
|
|
|
int "Maximum number of simultaneous incoming segmented messages"
|
|
|
|
default 1
|
|
|
|
range 1 255
|
|
|
|
help
|
|
|
|
Maximum number of simultaneous incoming multi-segment and/or reliable messages.
|
2019-10-30 05:01:18 -04:00
|
|
|
The default value is 1, which means the device can only receive one segmented
|
|
|
|
message at a time. And if another segmented message is going to be received,
|
|
|
|
it should wait for the completion of the previous one.
|
|
|
|
If users are going to receive multiple segmented messages at the same time, this
|
|
|
|
value should be configured properly.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_RX_SDU_MAX
|
|
|
|
int "Maximum incoming Upper Transport Access PDU length"
|
|
|
|
default 384
|
|
|
|
range 36 384
|
|
|
|
help
|
|
|
|
Maximum incoming Upper Transport Access PDU length. Leave this to the default
|
|
|
|
value, unless you really need to optimize memory usage.
|
|
|
|
|
|
|
|
config BLE_MESH_TX_SEG_MAX
|
|
|
|
int "Maximum number of segments in outgoing messages"
|
2020-01-19 05:57:13 -05:00
|
|
|
default 32
|
2019-06-30 04:39:00 -04:00
|
|
|
range 2 32
|
|
|
|
help
|
|
|
|
Maximum number of segments supported for outgoing messages.
|
|
|
|
This value should typically be fine-tuned based on what
|
|
|
|
models the local node supports, i.e. what's the largest
|
|
|
|
message payload that the node needs to be able to send.
|
|
|
|
This value affects memory and call stack consumption, which
|
|
|
|
is why the default is lower than the maximum that the
|
|
|
|
specification would allow (32 segments).
|
|
|
|
|
|
|
|
The maximum outgoing SDU size is 12 times this number (out of
|
|
|
|
which 4 or 8 bytes is used for the Transport Layer MIC). For
|
|
|
|
example, 5 segments means the maximum SDU size is 60 bytes,
|
|
|
|
which leaves 56 bytes for application layer data using a
|
|
|
|
4-byte MIC and 52 bytes using an 8-byte MIC.
|
|
|
|
|
|
|
|
Be sure to specify a sufficient number of advertising buffers
|
|
|
|
when setting this option to a higher value. There must be at
|
|
|
|
least three more advertising buffers (BLE_MESH_ADV_BUF_COUNT)
|
|
|
|
as there are outgoing segments.
|
|
|
|
|
|
|
|
config BLE_MESH_RELAY
|
|
|
|
bool "Relay support"
|
2019-10-21 10:53:25 -04:00
|
|
|
depends on BLE_MESH_NODE
|
|
|
|
default y
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Support for acting as a Mesh Relay Node. Enabling this option will allow
|
|
|
|
a node to support the Relay feature, and the Relay feature can still
|
|
|
|
be enabled or disabled by proper configuration messages. Disabling this
|
|
|
|
option will let a node not support the Relay feature.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2019-09-17 07:30:35 -04:00
|
|
|
if BLE_MESH_RELAY
|
|
|
|
|
|
|
|
config BLE_MESH_RELAY_ADV_BUF
|
|
|
|
bool "Use separate advertising buffers for relay packets"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
When selected, self-send packets will be put in a high-priority
|
|
|
|
queue and relay packets will be put in a low-priority queue.
|
|
|
|
|
|
|
|
if BLE_MESH_RELAY_ADV_BUF
|
|
|
|
|
|
|
|
config BLE_MESH_RELAY_ADV_BUF_COUNT
|
|
|
|
int "Number of advertising buffers for relay packets"
|
|
|
|
default 60
|
|
|
|
range 6 256
|
|
|
|
help
|
|
|
|
Number of advertising buffers for relay packets available.
|
|
|
|
|
|
|
|
endif # BLE_MESH_RELAY_ADV_BUF
|
|
|
|
|
|
|
|
endif # BLE_MESH_RELAY
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_LOW_POWER
|
|
|
|
bool "Support for Low Power features"
|
2019-10-21 10:53:25 -04:00
|
|
|
depends on BLE_MESH_NODE
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Enable this option to operate as a Low Power Node. If low power consumption
|
|
|
|
is required by a node, this option should be enabled. And once the node
|
|
|
|
enters the mesh network, it will try to find a Friend node and establish a
|
|
|
|
friendship.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
if BLE_MESH_LOW_POWER
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_ESTABLISHMENT
|
|
|
|
bool "Perform Friendship establishment using low power"
|
2019-09-17 04:32:27 -04:00
|
|
|
default n
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
Perform the Friendship establishment using low power with the help of a
|
|
|
|
reduced scan duty cycle. The downside of this is that the node may miss
|
|
|
|
out on messages intended for it until it has successfully set up Friendship
|
|
|
|
with a Friend node.
|
2019-10-30 05:01:18 -04:00
|
|
|
When this option is enabled, the node will stop scanning for a period of
|
|
|
|
time after a Friend Request or Friend Poll is sent, so as to reduce more
|
|
|
|
power consumption.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LPN_AUTO
|
|
|
|
bool "Automatically start looking for Friend nodes once provisioned"
|
2019-09-17 04:32:27 -04:00
|
|
|
default n
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
Once provisioned, automatically enable LPN functionality and start looking
|
|
|
|
for Friend nodes. If this option is disabled LPN mode needs to be manually
|
|
|
|
enabled by calling bt_mesh_lpn_set(true).
|
2019-10-30 05:01:18 -04:00
|
|
|
When an unprovisioned device is provisioned successfully and becomes a node,
|
|
|
|
enabling this option will trigger the node starts to send Friend Request at
|
|
|
|
a certain period until it finds a proper Friend node.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LPN_AUTO_TIMEOUT
|
|
|
|
int "Time from last received message before going to LPN mode"
|
|
|
|
default 15
|
|
|
|
range 0 3600
|
|
|
|
depends on BLE_MESH_LPN_AUTO
|
|
|
|
help
|
|
|
|
Time in seconds from the last received message, that the node waits out
|
|
|
|
before starting to look for Friend nodes.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_RETRY_TIMEOUT
|
2019-09-17 04:32:27 -04:00
|
|
|
int "Retry timeout for Friend requests"
|
|
|
|
default 6
|
2019-06-30 04:39:00 -04:00
|
|
|
range 1 3600
|
|
|
|
help
|
|
|
|
Time in seconds between Friend Requests, if a previous Friend Request did
|
|
|
|
not yield any acceptable Friend Offers.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_RSSI_FACTOR
|
|
|
|
int "RSSIFactor, used in Friend Offer Delay calculation"
|
|
|
|
range 0 3
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
The contribution of the RSSI, measured by the Friend node, used in Friend
|
|
|
|
Offer Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5.
|
2019-10-30 05:01:18 -04:00
|
|
|
RSSIFactor, one of the parameters carried by Friend Request sent by Low Power
|
|
|
|
node, which is used to calculate the Friend Offer Delay.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LPN_RECV_WIN_FACTOR
|
|
|
|
int "ReceiveWindowFactor, used in Friend Offer Delay calculation"
|
|
|
|
range 0 3
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
The contribution of the supported Receive Window used in Friend Offer
|
|
|
|
Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5.
|
2019-10-30 05:01:18 -04:00
|
|
|
ReceiveWindowFactor, one of the parameters carried by Friend Request sent by
|
|
|
|
Low Power node, which is used to calculate the Friend Offer Delay.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LPN_MIN_QUEUE_SIZE
|
|
|
|
int "Minimum size of the acceptable friend queue (MinQueueSizeLog)"
|
|
|
|
range 1 7
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
The MinQueueSizeLog field is defined as log_2(N), where N is the minimum
|
|
|
|
number of maximum size Lower Transport PDUs that the Friend node can store
|
|
|
|
in its Friend Queue. As an example, MinQueueSizeLog value 1 gives N = 2,
|
|
|
|
and value 7 gives N = 128.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_RECV_DELAY
|
|
|
|
int "Receive delay requested by the local node"
|
|
|
|
range 10 255
|
|
|
|
default 100
|
|
|
|
help
|
|
|
|
The ReceiveDelay is the time between the Low Power node sending a
|
|
|
|
request and listening for a response. This delay allows the Friend
|
|
|
|
node time to prepare the response. The value is in units of milliseconds.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_POLL_TIMEOUT
|
|
|
|
int "The value of the PollTimeout timer"
|
|
|
|
range 10 244735
|
|
|
|
default 300
|
|
|
|
help
|
|
|
|
PollTimeout timer is used to measure time between two consecutive
|
|
|
|
requests sent by a Low Power node. If no requests are received
|
|
|
|
the Friend node before the PollTimeout timer expires, then the
|
|
|
|
friendship is considered terminated. The value is in units of 100
|
|
|
|
milliseconds, so e.g. a value of 300 means 30 seconds.
|
2019-10-30 05:01:18 -04:00
|
|
|
The smaller the value, the faster the Low Power node tries to get
|
|
|
|
messages from corresponding Friend node and vice versa.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LPN_INIT_POLL_TIMEOUT
|
|
|
|
int "The starting value of the PollTimeout timer"
|
|
|
|
range 10 BLE_MESH_LPN_POLL_TIMEOUT
|
|
|
|
default BLE_MESH_LPN_POLL_TIMEOUT
|
|
|
|
help
|
|
|
|
The initial value of the PollTimeout timer when Friendship is to be
|
|
|
|
established for the first time. After this, the timeout gradually
|
|
|
|
grows toward the actual PollTimeout, doubling in value for each iteration.
|
|
|
|
The value is in units of 100 milliseconds, so e.g. a value of 300 means
|
|
|
|
30 seconds.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_SCAN_LATENCY
|
|
|
|
int "Latency for enabling scanning"
|
|
|
|
range 0 50
|
|
|
|
default 10
|
|
|
|
help
|
|
|
|
Latency (in milliseconds) is the time it takes to enable scanning. In
|
|
|
|
practice, it means how much time in advance of the Receive Window, the
|
|
|
|
request to enable scanning is made.
|
|
|
|
|
|
|
|
config BLE_MESH_LPN_GROUPS
|
|
|
|
int "Number of groups the LPN can subscribe to"
|
|
|
|
range 0 16384
|
2019-10-21 10:53:25 -04:00
|
|
|
default 8
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
Maximum number of groups to which the LPN can subscribe.
|
2019-10-30 05:01:18 -04:00
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
endif # BLE_MESH_LOW_POWER
|
|
|
|
|
|
|
|
config BLE_MESH_FRIEND
|
2019-12-06 02:34:18 -05:00
|
|
|
bool "Support for Friend feature"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
|
|
|
Enable this option to be able to act as a Friend Node.
|
|
|
|
|
|
|
|
if BLE_MESH_FRIEND
|
|
|
|
|
|
|
|
config BLE_MESH_FRIEND_RECV_WIN
|
|
|
|
int "Friend Receive Window"
|
|
|
|
range 1 255
|
|
|
|
default 255
|
|
|
|
help
|
|
|
|
Receive Window in milliseconds supported by the Friend node.
|
|
|
|
|
|
|
|
config BLE_MESH_FRIEND_QUEUE_SIZE
|
|
|
|
int "Minimum number of buffers supported per Friend Queue"
|
|
|
|
range 2 65536
|
|
|
|
default 16
|
|
|
|
help
|
|
|
|
Minimum number of buffers available to be stored for each local Friend Queue.
|
2019-10-30 05:01:18 -04:00
|
|
|
This option decides the size of each buffer which can be used by a Friend node
|
|
|
|
to store messages for each Low Power node.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_FRIEND_SUB_LIST_SIZE
|
|
|
|
int "Friend Subscription List Size"
|
|
|
|
range 0 1023
|
|
|
|
default 3
|
|
|
|
help
|
|
|
|
Size of the Subscription List that can be supported by a Friend node for a
|
2019-10-30 05:01:18 -04:00
|
|
|
Low Power node. And Low Power node can send Friend Subscription List Add or
|
|
|
|
Friend Subscription List Remove messages to the Friend node to add or remove
|
|
|
|
subscription addresses.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_FRIEND_LPN_COUNT
|
|
|
|
int "Number of supported LPN nodes"
|
|
|
|
range 1 1000
|
|
|
|
default 2
|
|
|
|
help
|
|
|
|
Number of Low Power Nodes with which a Friend can have Friendship simultaneously.
|
2019-10-30 05:01:18 -04:00
|
|
|
A Friend node can have friendship with multiple Low Power nodes at the same time,
|
|
|
|
while a Low Power node can only establish friendship with only one Friend node at
|
|
|
|
the same time.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_FRIEND_SEG_RX
|
|
|
|
int "Number of incomplete segment lists per LPN"
|
|
|
|
range 1 1000
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
Number of incomplete segment lists tracked for each Friends' LPN.
|
|
|
|
In other words, this determines from how many elements can segmented
|
|
|
|
messages destined for the Friend queue be received simultaneously.
|
|
|
|
|
|
|
|
endif # BLE_MESH_FRIEND
|
|
|
|
|
|
|
|
config BLE_MESH_NO_LOG
|
|
|
|
bool "Disable BLE Mesh debug logs (minimize bin size)"
|
|
|
|
depends on BLE_MESH
|
|
|
|
default n
|
|
|
|
help
|
2019-10-30 05:01:18 -04:00
|
|
|
Select this to save the BLE Mesh related rodata code size. Enabling this option
|
|
|
|
will disable the output of BLE Mesh debug log.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
menu "BLE Mesh STACK DEBUG LOG LEVEL"
|
|
|
|
depends on BLE_MESH && !BLE_MESH_NO_LOG
|
|
|
|
|
|
|
|
choice BLE_MESH_STACK_TRACE_LEVEL
|
|
|
|
prompt "BLE_MESH_STACK"
|
|
|
|
default BLE_MESH_TRACE_LEVEL_WARNING
|
|
|
|
depends on BLE_MESH && !BLE_MESH_NO_LOG
|
|
|
|
help
|
|
|
|
Define BLE Mesh trace level for BLE Mesh stack.
|
|
|
|
|
|
|
|
config BLE_MESH_TRACE_LEVEL_NONE
|
|
|
|
bool "NONE"
|
|
|
|
config BLE_MESH_TRACE_LEVEL_ERROR
|
|
|
|
bool "ERROR"
|
|
|
|
config BLE_MESH_TRACE_LEVEL_WARNING
|
|
|
|
bool "WARNING"
|
|
|
|
config BLE_MESH_TRACE_LEVEL_INFO
|
|
|
|
bool "INFO"
|
|
|
|
config BLE_MESH_TRACE_LEVEL_DEBUG
|
|
|
|
bool "DEBUG"
|
|
|
|
config BLE_MESH_TRACE_LEVEL_VERBOSE
|
|
|
|
bool "VERBOSE"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config BLE_MESH_STACK_TRACE_LEVEL
|
|
|
|
int
|
|
|
|
depends on BLE_MESH
|
|
|
|
default 0 if BLE_MESH_TRACE_LEVEL_NONE
|
|
|
|
default 1 if BLE_MESH_TRACE_LEVEL_ERROR
|
|
|
|
default 2 if BLE_MESH_TRACE_LEVEL_WARNING
|
|
|
|
default 3 if BLE_MESH_TRACE_LEVEL_INFO
|
|
|
|
default 4 if BLE_MESH_TRACE_LEVEL_DEBUG
|
|
|
|
default 5 if BLE_MESH_TRACE_LEVEL_VERBOSE
|
|
|
|
default 2
|
|
|
|
|
|
|
|
endmenu #BLE Mesh DEBUG LOG LEVEL
|
|
|
|
|
|
|
|
menu "BLE Mesh NET BUF DEBUG LOG LEVEL"
|
|
|
|
depends on BLE_MESH && !BLE_MESH_NO_LOG
|
|
|
|
|
|
|
|
choice BLE_MESH_NET_BUF_TRACE_LEVEL
|
|
|
|
prompt "BLE_MESH_NET_BUF"
|
|
|
|
default BLE_MESH_NET_BUF_TRACE_LEVEL_WARNING
|
|
|
|
depends on BLE_MESH && !BLE_MESH_NO_LOG
|
|
|
|
help
|
|
|
|
Define BLE Mesh trace level for BLE Mesh net buffer.
|
|
|
|
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_NONE
|
|
|
|
bool "NONE"
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_ERROR
|
|
|
|
bool "ERROR"
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_WARNING
|
|
|
|
bool "WARNING"
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_INFO
|
|
|
|
bool "INFO"
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_DEBUG
|
|
|
|
bool "DEBUG"
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL_VERBOSE
|
|
|
|
bool "VERBOSE"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config BLE_MESH_NET_BUF_TRACE_LEVEL
|
|
|
|
int
|
|
|
|
depends on BLE_MESH
|
|
|
|
default 0 if BLE_MESH_NET_BUF_TRACE_LEVEL_NONE
|
|
|
|
default 1 if BLE_MESH_NET_BUF_TRACE_LEVEL_ERROR
|
|
|
|
default 2 if BLE_MESH_NET_BUF_TRACE_LEVEL_WARNING
|
|
|
|
default 3 if BLE_MESH_NET_BUF_TRACE_LEVEL_INFO
|
|
|
|
default 4 if BLE_MESH_NET_BUF_TRACE_LEVEL_DEBUG
|
|
|
|
default 5 if BLE_MESH_NET_BUF_TRACE_LEVEL_VERBOSE
|
|
|
|
default 2
|
|
|
|
|
|
|
|
endmenu #BLE Mesh NET BUF DEBUG LOG LEVEL
|
|
|
|
|
|
|
|
config BLE_MESH_CLIENT_MSG_TIMEOUT
|
|
|
|
int "Timeout(ms) for client message response"
|
|
|
|
range 100 1200000
|
|
|
|
default 4000
|
|
|
|
help
|
|
|
|
Timeout value used by the node to get response of the acknowledged
|
|
|
|
message which is sent by the client model.
|
2019-10-30 05:01:18 -04:00
|
|
|
This value indicates the maximum time that a client model waits for
|
|
|
|
the response of the sent acknowledged messages. If a client model
|
|
|
|
uses 0 as the timeout value when sending acknowledged messages, then
|
|
|
|
the default value will be used which is four seconds.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-10-19 08:45:34 -04:00
|
|
|
menu "Support for BLE Mesh Foundation models"
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_CFG_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Configuration Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Configuration Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_HEALTH_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Health Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Health Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-10-19 09:12:17 -04:00
|
|
|
config BLE_MESH_HEALTH_SRV
|
|
|
|
bool "Health Server model"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for Health Server model.
|
|
|
|
|
2020-10-19 08:45:34 -04:00
|
|
|
endmenu #Support for BLE Mesh Foundation models
|
|
|
|
|
|
|
|
menu "Support for BLE Mesh Client/Server models"
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_GENERIC_ONOFF_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic OnOff Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic OnOff Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_LEVEL_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Level Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Level Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_DEF_TRANS_TIME_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Default Transition Time Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Default Transition Time Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_POWER_ONOFF_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Power OnOff Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Power OnOff Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_POWER_LEVEL_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Power Level Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Power Level Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_BATTERY_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Battery Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Battery Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_LOCATION_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Location Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Location Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_PROPERTY_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Generic Property Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Generic Property Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_SENSOR_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Sensor Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Sensor Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_TIME_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Time Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Time Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_SCENE_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Scene Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Scene Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_SCHEDULER_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Scheduler Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Scheduler Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LIGHT_LIGHTNESS_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Light Lightness Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Light Lightness Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LIGHT_CTL_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Light CTL Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Light CTL Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LIGHT_HSL_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Light HSL Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Light HSL Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LIGHT_XYL_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Light XYL Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Light XYL Client model.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_LIGHT_LC_CLI
|
2020-10-16 04:10:28 -04:00
|
|
|
bool "Light LC Client model"
|
2019-06-30 04:39:00 -04:00
|
|
|
help
|
2020-10-16 04:10:28 -04:00
|
|
|
Enable support for Light LC Client model.
|
|
|
|
|
|
|
|
config BLE_MESH_GENERIC_SERVER
|
|
|
|
bool "Generic server models"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for Generic server models.
|
|
|
|
|
|
|
|
config BLE_MESH_SENSOR_SERVER
|
|
|
|
bool "Sensor server models"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for Sensor server models.
|
|
|
|
|
|
|
|
config BLE_MESH_TIME_SCENE_SERVER
|
|
|
|
bool "Time and Scenes server models"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for Time and Scenes server models.
|
|
|
|
|
|
|
|
config BLE_MESH_LIGHTING_SERVER
|
|
|
|
bool "Lighting server models"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for Lighting server models.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
2020-10-19 08:45:34 -04:00
|
|
|
endmenu #Support for BLE Mesh Client/Server models
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
config BLE_MESH_IV_UPDATE_TEST
|
|
|
|
bool "Test the IV Update Procedure"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option removes the 96 hour limit of the IV Update Procedure and
|
|
|
|
lets the state to be changed at any time.
|
2019-10-30 05:01:18 -04:00
|
|
|
If IV Update test mode is going to be used, this option should be enabled.
|
2019-06-30 04:39:00 -04:00
|
|
|
|
|
|
|
menu "BLE Mesh specific test option"
|
|
|
|
|
|
|
|
config BLE_MESH_SELF_TEST
|
|
|
|
bool "Perform BLE Mesh self-tests"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
This option adds extra self-tests which are run every time BLE Mesh
|
|
|
|
networking is initialized.
|
|
|
|
|
2020-03-11 00:01:57 -04:00
|
|
|
if BLE_MESH_SELF_TEST
|
|
|
|
|
|
|
|
config BLE_MESH_TEST_AUTO_ENTER_NETWORK
|
|
|
|
bool "Unprovisioned device enters mesh network automatically"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
With this option enabled, an unprovisioned device can automatically
|
|
|
|
enters mesh network using a specific test function without the pro-
|
|
|
|
visioning procedure. And on the Provisioner side, a test function
|
|
|
|
needs to be invoked to add the node information into the mesh stack.
|
|
|
|
|
|
|
|
config BLE_MESH_TEST_USE_WHITE_LIST
|
|
|
|
bool "Use white list to filter mesh advertising packets"
|
|
|
|
default n
|
|
|
|
help
|
2020-05-12 03:31:26 -04:00
|
|
|
With this option enabled, users can use white list to filter mesh
|
2020-03-11 00:01:57 -04:00
|
|
|
advertising packets while scanning.
|
|
|
|
|
|
|
|
endif # BLE_MESH_SELF_TEST
|
|
|
|
|
2019-06-30 04:39:00 -04:00
|
|
|
config BLE_MESH_SHELL
|
|
|
|
bool "Enable BLE Mesh shell"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Activate shell module that provides BLE Mesh commands to the console.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG
|
|
|
|
bool "Enable BLE Mesh debug logs"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Enable debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
if BLE_MESH_DEBUG
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_NET
|
|
|
|
bool "Network layer debug"
|
|
|
|
help
|
|
|
|
Enable Network layer debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_TRANS
|
|
|
|
bool "Transport layer debug"
|
|
|
|
help
|
|
|
|
Enable Transport layer debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_BEACON
|
|
|
|
bool "Beacon debug"
|
|
|
|
help
|
|
|
|
Enable Beacon-related debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_CRYPTO
|
|
|
|
bool "Crypto debug"
|
|
|
|
help
|
|
|
|
Enable cryptographic debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_PROV
|
|
|
|
bool "Provisioning debug"
|
|
|
|
help
|
|
|
|
Enable Provisioning debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_ACCESS
|
|
|
|
bool "Access layer debug"
|
|
|
|
help
|
|
|
|
Enable Access layer debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_MODEL
|
|
|
|
bool "Foundation model debug"
|
|
|
|
help
|
|
|
|
Enable Foundation Models debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_ADV
|
|
|
|
bool "Advertising debug"
|
|
|
|
help
|
|
|
|
Enable advertising debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_LOW_POWER
|
|
|
|
bool "Low Power debug"
|
|
|
|
help
|
|
|
|
Enable Low Power debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_FRIEND
|
|
|
|
bool "Friend debug"
|
|
|
|
help
|
|
|
|
Enable Friend debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
config BLE_MESH_DEBUG_PROXY
|
|
|
|
bool "Proxy debug"
|
|
|
|
depends on BLE_MESH_PROXY
|
|
|
|
help
|
|
|
|
Enable Proxy protocol debug logs for the BLE Mesh functionality.
|
|
|
|
|
|
|
|
endif # BLE_MESH_DEBUG
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
endif # BLE_MESH
|
2019-10-30 05:01:18 -04:00
|
|
|
|