2019-11-01 13:45:29 +01:00
|
|
|
# Bluetooth Mesh configuration options
|
2017-06-16 11:30:54 +02:00
|
|
|
|
|
|
|
# Copyright (c) 2017 Intel Corporation
|
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
menuconfig BT_MESH
|
2017-11-10 13:08:09 +01:00
|
|
|
bool "Bluetooth Mesh support"
|
2017-06-16 11:30:54 +02:00
|
|
|
select TINYCRYPT
|
|
|
|
select TINYCRYPT_AES
|
|
|
|
select TINYCRYPT_AES_CMAC
|
2020-01-29 13:03:23 +01:00
|
|
|
select BT_HOST_CCM
|
2018-06-27 08:54:54 +02:00
|
|
|
depends on BT_OBSERVER && BT_BROADCASTER
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
2017-11-10 13:08:09 +01:00
|
|
|
This option enables Bluetooth Mesh support. The specific
|
|
|
|
features that are available may depend on other features
|
|
|
|
that have been enabled in the stack, such as GATT support.
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
if BT_MESH
|
2017-06-16 11:30:54 +02:00
|
|
|
|
|
|
|
# Virtual option enabled whenever Generic Provisioning layer is needed
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_PROV
|
2017-06-16 11:30:54 +02:00
|
|
|
bool
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_PB_ADV
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Provisioning support using the advertising bearer (PB-ADV)"
|
2017-08-09 08:21:11 +02:00
|
|
|
select BT_MESH_PROV
|
2017-06-16 11:30:54 +02:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over
|
|
|
|
the advertising bearer.
|
|
|
|
|
2019-07-12 15:57:58 +02:00
|
|
|
config BT_MESH_PROVISIONER
|
|
|
|
bool "Provisioner support"
|
|
|
|
select BT_MESH_PROV
|
|
|
|
help
|
|
|
|
Enable this option to have support for provisioning remote devices.
|
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_CDB
|
|
|
|
bool "Mesh Configuration Database [EXPERIMENTAL]"
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
if BT_MESH_CDB
|
|
|
|
|
|
|
|
config BT_MESH_CDB_NODE_COUNT
|
|
|
|
int "Maximum number of nodes in the database"
|
2019-07-12 15:57:58 +02:00
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many nodes each network can at most
|
2019-11-04 16:14:07 +01:00
|
|
|
save in the configuration database.
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_CDB_SUBNET_COUNT
|
|
|
|
int "Maximum number of subnets in the database"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many subnets that can at most be
|
|
|
|
saved in the configuration database.
|
|
|
|
|
|
|
|
config BT_MESH_CDB_APP_KEY_COUNT
|
|
|
|
int "Maximum number of application keys in the database"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys that can at most
|
|
|
|
be saved in the configuration database.
|
|
|
|
|
|
|
|
endif # BT_MESH_CDB
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
if BT_CONN
|
2017-06-16 11:30:54 +02:00
|
|
|
|
|
|
|
# Virtual option enabled whenever any Proxy protocol is needed
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
bool
|
2019-04-25 10:23:14 +02:00
|
|
|
select BT_GATT_DYNAMIC_DB
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_PB_GATT
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Provisioning support using GATT (PB-GATT)"
|
2017-08-09 08:21:11 +02:00
|
|
|
select BT_MESH_PROXY
|
|
|
|
select BT_MESH_PROV
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over
|
|
|
|
GATT.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_GATT_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "GATT Proxy Service"
|
2017-08-09 08:21:11 +02:00
|
|
|
select BT_MESH_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
This option enables support for the Mesh GATT Proxy Service,
|
|
|
|
i.e. the ability to act as a proxy between a Mesh GATT Client
|
|
|
|
and a Mesh network.
|
|
|
|
|
2017-11-27 11:59:55 +01:00
|
|
|
config BT_MESH_NODE_ID_TIMEOUT
|
|
|
|
int "Node Identity advertising timeout"
|
|
|
|
depends on BT_MESH_GATT_PROXY
|
|
|
|
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 implies that to
|
|
|
|
be the appropriate value as well, so just leaving this as the
|
|
|
|
default is the safest option.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_PROXY_FILTER_SIZE
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of filter entries per Proxy Client"
|
2017-08-09 08:21:11 +02:00
|
|
|
default 3 if BT_MESH_GATT_PROXY
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 1
|
2017-06-16 11:30:54 +02:00
|
|
|
range 1 32767
|
kconfig: Replace some single-symbol 'if's with 'depends on'
I think people might be reading differences into 'if' and 'depends on'
that aren't there, like maybe 'if' being needed to "hide" a symbol,
while 'depends on' just adds a dependency.
There are no differences between 'if' and 'depends on'. 'if' is just a
shorthand for 'depends on'. They work the same when it comes to creating
implicit menus too.
The way symbols get "hidden" is through their dependencies not being
satisfied ('if'/'depends on' get copied up as a dependency on the
prompt).
Since 'if' and 'depends on' are the same, an 'if' with just a single
symbol in it can be replaced with a 'depends on'. IMO, it's best to
avoid 'if' there as a style choice too, because it confuses people into
thinking there's deep Kconfig magic going on that requires 'if'.
Going for 'depends on' can also remove some nested 'if's, which
generates nicer symbol information and docs, because nested 'if's really
are so simple/dumb that they just add the dependencies from both 'if's
to all symbols within.
Replace a bunch of single-symbol 'if's with 'depends on' to despam the
Kconfig files a bit and make it clearer how things work. Also do some
other minor related dependency refactoring.
The replacement isn't complete. Will fix up the rest later. Splitting it
a bit to make it more manageable.
(Everything above is true for choices, menus, and comments as well.)
Detected by tweaking the Kconfiglib parsing code. It's impossible to
detect after parsing, because 'if' turns into 'depends on'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-02-08 03:45:50 +01:00
|
|
|
depends on BT_MESH_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
This option specifies how many Proxy Filter entries the local
|
|
|
|
node supports.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
endif # BT_CONN
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_SELF_TEST
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Perform self-tests"
|
|
|
|
help
|
|
|
|
This option adds extra self-tests which are run every time
|
|
|
|
mesh networking is initialized.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_IV_UPDATE_TEST
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Test the IV Update Procedure"
|
|
|
|
help
|
|
|
|
This option removes the 96 hour limit of the IV Update
|
|
|
|
Procedure and lets the state be changed at any time.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_SUBNET_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of mesh subnets per network"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many subnets a Mesh network can
|
|
|
|
participate in at the same time.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_APP_KEY_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of application keys per network"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys the device can
|
|
|
|
store per network.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_MODEL_KEY_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of application keys per model"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys each model can
|
|
|
|
at most be bound to.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_MODEL_GROUP_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of group address subscriptions per model"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many group addresses each model can
|
|
|
|
at most be subscribed to.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LABEL_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of Label UUIDs used for Virtual Addresses"
|
|
|
|
default 1
|
|
|
|
range 0 4096
|
|
|
|
help
|
|
|
|
This option specifies how many Label UUIDs can be stored.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_CRPL
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum capacity of the replay protection list"
|
|
|
|
default 10
|
|
|
|
range 2 65535
|
|
|
|
help
|
|
|
|
This options specifies the maximum capacity of the replay
|
|
|
|
protection list. This option is similar to the network message
|
|
|
|
cache size, but has a different purpose.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_MSG_CACHE_SIZE
|
2017-06-16 11:30:54 +02:00
|
|
|
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 the replay protection list,
|
|
|
|
but has a different purpose.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_ADV_BUF_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Number of advertising buffers"
|
|
|
|
default 6
|
2020-03-05 16:10:15 +01:00
|
|
|
range 3 256
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
2018-07-23 19:47:12 +02:00
|
|
|
Number of advertising buffers available. This should be chosen
|
2018-08-07 23:03:09 +02:00
|
|
|
based on what kind of features the local node should have. E.g.
|
2018-07-23 19:47:12 +02:00
|
|
|
a relay will perform better the more buffers it has. Another
|
|
|
|
thing to consider is outgoing segmented messages. There must
|
|
|
|
be at least three more advertising buffers than the maximum
|
|
|
|
supported outgoing segment count (BT_MESH_TX_SEG_MAX).
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2018-05-15 13:35:07 +02:00
|
|
|
config BT_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).
|
|
|
|
|
2018-05-23 20:53:20 +02:00
|
|
|
In order to fulfill the above requirement, even if the node might
|
2018-05-15 13:35:07 +02:00
|
|
|
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).
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_TX_SEG_MSG_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Maximum number of simultaneous outgoing segmented messages"
|
|
|
|
default 1
|
2020-03-05 16:10:15 +01:00
|
|
|
range 1 255
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Maximum number of simultaneous outgoing multi-segment and/or
|
|
|
|
reliable messages.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_RX_SEG_MSG_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
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.
|
|
|
|
|
2020-03-05 16:10:15 +01:00
|
|
|
config BT_MESH_SEG_BUFS
|
|
|
|
int "Number of segment buffers available"
|
|
|
|
default 64
|
|
|
|
range BT_MESH_RX_SEG_MAX 16384 if BT_MESH_RX_SEG_MAX > \
|
|
|
|
BT_MESH_TX_SEG_MAX
|
|
|
|
range BT_MESH_TX_SEG_MAX 16384
|
2018-07-25 14:39:02 +02:00
|
|
|
help
|
2020-03-05 16:10:15 +01:00
|
|
|
The incoming and outgoing segmented messages allocate their
|
|
|
|
segments from the same pool. Each segment is a 12 byte block,
|
|
|
|
and may only be used by one message at the time.
|
|
|
|
|
|
|
|
Outgoing messages will allocate their segments at the start of the
|
|
|
|
transmission, and release them one by one as soon as they have been
|
|
|
|
acknowledged by the receiver. Incoming messages allocate all their
|
|
|
|
segments at the start of the transaction, and won't release them until
|
|
|
|
the message is fully received.
|
|
|
|
|
|
|
|
config BT_MESH_RX_SEG_MAX
|
|
|
|
int "Maximum number of segments in incoming messages"
|
|
|
|
default 3
|
|
|
|
range 2 32
|
|
|
|
help
|
|
|
|
Maximum number of segments supported for incoming 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 receive.
|
|
|
|
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 incoming 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.
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2018-07-23 19:47:12 +02:00
|
|
|
config BT_MESH_TX_SEG_MAX
|
|
|
|
int "Maximum number of segments in outgoing messages"
|
|
|
|
default 3
|
|
|
|
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.
|
2020-03-05 16:10:15 +01:00
|
|
|
This value affects memory consumption, which is why the
|
|
|
|
default is lower than the maximum that the specification
|
|
|
|
would allow (32 segments).
|
2018-07-23 19:47:12 +02:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_RELAY
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Relay support"
|
|
|
|
help
|
|
|
|
Support for acting as a Mesh Relay Node.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LOW_POWER
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Support for Low Power features"
|
|
|
|
help
|
|
|
|
Enable this option to be able to act as a Low Power Node.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
if BT_MESH_LOW_POWER
|
2017-11-09 09:28:44 +01:00
|
|
|
|
|
|
|
config BT_MESH_LPN_ESTABLISHMENT
|
|
|
|
bool "Perform Friendship establishment using low power"
|
|
|
|
default y
|
|
|
|
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.
|
|
|
|
|
|
|
|
config BT_MESH_LPN_AUTO
|
|
|
|
bool "Automatically start looking for Friend nodes once provisioned"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Automatically enable LPN functionality once provisioned 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).
|
|
|
|
|
|
|
|
config BT_MESH_LPN_AUTO_TIMEOUT
|
|
|
|
int "Time from last received message before going to LPN mode"
|
|
|
|
default 15
|
|
|
|
range 0 3600
|
|
|
|
depends on BT_MESH_LPN_AUTO
|
|
|
|
help
|
|
|
|
Time in seconds from the last received message, that the node
|
|
|
|
will wait before starting to look for Friend nodes.
|
|
|
|
|
|
|
|
config BT_MESH_LPN_RETRY_TIMEOUT
|
|
|
|
int "Retry timeout for Friend requests"
|
|
|
|
default 8
|
|
|
|
range 1 3600
|
|
|
|
help
|
|
|
|
Time in seconds between Friend Requests, if a previous Friend
|
|
|
|
Request did not receive any acceptable Friend Offers.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_RSSI_FACTOR
|
2017-06-16 11:30:54 +02:00
|
|
|
int "RSSIFactor, used in the 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.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_RECV_WIN_FACTOR
|
2017-06-16 11:30:54 +02:00
|
|
|
int "ReceiveWindowFactor, used in the 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.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_MIN_QUEUE_SIZE
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Minimum size of 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.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_RECV_DELAY
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Receive delay requested by the local node"
|
|
|
|
range 10 255
|
2017-11-10 09:47:12 +01:00
|
|
|
default 100
|
2017-06-16 11:30:54 +02:00
|
|
|
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.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_POLL_TIMEOUT
|
2017-11-23 08:48:41 +01:00
|
|
|
int "The value of the PollTimeout timer"
|
2017-06-16 11:30:54 +02:00
|
|
|
range 10 244735
|
2017-11-23 08:48:41 +01:00
|
|
|
default 300
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
PollTimeout timer is used to measure time between two
|
|
|
|
consecutive requests sent by the Low Power node. If no
|
|
|
|
requests are received by the Friend node before the
|
|
|
|
PollTimeout timer expires, then the friendship is considered
|
2017-11-23 08:48:41 +01:00
|
|
|
terminated. The value is in units of 100 milliseconds, so e.g.
|
2018-02-01 18:51:36 +01:00
|
|
|
a value of 300 means 30 seconds.
|
2017-11-23 08:48:41 +01:00
|
|
|
|
|
|
|
config BT_MESH_LPN_INIT_POLL_TIMEOUT
|
|
|
|
int "The starting value of the PollTimeout timer"
|
|
|
|
range 10 BT_MESH_LPN_POLL_TIMEOUT
|
|
|
|
default BT_MESH_LPN_POLL_TIMEOUT
|
|
|
|
help
|
|
|
|
The initial value of the PollTimeout timer when Friendship
|
|
|
|
gets established for the first time. After this the timeout
|
|
|
|
will gradually grow toward the actual PollTimeout, doubling
|
|
|
|
in value for each iteration. The value is in units of 100
|
2017-12-07 15:19:28 +01:00
|
|
|
milliseconds, so e.g. a value of 300 means 30 seconds.
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_SCAN_LATENCY
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Latency for enabling scanning"
|
|
|
|
range 0 50
|
|
|
|
default 10
|
|
|
|
help
|
|
|
|
Latency in milliseconds that it takes to enable scanning. This
|
|
|
|
is in practice how much time in advance before the Receive Window
|
|
|
|
that scanning is requested to be enabled.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_LPN_GROUPS
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Number of groups the LPN can subscribe to"
|
|
|
|
range 0 16384
|
|
|
|
default 8
|
|
|
|
help
|
|
|
|
Maximum number of groups that the LPN can subscribe to.
|
2017-08-09 08:21:11 +02:00
|
|
|
endif # BT_MESH_LOW_POWER
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_FRIEND
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Support for acting as a Friend Node"
|
|
|
|
help
|
|
|
|
Enable this option to be able to act as a Friend Node.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
if BT_MESH_FRIEND
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_FRIEND_RECV_WIN
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Friend Receive Window"
|
|
|
|
range 1 255
|
|
|
|
default 255
|
|
|
|
help
|
|
|
|
Receive Window in milliseconds supported by the Friend node.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_FRIEND_QUEUE_SIZE
|
2017-10-31 15:16:28 +01:00
|
|
|
int "Minimum number of buffers supported per Friend Queue"
|
|
|
|
range 2 65536
|
2017-11-10 09:13:09 +01:00
|
|
|
default 16
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
2017-10-31 15:16:28 +01:00
|
|
|
Minimum number of buffers available to be stored for each
|
|
|
|
local Friend Queue.
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_FRIEND_SUB_LIST_SIZE
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Friend Subscription List Size"
|
2017-10-31 15:16:28 +01:00
|
|
|
range 0 1023
|
|
|
|
default 3
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Size of the Subscription List that can be supported by a
|
|
|
|
Friend node for a Low Power node.
|
|
|
|
|
2020-04-18 09:15:19 +02:00
|
|
|
config BT_MESH_LPN_SUB_ALL_NODES_ADDR
|
|
|
|
bool "Automatically subscribe all nodes address"
|
|
|
|
help
|
|
|
|
Automatically subscribe all nodes address when friendship
|
|
|
|
established.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_FRIEND_LPN_COUNT
|
2017-06-16 11:30:54 +02:00
|
|
|
int "Number of supported LPN nodes"
|
|
|
|
range 1 1000
|
2017-11-10 09:13:09 +01:00
|
|
|
default 2
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Number of Low Power Nodes the Friend can have a Friendship
|
|
|
|
with simultaneously.
|
|
|
|
|
2017-10-31 15:16:28 +01:00
|
|
|
config BT_MESH_FRIEND_SEG_RX
|
|
|
|
int "Number of incomplete segment lists per LPN"
|
|
|
|
range 1 1000
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
Number of incomplete segment lists that we track for each LPN
|
|
|
|
that we are Friends for. In other words, this determines how
|
|
|
|
many elements we can simultaneously be receiving segmented
|
|
|
|
messages from when the messages are going into the Friend queue.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
endif # BT_MESH_FRIEND
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-11-12 12:48:55 +01:00
|
|
|
config BT_MESH_CFG_CLI
|
|
|
|
bool "Support for Configuration Client Model"
|
|
|
|
help
|
|
|
|
Enable support for the configuration client model.
|
|
|
|
|
2017-11-22 07:49:52 +01:00
|
|
|
config BT_MESH_HEALTH_CLI
|
|
|
|
bool "Support for Health Client Model"
|
|
|
|
help
|
|
|
|
Enable support for the health client model.
|
|
|
|
|
2017-11-10 21:17:40 +01:00
|
|
|
config BT_MESH_SHELL
|
|
|
|
bool "Enable Bluetooth Mesh shell"
|
2018-11-06 15:12:08 +01:00
|
|
|
select SHELL
|
2017-11-21 11:36:57 +01:00
|
|
|
depends on BT_MESH_CFG_CLI
|
2017-11-22 07:49:52 +01:00
|
|
|
depends on BT_MESH_HEALTH_CLI
|
2017-11-10 21:17:40 +01:00
|
|
|
help
|
|
|
|
Activate shell module that provides Bluetooth Mesh commands to
|
|
|
|
the console.
|
|
|
|
|
2019-10-18 13:23:06 +02:00
|
|
|
config BT_MESH_MODEL_EXTENSIONS
|
|
|
|
bool "Support for Model extensions"
|
|
|
|
help
|
|
|
|
Enable support for the model extension concept, allowing the Access
|
|
|
|
layer to know about Mesh model relationships.
|
|
|
|
|
2018-05-07 21:22:30 +02:00
|
|
|
if BT_SETTINGS
|
|
|
|
|
2018-05-08 22:34:56 +02:00
|
|
|
config BT_MESH_STORE_TIMEOUT
|
|
|
|
int "Delay (in seconds) before storing anything persistently"
|
|
|
|
range 0 1000000
|
|
|
|
default 2
|
|
|
|
help
|
|
|
|
This value defines in seconds how soon any pending changes
|
|
|
|
are actually written into persistent storage (flash) after
|
|
|
|
a change occurs.
|
|
|
|
|
2018-05-07 21:22:30 +02:00
|
|
|
config BT_MESH_SEQ_STORE_RATE
|
|
|
|
int "How often the sequence number gets updated in storage"
|
|
|
|
range 0 1000000
|
|
|
|
default 128
|
|
|
|
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 this 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 BT_MESH_RPL_STORE_TIMEOUT
|
|
|
|
int "Minimum frequency that the RPL gets updated in storage"
|
|
|
|
range 0 1000000
|
|
|
|
default 5
|
|
|
|
help
|
|
|
|
This value defines in seconds how soon the RPL gets written to
|
|
|
|
persistent storage after a change occurs. If the node receives
|
|
|
|
messages frequently it may make sense to have this set to a
|
|
|
|
large value, whereas if the RPL gets updated infrequently a
|
|
|
|
value as low as 0 (write immediately) may make sense. Note that
|
|
|
|
if the node operates a security sensitive use case, and there's
|
|
|
|
a risk of sudden power loss, it may be a security vulnerability
|
|
|
|
to set this value to anything else than 0 (a power loss before
|
|
|
|
writing to storage exposes the node to potential message
|
|
|
|
replay attacks).
|
|
|
|
|
|
|
|
endif # BT_SETTINGS
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Enable debug logs"
|
2017-08-09 08:21:11 +02:00
|
|
|
depends on BT_DEBUG
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Use this option to enable debug logs for the Bluetooth
|
|
|
|
Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
if BT_MESH_DEBUG
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2018-03-21 08:24:25 +01:00
|
|
|
config BT_MESH_DEBUG_USE_ID_ADDR
|
|
|
|
bool "Use identity address for all advertising"
|
|
|
|
help
|
|
|
|
This option forces the usage of the local identity address for
|
|
|
|
all advertising. This can be a help for debugging (analyzing
|
|
|
|
traces), however it should never be enabled for a production
|
|
|
|
build as it compromises the privacy of the device.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_NET
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Network layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Network layer debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_TRANS
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Transport layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Transport layer debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_BEACON
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Beacon debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Beacon-related debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_CRYPTO
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Crypto debug"
|
|
|
|
help
|
|
|
|
Use this option to enable cryptographic debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_PROV
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Provisioning debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Provisioning debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_ACCESS
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Access layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Access layer and device composition
|
|
|
|
related debug logs for Bluetooth Mesh.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_MODEL
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Foundation model debug"
|
|
|
|
help
|
|
|
|
Use this option to enable debug logs for the Foundation
|
|
|
|
Models.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_ADV
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Advertising debug"
|
|
|
|
help
|
|
|
|
Use this option to enable advertising debug logs for
|
|
|
|
the Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_LOW_POWER
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Low Power debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Low Power debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_FRIEND
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Friend debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Friend debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
config BT_MESH_DEBUG_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
bool "Proxy debug"
|
2017-08-09 08:21:11 +02:00
|
|
|
depends on BT_MESH_PROXY
|
2017-06-16 11:30:54 +02:00
|
|
|
help
|
|
|
|
Use this option to enable Proxy protocol debug logs.
|
|
|
|
|
2018-05-07 08:50:49 +02:00
|
|
|
config BT_MESH_DEBUG_SETTINGS
|
|
|
|
bool "Persistent settings debug"
|
|
|
|
depends on BT_SETTINGS
|
|
|
|
help
|
|
|
|
Use this option to enable persistent settings debug logs.
|
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_DEBUG_CDB
|
|
|
|
bool "Configuration database debug"
|
|
|
|
depends on BT_MESH_CDB
|
|
|
|
help
|
|
|
|
Use this option to enable configuration database debug logs.
|
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
endif # BT_MESH_DEBUG
|
2017-06-16 11:30:54 +02:00
|
|
|
|
2017-08-09 08:21:11 +02:00
|
|
|
endif # BT_MESH
|