doc: Matter bridge app: Kconfig fixes

peknis · ArekBalysNordic · commit 9bfb7928c033 · 2025-09-17T14:17:02.000+02:00
Adding sample-specific Kconfig options and fixing links
to them.

Signed-off-by: Pekka Niskanen &lt;pekka.niskanen@nordicsemi.no&gt;
diff --git a/applications/matter_bridge/doc/matter_bridge_description.rst b/applications/matter_bridge/doc/matter_bridge_description.rst
@@ -470,6 +470,41 @@ CONFIG_BRIDGE_BT_RECOVERY_SCAN_TIMEOUT_MS
 CONFIG_BRIDGE_BT_SCAN_TIMEOUT_MS
    ``int`` - Set the Bluetooth LE scan timeout in milliseconds.
 
+.. _CONFIG_BRIDGE_FORCE_BT_CONNECTION_PARAMS:
+
+CONFIG_BRIDGE_FORCE_BT_CONNECTION_PARAMS
+   ``bool`` - Determines whether the Matter bridge forces connection parameters or accepts the Bluetooth LE peripheral device selection.
+
+.. _CONFIG_BRIDGE_BT_SCAN_WINDOW:
+
+CONFIG_BRIDGE_BT_SCAN_WINDOW
+   ``int`` - Duration of a central actively scanning for devices within scan interval, equal to ``CONFIG_BRIDGE_BT_SCAN_WINDOW`` * 0.625 ms.
+
+.. _CONFIG_BRIDGE_BT_SCAN_INTERVAL:
+
+CONFIG_BRIDGE_BT_SCAN_INTERVAL
+   ``int`` - Time between consecutive Bluetooth scan windows, equal to ``CONFIG_BRIDGE_BT_SCAN_INTERVAL`` * 0.625 ms.
+
+.. _CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN:
+
+CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN
+   ``int`` - The minimum duration of time requested by central after the peripheral device should wake up to communicate, equal to ``CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN`` * 1.25 ms.
+
+.. _CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX:
+
+CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX
+   ``int`` - The maximum duration of time requested by central after the peripheral device should wake up to communicate, equal to ``CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX`` * 1.25 ms.
+
+.. _CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT:
+
+CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT
+   ``int`` - The time since the last packet was successfully received until the devices consider the connection lost, equal to ``CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT`` cs.
+
+.. _CONFIG_BRIDGE_BT_CONNECTION_LATENCY:
+
+CONFIG_BRIDGE_BT_CONNECTION_LATENCY
+   ``int`` - The number of connection events the peripheral can skip waking up for if it does not have any data to send.
+
 The following options affect how many bridged devices the application supports.
 See the :ref:`matter_bridge_app_bridged_support_configs` section for more information.
 
@@ -573,12 +608,12 @@ You can disable configuring the parameters by setting the :kconfig:option:`CONFI
 
 Use the following Kconfig options to set the desired parameters:
 
-- :kconfig:option:`CONFIG_BRIDGE_BT_SCAN_WINDOW` - The duration a central actively scans for devices within the scan interval.
-- :kconfig:option:`CONFIG_BRIDGE_BT_SCAN_INTERVAL` - Time between consecutive Bluetooth LE scan windows.
-- :kconfig:option:`CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN` - The minimum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
-- :kconfig:option:`CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX` - The maximum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
-- :kconfig:option:`CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT` - The time since the last packet was successfully received until the devices consider the connection lost.
-- :kconfig:option:`CONFIG_BRIDGE_BT_CONNECTION_LATENCY` - Allows the peripheral to skip waking up for a certain number of connection events if it does not have any data to send.
+- :ref:`CONFIG_BRIDGE_BT_SCAN_WINDOW` - The duration a central actively scans for devices within the scan interval.
+- :ref:`CONFIG_BRIDGE_BT_SCAN_INTERVAL` - Time between consecutive Bluetooth LE scan windows.
+- :ref:`CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN` - The minimum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
+- :ref:`CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX` - The maximum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
+- :ref:`CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT` - The time since the last packet was successfully received until the devices consider the connection lost.
+- :ref:`CONFIG_BRIDGE_BT_CONNECTION_LATENCY` - Allows the peripheral to skip waking up for a certain number of connection events if it does not have any data to send.
 
 The parameters in this application have been selected based on the :ref:`multiprotocol_bt_thread` information in the :ref:`ug_multiprotocol_support` section.
 
diff --git a/doc/nrf/protocols/matter/end_product/factory_provisioning.rst b/doc/nrf/protocols/matter/end_product/factory_provisioning.rst
@@ -140,7 +140,7 @@ The following table lists the parameters of a factory data set:
 | ``rd_uid``             | rotating device ID unique ID         | <16, 32> B           | byte string  | optional    | The unique ID for rotating device ID, which consists of a randomly-generated 128-bit (or longer) octet string.                                                                                                              |
 |                        |                                      |                      |              |             | The rotating device ID is an optional identifier that is used for the :ref:`ug_matter_configuring_ffs` purposes.                                                                                                            |
 |                        |                                      |                      |              |             | This parameter should be protected against reading or writing over-the-air after initial introduction into the device, and stay fixed during the lifetime of the device.                                                    |
-|                        |                                      |                      |              |             | When building an application with the Factory Data support, the :ref:`CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN` must be set with the length of the actual ``rd_uid`` stored in the Factory Data partition.           |
+|                        |                                      |                      |              |             | When building an application with the Factory Data support, the :ref:`CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN` must be set with the length of the actual ``rd_uid`` stored in the Factory Data partition.      |
 +------------------------+--------------------------------------+----------------------+--------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 | ``user``               | User data                            | variable, max 1024 B | CBOR map     | optional    | The user data is provided in the JSON format.                                                                                                                                                                               |
 |                        |                                      |                      |              |             | This parameter is optional and depends on the device manufacturer's purpose.                                                                                                                                                |
diff --git a/doc/nrf/samples/matter.rst b/doc/nrf/samples/matter.rst
@@ -123,3 +123,4 @@ In addition to these samples, check also the following Matter applications:
 
    ../../../samples/matter/*/README
    ../../../samples/matter/common/config
+   ../../../samples/matter/common/config_matter_stack
diff --git a/samples/matter/common/config.rst b/samples/matter/common/config.rst
@@ -94,7 +94,7 @@ CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_NETWORK_LOGS
 
 .. _CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_TEST:
 
-ONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_TEST
+CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_TEST
 	``bool`` - Enable the testing module for the diagnostic logs cluster.
 
 .. _CONFIG_NCS_SAMPLE_MATTER_DIAGNOSTIC_LOGS_REDIRECT:
@@ -248,78 +248,3 @@ The following snippets are available:
 
 * ``diagnostic-logs`` - Enables the set of configurations needed for full Matter diagnostic logs support.
   See :ref:`ug_matter_diagnostic_logs_snippet` in the Matter protocol section for more information.
-
-.. _matter_stack_config:
-
-Shared configurations in Matter stack
-#####################################
-
-.. contents::
-   :local:
-   :depth: 2
-
-This page lists Kconfig options and snippets shared by ``sdk-connectedhomeip``.
-See the :ref:`ug_matter_device_advanced_kconfigs` page for more detailed information.
-
-Configuration options
-*********************
-
-Check and configure the following configuration options:
-
-.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY:
-
-CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY
-  ``int`` - After removing the last fabric wait defined time [in milliseconds] to perform an action.
-  After removing the last fabric the device will wait for the defined time and then perform an action chosen by the CHIP_LAST_FABRIC_REMOVED_ACTION option.
-  This schedule will allow for avoiding race conditions before the device removes non-volatile data.
-
-.. _CONFIG_FACTORY_DATA_CUSTOM_BACKEND:
-
-CONFIG_FACTORY_DATA_CUSTOM_BACKEND
-  ``bool`` - Enable a custom backend for factory data.
-  This option is used to enable a custom backend for factory data.
-  The custom backend is used to store the factory data in a custom location.
-
-.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START:
-
-CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START
-  ``bool`` - After removing the last fabric erase NVS and start Bluetooth LE advertising.
-  After removing the last fabric the device will perform the factory reset without rebooting and start the Bluetooth LE advertisement automatically.
-  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
-  This option should not be used for devices that normally do not advertise Bluetooth LE on boot to keep their original behavior.
-
-.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT:
-
-CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT
-  ``bool`` - After removing the last fabric erase NVS and reboot.
-  After removing the last fabric the device will perform the factory reset and then reboot.
-  The current RAM state will be removed and the new commissioning to the new fabric will use the initial fabric index.
-  This option is the most safe.
-
-.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY:
-
-CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY
-  ``bool`` - After removing the last fabric erase NVS only.
-  After removing the last fabric the device will perform the factory reset only without rebooting.
-  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
-
-.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE:
-
-CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE
-  ``bool`` - After removing the last fabric do not perform any action.
-  After removing the last fabric the device will not perform factory reset or reboot.
-  The current state will be left as it is and the BLE advertising will not start automatically.
-
-.. _CONFIG_CHIP_MEMORY_PROFILING:
-
-CONFIG_CHIP_MEMORY_PROFILING
-  ``bool`` - Enable features for tracking memory usage.
-  Enables features for tracking memory usage in Matter.
-
-.. _CONFIG_CHIP_NUS:
-
-CONFIG_CHIP_NUS
-  ``bool`` - Enable Nordic UART service for Matter purposes.
-  Enables Nordic UART service (NUS) for Matter samples.
-  Using NUS service you can control a Matter sample using pre-defined BLE commands and do defined operations.
-  The CHIP NUS service can be useful to keep communication with a smart home device when a connection within Matter network is lost.
diff --git a/samples/matter/common/config_matter_stack.rst b/samples/matter/common/config_matter_stack.rst
@@ -0,0 +1,80 @@
+.. _matter_stack_config:
+
+Shared configurations in Matter stack
+#####################################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This page lists Kconfig options and snippets shared by ``sdk-connectedhomeip``.
+See the :ref:`ug_matter_device_advanced_kconfigs` page for more detailed information.
+
+Configuration options
+*********************
+
+Check and configure the following configuration options:
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY
+  ``int`` - After removing the last fabric wait defined time [in milliseconds] to perform an action.
+  After removing the last fabric the device will wait for the defined time and then perform an action chosen by the ``CHIP_LAST_FABRIC_REMOVED_ACTION`` option.
+  This schedule will allow for avoiding race conditions before the device removes non-volatile data.
+
+.. _CONFIG_FACTORY_DATA_CUSTOM_BACKEND:
+
+CONFIG_FACTORY_DATA_CUSTOM_BACKEND
+  ``bool`` - Enable a custom backend for factory data.
+  This option is used to enable a custom backend for factory data.
+  The custom backend is used to store the factory data in a custom location.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START
+  ``bool`` - After removing the last fabric erase NVS and start Bluetooth LE advertising.
+  After removing the last fabric the device will perform the factory reset without rebooting and start the Bluetooth LE advertisement automatically.
+  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
+  This option should not be used for devices that normally do not advertise Bluetooth LE on boot to keep their original behavior.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT
+  ``bool`` - After removing the last fabric erase NVS and reboot.
+  After removing the last fabric the device will perform the factory reset and then reboot.
+  The current RAM state will be removed and the new commissioning to the new fabric will use the initial fabric index.
+  This option is the safest.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY
+  ``bool`` - After removing the last fabric erase NVS only.
+  After removing the last fabric the device will perform the factory reset only without rebooting.
+  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE
+  ``bool`` - After removing the last fabric do not perform any action.
+  After removing the last fabric the device will not perform factory reset or reboot.
+  The current state will be left as it is and the Bluetooth LE advertising will not start automatically.
+
+.. _CONFIG_CHIP_MEMORY_PROFILING:
+
+CONFIG_CHIP_MEMORY_PROFILING
+  ``bool`` - Enable features for tracking memory usage.
+  Enables features for tracking memory usage in Matter.
+
+.. _CONFIG_CHIP_NUS:
+
+CONFIG_CHIP_NUS
+  ``bool`` - Enable Nordic UART service for Matter purposes.
+  Enables Nordic UART service (NUS) for Matter samples.
+  Using the NUS service, you can control a Matter sample using pre-defined Bluetooth LE commands and perform defined operations.
+  The CHIP NUS service can be useful to keep communication with a smart home device when a connection within Matter network is lost.
+
+.. _CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN:
+
+CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN
+	``int`` - Maximum length of rotating device ID unique ID in bytes
+	Maximum acceptable length of rotating device ID unique ID in bytes.
diff --git a/samples/matter/lock/README.rst b/samples/matter/lock/README.rst
@@ -138,7 +138,7 @@ In the door lock sample, you can use the following commands with the Bluetooth L
 * ``Lock`` - To lock the door of the connected device.
 * ``Unlock`` - To unlock the door of the connected device.
 
-If the device is already connected to the Matter network, the notification about changing the lock state will be send to the Bluetooth controller.
+If the device is already connected to the Matter network, the notification about changing the lock state will be sent to the Bluetooth controller.
 
 Currently, the door lock's Bluetooth LE service extension with NUS is only available for the nRF52840 and the nRF5340 DKs in the :ref:`Matter over Thread <ug_matter_gs_testing>` network variant.
 However, you can use the Bluetooth LE service extension regardless of whether the device is connected to a Matter over Thread network or not.
@@ -556,7 +556,7 @@ Onboarding information
 ++++++++++++++++++++++
 
 When you start the commissioning procedure, the controller must get the onboarding information from the Matter accessory device.
-The onboarding information representation depends on your commissioner setup.
+The onboarding information representation depends on your commissioner set-up.
 
 For this sample, you can use one of the following :ref:`onboarding information formats <ug_matter_network_topologies_commissioning_onboarding_formats>` to provide the commissioner with the data payload that includes the device discriminator and the setup PIN code:
 
@@ -822,7 +822,7 @@ To test the :ref:`matter_lock_sample_ble_nus` feature, complete the following st
 
       west flash --erase
 
-#. If you built the sample with the debug configuration, connect the board to an UART console to see the log entries from the device.
+#. If you built the sample with the debug configuration, connect the board to a UART console to see the log entries from the device.
 #. Open the nRF Toolbox application on your smartphone.
 #. Select :guilabel:`Universal Asynchronous Receiver/Transmitter UART` from the list in the nRF Toolbox application.
 #. Tap on :guilabel:`Connect`.

Original file line number	Diff line number	Diff line change
`@@ -123,3 +123,4 @@ In addition to these samples, check also the following Matter applications:`
`123`	`123`
`124`	`124`	`../../../samples/matter/*/README`
`125`	`125`	`../../../samples/matter/common/config`
	`126`	`+ ../../../samples/matter/common/config_matter_stack`