1# Licensed to the Apache Software Foundation (ASF) under one 2# or more contributor license agreements. See the NOTICE file 3# distributed with this work for additional information 4# regarding copyright ownership. The ASF licenses this file 5# to you under the Apache License, Version 2.0 (the 6# "License"); you may not use this file except in compliance 7# with the License. You may obtain a copy of the License at 8# 9# http://www.apache.org/licenses/LICENSE-2.0 10# 11# Unless required by applicable law or agreed to in writing, 12# software distributed under the License is distributed on an 13# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY 14# KIND, either express or implied. See the License for the 15# specific language governing permissions and limitations 16# under the License. 17# 18 19syscfg.defs: 20 BLE_MESH_PROV: 21 description: > 22 Enable provisioning. It is automatically enabled whenever 23 BLE_MESH_PB_ADV or BLE_MESH_PB_GATT is set. 24 value: 1 25 26 BLE_MESH_PB_ADV: 27 description: > 28 Enable this option to allow the device to be provisioned over 29 the advertising bearer. 30 value: 1 31 32 BLE_MESH_PROXY: 33 description: > 34 Enable proxy. This is automatically set whenever BLE_MESH_PB_GATT or 35 BLE_MESH_GATT_PROXY is set. 36 value: 0 37 38 BLE_MESH_PB_GATT: 39 description: > 40 Enable this option to allow the device to be provisioned over 41 the GATT bearer. 42 value: 1 43 44 BLE_MESH_GATT_PROXY: 45 description: > 46 This option enables support for the Mesh GATT Proxy Service, 47 i.e. the ability to act as a proxy between a Mesh GATT Client 48 and a Mesh network. 49 value: 1 50 51 BLE_MESH_NODE_ID_TIMEOUT: 52 description: > 53 This option determines for how long the local node advertises 54 using Node Identity. The given value is in seconds. The 55 specification limits this to 60 seconds, and implies that to 56 be the appropriate value as well, so just leaving this as the 57 default is the safest option. 58 value: 60 59 60 BLE_MESH_PROXY_FILTER_SIZE: 61 descryption: > 62 This option specifies how many Proxy Filter entries the local 63 node supports. 64 value: 1 65 66 BLE_MESH_SUBNET_COUNT: 67 description: > 68 This option specifies how many subnets a Mesh network can 69 participate in at the same time. 70 value: 1 71 72 BLE_MESH_APP_KEY_COUNT: 73 description: > 74 This option specifies how many application keys the device can 75 store per network. 76 value: 1 77 78 BLE_MESH_MODEL_KEY_COUNT: 79 description: > 80 This option specifies how many application keys each model can 81 at most be bound to. 82 value: 1 83 84 BLE_MESH_MODEL_GROUP_COUNT: 85 description: > 86 This option specifies how many group addresses each model can 87 at most be subscribed to. 88 value: 1 89 90 BLE_MESH_LABEL_COUNT: 91 description: > 92 This option specifies how many Label UUIDs can be stored. 93 value: 1 94 95 BLE_MESH_CRPL: 96 description: > 97 This options specifies the maximum capacity of the replay 98 protection list. This option is similar to the network message 99 cache size, but has a different purpose. 100 value: 10 101 102 BLE_MESH_ADV_TASK_PRIO: 103 description: > 104 Advertising task prio (FIXME) 105 type: task_priority 106 value: 9 107 108 BLE_MESH_MSG_CACHE_SIZE: 109 description: > 110 Number of messages that are cached for the network. This description 111 prevent unnecessary decryption operations and unnecessary 112 relays. This option is similar to the replay protection list, 113 but has a different purpose. 114 value: 10 115 116 BLE_MESH_ADV_BUF_COUNT: 117 description: > 118 Number of advertising buffers available. This should be chosen 119 based on what kind of features the local node shoule have. E.g. 120 a relay will perform better the more buffers it has. Another 121 thing to consider is outgoing segmented messages. There must 122 be at least three more advertising buffers than the maximum 123 supported outgoing segment count (BT_MESH_TX_SEG_MAX). 124 value: 6 125 126 BLE_MESH_IVU_DIVIDER: 127 description: > 128 When the IV Update state enters Normal operation or IV Update 129 in Progress, we need to keep track of how many hours has passed 130 in the state, since the specification requires us to remain in 131 the state at least for 96 hours (Update in Progress has an 132 additional upper limit of 144 hours). 133 134 In order to fulfil the above requirement, even if the node might 135 be powered off once in a while, we need to store persistently 136 how many hours the node has been in the state. This doesn't 137 necessarily need to happen every hour (thanks to the flexible 138 duration range). The exact cadence will depend a lot on the 139 ways that the node will be used and what kind of power source it 140 has. 141 142 Since there is no single optimal answer, this configuration 143 option allows specifying a divider, i.e. how many intervals 144 the 96 hour minimum gets split into. After each interval the 145 duration that the node has been in the current state gets 146 stored to flash. E.g. the default value of 4 means that the 147 state is saved every 24 hours (96 / 4). 148 value: 4 149 150 BLE_MESH_TX_SEG_MSG_COUNT: 151 description: > 152 Maximum number of simultaneous outgoing multi-segment and/or 153 reliable messages. 154 value: 4 155 156 BLE_MESH_RX_SEG_MSG_COUNT: 157 description: > 158 Maximum number of simultaneous incoming multi-segment and/or 159 reliable messages. 160 value: 2 161 162 BLE_MESH_RX_SDU_MAX: 163 description: > 164 Maximum incoming Upper Transport Access PDU length. This 165 determines also how many segments incoming segmented messages 166 can have. Each segment can contain 12 bytes, so this value should 167 be set to a multiple of 12 to avoid wasted memory. The minimum 168 requirement is 2 segments (24 bytes) whereas the maximum supported 169 by the Mesh specification is 32 segments (384 bytes). 170 value: 72 171 172 BLE_MESH_TX_SEG_MAX: 173 description: > 174 Maximum number of segments supported for outgoing messages. 175 This value should typically be fine-tuned based on what 176 models the local node supports, i.e. what's the largest 177 message payload that the node needs to be able to send. 178 This value affects memory and call stack consumption, which 179 is why the default is lower than the maximum that the 180 specification would allow (32 segments). 181 182 The maximum outgoing SDU size is 12 times this number (out of 183 which 4 or 8 bytes is used for the Transport Layer MIC). For 184 example, 5 segments means the maximum SDU size is 60 bytes, 185 which leaves 56 bytes for application layer data using a 186 4-byte MIC and 52 bytes using an 8-byte MIC. 187 188 Be sure to specify a sufficient number of advertising buffers 189 when setting this option to a higher value. There must be at 190 least three more advertising buffers (BT_MESH_ADV_BUF_COUNT) 191 as there are outgoing segments. 192 value: 3 193 194 BLE_MESH_RELAY: 195 description: > 196 Support for acting as a Mesh Relay Node. 197 value: 0 198 199 BLE_MESH_LOW_POWER: 200 description: > 201 Enable this option to be able to act as a Low Power Node. 202 value: 0 203 204 BLE_MESH_LPN_ESTABLISHMENT: 205 description: > 206 Perform the Friendship establishment using low power, with 207 the help of a reduced scan duty cycle. The downside of this 208 is that the node may miss out on messages intended for it 209 until it has successfully set up Friendship with a Friend 210 node. 211 value: 1 212 213 BLE_MESH_LPN_AUTO: 214 description: > 215 Automatically enable LPN functionality once provisioned and start 216 looking for Friend nodes. If this option is disabled LPN mode 217 needs to be manually enabled by calling bt_mesh_lpn_set(true). 218 node. 219 value: 1 220 221 BLE_MESH_LPN_AUTO_TIMEOUT: 222 description: > 223 Time in seconds from the last received message, that the node 224 will wait before starting to look for Friend nodes. 225 value: 15 226 227 BLE_MESH_LPN_RETRY_TIMEOUT: 228 description: > 229 Time in seconds between Friend Requests, if a previous Friend 230 Request did not receive any acceptable Friend Offers. 231 value: 8 232 233 BLE_MESH_LPN_RSSI_FACTOR: 234 description: > 235 The contribution of the RSSI measured by the Friend node used 236 in Friend Offer Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5. 237 value: 0 238 239 BLE_MESH_LPN_RECV_WIN_FACTOR: 240 description: > 241 The contribution of the supported Receive Window used in 242 Friend Offer Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5. 243 value: 0 244 245 BLE_MESH_LPN_MIN_QUEUE_SIZE: 246 description: > 247 The MinQueueSizeLog field is defined as log_2(N), where N is 248 the minimum number of maximum size Lower Transport PDUs that 249 the Friend node can store in its Friend Queue. As an example, 250 MinQueueSizeLog value 1 gives N = 2, and value 7 gives N = 128. 251 value: 1 252 253 BLE_MESH_LPN_RECV_DELAY: 254 description: > 255 The ReceiveDelay is the time between the Low Power node 256 sending a request and listening for a response. This delay 257 allows the Friend node time to prepare the response. The value 258 is in units of milliseconds. 259 value: 100 260 261 BLE_MESH_LPN_POLL_TIMEOUT: 262 description: > 263 PollTimeout timer is used to measure time between two 264 consecutive requests sent by the Low Power node. If no 265 requests are received by the Friend node before the 266 PollTimeout timer expires, then the friendship is considered 267 terminated. The value is in units of 100 milliseconds, so e.g. 268 a value of 300 means 30 seconds. 269 value: 300 270 271 BLE_MESH_LPN_INIT_POLL_TIMEOUT: 272 description: > 273 The initial value of the PollTimeout timer when Friendship 274 gets established for the first time. After this the timeout 275 will gradually grow toward the actual PollTimeout, doubling 276 in value for each iteration. The value is in units of 100 277 milliseconds, so e.g. a value of 300 means 3 seconds. 278 value: MYNEWT_VAL_BLE_MESH_LPN_POLL_TIMEOUT 279 280 BLE_MESH_LPN_SCAN_LATENCY: 281 description: > 282 Latency in milliseconds that it takes to enable scanning. This 283 is in practice how much time in advance before the Receive Window 284 that scanning is requested to be enabled. 285 value: 10 286 287 BLE_MESH_LPN_GROUPS: 288 description: > 289 Maximum number of groups that the LPN can subscribe to. 290 value: 10 291 292 BLE_MESH_FRIEND: 293 description: > 294 Enable this option to be able to act as a Friend Node. 295 value: 0 296 297 BLE_MESH_FRIEND_RECV_WIN: 298 description: > 299 Receive Window in milliseconds supported by the Friend node. 300 value: 255 301 302 BLE_MESH_FRIEND_QUEUE_SIZE: 303 description: > 304 Minimum number of buffers available to be stored for each 305 local Friend Queue. 306 value: 16 307 308 BLE_MESH_FRIEND_SUB_LIST_SIZE: 309 description: > 310 Size of the Subscription List that can be supported by a 311 Friend node for a Low Power node. 312 value: 3 313 314 BLE_MESH_FRIEND_LPN_COUNT: 315 description: > 316 Number of Low Power Nodes the Friend can have a Friendship 317 with simultaneously. 318 value: 2 319 320 BLE_MESH_FRIEND_SEG_RX: 321 description: > 322 Number of incomplete segment lists that we track for each LPN 323 that we are Friends for. In other words, this determines how 324 many elements we can simultaneously be receiving segmented 325 messages from when the messages are going into the Friend queue. 326 value: 1 327 328 BLE_MESH_CFG_CLI: 329 description: > 330 Enable support for the configuration client model. 331 value: 0 332 333 BLE_MESH_HEALTH_CLI: 334 description: > 335 Enable support for the health client model. 336 value: 0 337 338 BLE_MESH_SHELL: 339 description: > 340 Activate shell module that provides Bluetooth Mesh commands to 341 the console. 342 value: 0 343 344 BLE_MESH_DEBUG: 345 description: > 346 Use this option to enable debug logs for the Bluetooth 347 Mesh functionality. 348 value: 0 349 350 BLE_MESH_DEBUG_NET: 351 description: > 352 Use this option to enable Network layer debug logs for the 353 Bluetooth Mesh functionality. 354 value: 0 355 356 BLE_MESH_DEBUG_TRANS: 357 description: > 358 Use this option to enable Transport layer debug logs for the 359 Bluetooth Mesh functionality. 360 value: 0 361 362 BLE_MESH_DEBUG_BEACON: 363 description: > 364 Use this option to enable Beacon-related debug logs for the 365 Bluetooth Mesh functionality. 366 value: 0 367 368 BLE_MESH_DEBUG_CRYPTO: 369 description: > 370 Use this option to enable cryptographic debug logs for the 371 Bluetooth Mesh functionality. 372 value: 0 373 374 BLE_MESH_DEBUG_PROV: 375 description: > 376 Use this option to enable Provisioning debug logs for the 377 Bluetooth Mesh functionality. 378 value: 0 379 380 BLE_MESH_DEBUG_ACCESS: 381 description: > 382 Use this option to enable Access layer and device composition 383 related debug logs for Bluetooth Mesh. 384 value: 0 385 386 BLE_MESH_DEBUG_MODEL: 387 description: > 388 Use this option to enable debug logs for the Foundation 389 Models. 390 value: 0 391 392 BLE_MESH_DEBUG_ADV: 393 description: > 394 Use this option to enable advertising debug logs for 395 the Bluetooth Mesh functionality. 396 value: 0 397 398 BLE_MESH_DEBUG_LOW_POWER: 399 description: > 400 Use this option to enable Low Power debug logs for the 401 Bluetooth Mesh functionality. 402 value: 0 403 404 BLE_MESH_DEBUG_FRIEND: 405 description: > 406 Use this option to enable Friend debug logs for the 407 Bluetooth Mesh functionality. 408 value: 0 409 410 BLE_MESH_DEBUG_PROXY: 411 description: > 412 Use this option to enable Proxy protocol debug logs. 413 value: 0 414 415 BLE_MESH_DEBUG_SETTINGS: 416 description: > 417 Use this option to enable persistent settings debug logs. 418 value: 1 419 420 BLE_MESH_IV_UPDATE_TEST: 421 description: > 422 This option removes the 96 hour limit of the IV Update 423 Procedure and lets the state be changed at any time. 424 value: 0 425 426 BLE_MESH_TESTING: 427 description: > 428 This option enables testing API. 429 value: 0 430 431 BLE_MESH_DEV_UUID: 432 description: > 433 Device UUID 434 value: ((uint8_t[16]){0x11, 0x22, 0}) 435 436 BLE_MESH_SHELL_MODELS: 437 description: > 438 Include implementation of some demo models. 439 value: 0 440 441 BLE_MESH_OOB_OUTPUT_ACTIONS: 442 description: > 443 Supported Output OOB Actions 444 BT_MESH_NO_OUTPUT = 0, 445 BT_MESH_BLINK = BIT(0) 446 BT_MESH_BEEP = BIT(1) 447 BT_MESH_VIBRATE = BIT(2) 448 BT_MESH_DISPLAY_NUMBER = BIT(3) 449 BT_MESH_DISPLAY_STRING = BIT(4) 450 value: ((BT_MESH_DISPLAY_NUMBER)) 451 452 BLE_MESH_OOB_OUTPUT_SIZE: 453 description: > 454 Output OOB size 455 value: 4 456 457 BLE_MESH_OOB_INPUT_ACTIONS: 458 description: > 459 Supported Input OOB Actions 460 BT_MESH_NO_INPUT = 0, 461 BT_MESH_PUSH = BIT(0) 462 BT_MESH_TWIST = BIT(1) 463 BT_MESH_ENTER_NUMBER = BIT(2) 464 BT_MESH_ENTER_STRING = BIT(3) 465 value: ((BT_MESH_NO_INPUT)) 466 467 BLE_MESH_OOB_INPUT_SIZE: 468 description: > 469 Input OOB size 470 value: 4 471 472 BLE_MESH_SETTINGS: 473 description: > 474 This option enables Mesh settings storage. 475 value: 1 476 477 BLE_MESH_STORE_TIMEOUT: 478 description: > 479 This value defines in seconds how soon any pending changes 480 are actually written into persistent storage (flash) after 481 a change occurs. 482 value: 2 483 484 BLE_MESH_SEQ_STORE_RATE: 485 description: > 486 This value defines how often the local sequence number gets 487 updated in persistent storage (i.e. flash). E.g. a value of 100 488 means that the sequence number will be stored to flash on every 489 100th increment. If the node sends messages very frequently a 490 higher value makes more sense, whereas if the node sends 491 infrequently a value as low as 0 (update storage for every 492 increment) can make sense. When the stack gets initialized it 493 will add this number to the last stored one, so that it starts 494 off with a value that's guaranteed to be larger than the last 495 one used before power off. 496 value: 128 497 498 BLE_MESH_RPL_STORE_TIMEOUT: 499 description: > 500 This value defines in seconds how soon the RPL gets written to 501 persistent storage after a change occurs. If the node receives 502 messages frequently it may make sense to have this set to a 503 large value, whereas if the RPL gets updated infrequently a 504 value as low as 0 (write immediately) may make sense. Note that 505 if the node operates a security sensitive use case, and there's 506 a risk of sudden power loss, it may be a security vulnerability 507 to set this value to anything else than 0 (a power loss before 508 writing to storage exposes the node to potential message 509 replay attacks). 510 value: 5 511 512 BLE_MESH_DEVICE_NAME: 513 description: > 514 This value defines BLE Mesh device/node name. 515 value: '"nimble-mesh-node"' 516 517 BLE_MESH_SYSINIT_STAGE: 518 description: > 519 Primary sysinit stage for BLE mesh functionality. 520 value: 500 521 522 BLE_MESH_SYSINIT_STAGE_SHELL: 523 description: > 524 Secondary sysinit stage for BLE mesh functionality. 525 value: 1000 526 527syscfg.vals.BLE_MESH_SHELL: 528 BLE_MESH_CFG_CLI: 1 529 BLE_MESH_HEALTH_CLI: 1 530 BLE_MESH_IV_UPDATE_TEST: 1 531 532syscfg.vals.BLE_MESH_GATT_PROXY: 533 BLE_MESH_PROXY: 1 534 535syscfg.vals.BLE_MESH_PB_GATT: 536 BLE_MESH_PROXY: 1 537 BLE_MESH_PROV: 1 538 539syscfg.vals.BLE_MESH_PB_ADV: 540 BLE_MESH_PROV: 1 541