:orphan:

.. title:: CONFIG_BT_MESH_SEQ_STORE_RATE

.. kconfig:: CONFIG_BT_MESH_SEQ_STORE_RATE

CONFIG_BT_MESH_SEQ_STORE_RATE
#############################

*How often the sequence number gets updated in storage*

Type: ``int``

Help
====

.. code-block:: none

    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.

Direct dependencies
===================

\ :kconfig:`BT_SETTINGS <CONFIG_BT_SETTINGS>` && \ :kconfig:`BT_MESH <CONFIG_BT_MESH>` && \ :kconfig:`BT <CONFIG_BT>`

*(Includes any dependencies from ifs and menus.)*

Default
=======

- 128

Kconfig definition
==================



At ``<Zephyr Subsystem>/bluetooth/mesh/Kconfig:729``

Included via ``Kconfig:8`` → ``Kconfig.zephyr:44`` → ``<Zephyr Subsystem>/Kconfig:9`` → ``<Zephyr Subsystem>/bluetooth/Kconfig:193``

Menu path: (Top) → Sub Systems and OS Services → Bluetooth → Bluetooth mesh support

.. code-block:: kconfig

    config BT_MESH_SEQ_STORE_RATE
    	int "How often the sequence number gets updated in storage"
    	range 0 1000000
    	default 128
    	depends on BT_SETTINGS && BT_MESH && BT
    	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.

*(The 'depends on' condition includes propagated dependencies from ifs and menus.)*