doc: implemented latest review

Implementing as much as I was able to.

Signed-off-by: Wille Backman <wille.backman@nordicsemi.no>

Author: wiba-nordic

.gitignore

@@ -12,5 +12,4 @@ __pycache__/
 /twister-out*
 
 # docs
-/doc/_build*
 /docs/_build*

docs/about.rst

@@ -56,7 +56,7 @@ In each topology, the nodes have the following responsibilities:
 * *Zigbee Router* - Extends the range of the network.
   For this reason, the router has the radio enabled at all times.
   However, in the star topology it is not moving packets through the network.
-* *Zigbee End Device* - Receives messages from the parent device, in this case the coordinator.
+* *Zigbee End Device* - Receives messages from the parent device.
 
 In every Zigbee topology, each router and end device that joins the Zigbee network after its creation by the coordinator needs a parent device.
 When a device wants to join the network, it sends a beacon request to scan for available devices.
@@ -66,7 +66,7 @@ Based on different factors of responses, such as signal strength, the new device
 For end devices, the parent device (a coordinator or a router) can store information meant for them.
 This is required because the end devices do not receive packets directly from other devices.
 Each packet meant for an end device needs to go through its parent, and the end devices need to regularly request and respond to packets from the parents.
-For example, in the |NCS|, the Zigbee light switch device requests packets from the parent every three seconds.
+For example, in the |addon| for the |NCS|, the Zigbee light switch device requests packets from the parent every three seconds.
 The end device does not route packets.
 It can also disable its radio to reduce the power consumption between the regular packet requests if the Sleepy End Device behavior is enabled.
 
@@ -75,7 +75,7 @@ Additional information
 
 If you want to learn more about the Zigbee topics and terminology mentioned in this guide, read the following pages:
 
-* :ref:`ug_zigbee_architectures` page to learn more about the Zigbee architecture available in the |NCS|.
+* :ref:`ug_zigbee_architectures` page to learn more about the Zigbee architecture.
 * `Common ZCL terms and definitions`_ section in the ZBOSS user guide.
 * Zigbee topologies in section 1.1.4 of the `Zigbee Specification <CSA Specifications Download Request_>`_.
 * :ref:`zigbee_ug_sed` section on the :ref:`ug_zigbee_configuring` page.

docs/adding_clusters.rst

@@ -6,9 +6,7 @@ Adding ZCL clusters to application
 ##################################
 
 .. note::
-   The contents of this user guide are inaccurate and will be updated in one of the upcoming releases.
-   The information about the update will be posted in the release notes.
-   For the time being, do not use this guide.
+   .. include:: /includes/experimental_note.txt
 
 .. contents::
    :local:
@@ -372,19 +370,20 @@ Complete the following steps to read the cluster list of a Zigbee node:
 Further expanding the custom application
 ****************************************
 
-You can further expand the application with more features, such as OTA support.
+You can further expand the application with more features.
 
-.. _ug_zigee_adding_clusters_ota:
+..
+  .. _ug_zigee_adding_clusters_ota:
 
-Adding OTA
-==========
+  Adding OTA
+  ==========
 
-To extend the sample with OTA support, we would have to complete steps similar to :ref:`adding On/Off Switch and Temperature Sensor functionalities <ug_zigee_adding_clusters_adding_clusters>`.
-Then, we would have to implement the ZCL device callback to control the process of collecting chunks of new firmware.
-This is described more broadly in the following sections.
+  To extend the sample with OTA support, we would have to complete steps similar to :ref:`adding On/Off Switch and Temperature Sensor functionalities <ug_zigee_adding_clusters_adding_clusters>`.
+  Then, we would have to implement the ZCL device callback to control the process of collecting chunks of new firmware.
+  This is described more broadly in the following sections.
 
-Fortunately, we can use the :ref:`lib_zigbee_fota` library to handle the majority of these implementation steps.
-To add OTA support to the extended application, follow the steps in :ref:`ug_zigbee_configuring_components_ota`.
+  Fortunately, we can use the :ref:`lib_zigbee_fota` library to handle the majority of these implementation steps.
+  To add OTA support to the extended application, follow the steps in :ref:`ug_zigbee_configuring_components_ota`.
 
 
 .. _ug_zigee_adding_clusters_passing_events:

docs/architectures.rst

@@ -7,6 +7,9 @@ Architectures
    :local:
    :depth: 2
 
+.. note::
+   .. include:: /includes/experimental_note.txt
+
 This page describes the platform designs that are possible with the Zigbee stack on the nRF54L15 development kit.
 
 The designs are described from the least to the most complex, that is from simple applications that consist of a single chip running single or multiple protocols to scenarios in which the nRF SoC acts as a network co-processor when the application is running on a much more powerful host processor.
@@ -73,7 +76,7 @@ It also has the following disadvantages:
 .. figure:: images/zigbee_platform_design_multi.svg
    :alt: Multiprotocol Zigbee and Bluetooth LE architecture (nRF54L Series devices)
 
-   Multiprotocol Zigbee and Bluetooth LE architecture on nRF52 Series devices
+   Multiprotocol Zigbee and Bluetooth LE architecture on nRF54L Series devices
 
 ..
   .. figure:: images/zigbee_platform_design_nRF5340_multi.svg

docs/commissioning.rst

@@ -7,6 +7,9 @@ Commissioning
    :local:
    :depth: 2
 
+.. note::
+   .. include:: /includes/experimental_note.txt
+
 Commissioning is a process that allows a new Zigbee device to join a Zigbee network.
 The device is configured into the network, so that it can start communicating with other network nodes.
 If there is no network to join, the commissioning procedure ensures that a new network is created.
@@ -32,7 +35,7 @@ In the ZBOSS stack, the commissioning can be started using one of the following
 
 For more information, see the `Stack commissioning start sequence`_ section in the ZBOSS stack documentation.
 
-In the |NCS|, the application can use :ref:`lib_zigbee_signal_handler` to handle the ZBOSS signals and start the commissioning.
+With the |addon|, the application can use :ref:`lib_zigbee_signal_handler` to handle the ZBOSS signals and start the commissioning.
 
 .. _zigbee_commissioning_modes:
 
@@ -108,10 +111,10 @@ The new device must be authenticated and authorized to become part of the networ
 For this purpose, it needs credentials, which usually take form of a network key.
 For `Centralized security network`_, the authentication and authorization also involves establishing a unique Trust Center Link Key (TCLK).
 
-Network Steering in the |NCS|
+Network Steering in the |addon| for the |NCS|
    In the ZBOSS stack, Network Steering is started using the `ZB_BDB_NETWORK_STEERING`_ bit mask.
 
-   In the |NCS|, Network Steering for a node on a network can be started using the following additional options:
+   In the |addon|, Network Steering for a node on a network can be started using the following additional options:
 
    * When running the :ref:`Zigbee Coordinator sample <zigbee_network_coordinator_sample>`, you can press the associated button.
    * If you are using the :ref:`lib_zigbee_shell` library in your application, you can use the ``bdb start`` command.
@@ -139,10 +142,10 @@ Depending on the node role:
 If Network Formation is successful, you can add nodes to the new network using `Network Steering`_.
 If unsuccessful, the commissioning procedure stops here.
 
-Network Formation in the |NCS|
+Network Formation in the |addon| for the |NCS|
    In the ZBOSS stack, Network Formation is started using the `ZB_BDB_NETWORK_FORMATION`_ bit mask.
 
-   In the |NCS|, when using the :ref:`lib_zigbee_signal_handler` and the application implements the Zigbee Coordinator role, the Network Formation procedure is started right after the stack initialization.
+   In the |addon|, when using the :ref:`lib_zigbee_signal_handler` and the application implements the Zigbee Coordinator role, the Network Formation procedure is started right after the stack initialization.
 
 Centralized security network
 ----------------------------
@@ -196,7 +199,7 @@ Depending on the device type:
 
 Finding and Binding can be terminated if there are no corresponding clusters on the target node.
 
-Finding and Binding in the |NCS|
+Finding and Binding in the |addon| for the |NCS|
    In the ZBOSS stack, Finding and Binding is started using the `ZB_BDB_FINDING_N_BINDING`_ bit mask.
 
    Apart from the BDB top-level procedure API, you can use the `zb_bdb_finding_binding_initiator()`_ function to manually control which binding table entries are to be created.

docs/configuring.rst

@@ -7,7 +7,11 @@ Configuring |addon|
    :local:
    :depth: 2
 
+.. note::
+   .. include:: /includes/experimental_note.txt
+
 This page describes what is needed to start working with Zigbee using the |addon| for the |NCS|.
+|kconfig_search|
 
 .. _zigbee_ug_libs:
 
@@ -17,7 +21,7 @@ Required libraries and drivers
 Zigbee requires the following modules:
 
 * :ref:`zigbee_zboss`, with the :ref:`lib_zigbee_osif` subsystem acting as the linking layer between the ZBOSS stack and the |NCS|.
-  The ZBOSS library is enabled by the :option:`CONFIG_ZIGBEE` Kconfig option.
+  The ZBOSS library is enabled by the ``CONFIG_ZIGBEE_R23`` Kconfig option.
   For more information about the ZBOSS stack, see also the `external ZBOSS development guide and API documentation`_.
 * `IEEE 802.15.4`_ radio driver - This library is automatically enabled when working with Zigbee on Nordic Semiconductor's development kits.
 
@@ -26,14 +30,14 @@ Zigbee requires the following modules:
 Mandatory configuration
 ***********************
 
-To use the Zigbee protocol, set the :option:`CONFIG_ZIGBEE` Kconfig option.
+To use the Zigbee protocol, set the ``CONFIG_ZIGBEE_R23`` Kconfig option.
 Setting this option enables all the peripherals required for the correct operation of the Zigbee protocol and allows you to use them.
 
 After that, you have to define the Zigbee device role for the Zigbee application or sample by setting one of the following Kconfig options:
 
-* Router role: :option:`CONFIG_ZIGBEE_ROLE_ROUTER`
-* End Device role: :option:`CONFIG_ZIGBEE_ROLE_END_DEVICE`
-* Coordinator role: :option:`CONFIG_ZIGBEE_ROLE_COORDINATOR`
+* Router role: ``CONFIG_ZIGBEE_ROLE_ROUTER``
+* End Device role: ``CONFIG_ZIGBEE_ROLE_END_DEVICE``
+* Coordinator role: ``CONFIG_ZIGBEE_ROLE_COORDINATOR``
 
 Setting any of these options enables the respective ZBOSS role library.
 This is needed because End Devices use different libraries than Routers and Coordinators.
@@ -66,11 +70,10 @@ Power saving during sleep
 -------------------------
 
 With the sleepy behavior enabled, the unused part of RAM memory is powered off, which allows to lower the power consumption even more.
-The sleep current of MCU can be lowered to about 1.8 µA by completing the following steps:
+The sleep current of MCU can be lowered by completing the following steps:
 
-1. Turn off UART by setting the :option:`CONFIG_SERIAL` Kconfig option to ``n``.
-#. For current measurements for the `nRF54L15 DK <Developing with nRF54L Series_>`_ (PCA10156), set **SW6** to ``nRF ONLY`` position to get the desired results.
-#. Enable the :option:`CONFIG_RAM_POWER_DOWN_LIBRARY` Kconfig option.
+1. Turn off UART by setting the ``CONFIG_SERIAL`` Kconfig option to ``n``.
+#. Enable the ``CONFIG_RAM_POWER_DOWN_LIBRARY`` Kconfig option.
 
 Optional configuration
 **********************
@@ -82,11 +85,11 @@ Device operational channel
 
 You can enable one of the following alternative options to select the channel on which the Zigbee device can operate:
 
-  * :option:`CONFIG_ZIGBEE_CHANNEL_SELECTION_MODE_SINGLE` - Single mode is enabled by default.
+  * ``CONFIG_ZIGBEE_CHANNEL_SELECTION_MODE_SINGLE`` - Single mode is enabled by default.
     The default channel is set to 16.
-    To set a different channel, edit the :option:`CONFIG_ZIGBEE_CHANNEL` option to the desired value.
-  * :option:`CONFIG_ZIGBEE_CHANNEL_SELECTION_MODE_MULTI` - In this mode, you get all the channels enabled by default.
-    To configure a custom set of channels in the range from 11 to 26, edit the :option:`CONFIG_ZIGBEE_CHANNEL_MASK` option.
+    To set a different channel, edit the ``CONFIG_ZIGBEE_CHANNEL`` Kconfig option to the desired value.
+  * ``CONFIG_ZIGBEE_CHANNEL_SELECTION_MODE_MULTI`` - In this mode, you get all the channels enabled by default.
+    To configure a custom set of channels in the range from 11 to 26, edit the ``CONFIG_ZIGBEE_CHANNEL_MASK`` Kconfig option.
     For example, you can set channels 13, 16, and 21.
     You must have at least one channel enabled with this option.
 
@@ -100,7 +103,7 @@ By default, it uses an address from Nordic Semiconductor's pool.
 
 If your devices should use a different address, you can change the address according to your company's addressing scheme.
 
-.. include:: includes/ieee802154_eui64_conf.txt
+.. include:: includes/ieee802154_eui64_conf_nrf54l.txt
 
 At the end of the configuration process, you can check the EUI-64 value using :ref:`lib_zigbee_shell`:
 
@@ -123,17 +126,17 @@ The ZBOSS stack can be started using one of the following options:
 * Started and executed from the main thread, as `described in the ZBOSS development guide <Stack commissioning start sequence_>`_.
 * Started from a dedicated Zephyr thread, which in turn can be created and started by calling :c:func:`zigbee_enable`.
 
-The dedicated thread can be configured using the following options:
+The dedicated thread can be configured using the following Kconfig options:
 
-* :option:`CONFIG_ZBOSS_DEFAULT_THREAD_PRIORITY` - Defines thread priority; set to 3 by default.
-* :option:`CONFIG_ZBOSS_DEFAULT_THREAD_STACK_SIZE` - Defines the size of the thread stack; set to 2048 by default.
+* ``CONFIG_ZBOSS_DEFAULT_THREAD_PRIORITY`` - Defines thread priority; set to ``3`` by default.
+* ``CONFIG_ZBOSS_DEFAULT_THREAD_STACK_SIZE`` - Defines the size of the thread stack; set to ``2048`` by default.
 
 .. _zigbee_ug_logging:
 
 Custom logging per module
 =========================
 
-Logging is handled with the :option:`CONFIG_LOG` option.
+Logging is handled with the ``CONFIG_LOG`` Kconfig option.
 This option enables logging for both the stack and Zephyr's `Logging`_ API.
 
 .. _zigbee_ug_logging_application_logs:
@@ -150,21 +153,22 @@ Stack logs
 ----------
 
 The stack logs are independent from Zephyr's `Logging`_ API.
-To customize them, use the following options:
+To customize them, use the following Kconfig options:
 
-* :option:`CONFIG_ZBOSS_ERROR_PRINT_TO_LOG` - Allows the application to log ZBOSS error names; enabled by default.
-* :option:`CONFIG_ZBOSS_TRACE_MASK` - Sets the modules from which ZBOSS will log the debug messages with :option:`CONFIG_ZBOSS_TRACE_LOG_LEVEL`; no module is set by default.
-* :option:`CONFIG_ZBOSS_TRAF_DUMP` - Enables logging of the received 802.15.4 frames over ZBOSS trace log if :option:`CONFIG_ZBOSS_TRACE_LOG_LEVEL` is set; disabled by default.
+* ``CONFIG_ZBOSS_ERROR_PRINT_TO_LOG`` - Allows the application to log ZBOSS error names; enabled by default.
+* ``CONFIG_ZBOSS_TRACE_MASK`` - Sets the modules from which ZBOSS will log the debug messages with ``CONFIG_ZBOSS_TRACE_LOG_LEVEL``; no module is set by default.
+* ``CONFIG_ZBOSS_TRAF_DUMP`` - Enables logging of the received 802.15.4 frames over ZBOSS trace log if ``CONFIG_ZBOSS_TRACE_LOG_LEVEL`` is set; disabled by default.
 
-The stack logs are provided in a binary format and you can configure how they are printed:
+The stack logs are provided in a binary format.
+You can configure how they are printed with the following Kconfig options:
 
-* :option:`CONFIG_ZBOSS_TRACE_HEXDUMP_LOGGING` - Stack logs are printed as hexdump using Zephyr's `Logging`_ API.
+* ``CONFIG_ZBOSS_TRACE_HEXDUMP_LOGGING`` - Stack logs are printed as hexdump using Zephyr's `Logging`_ API.
   This option is enabled by default.
-* :option:`CONFIG_ZBOSS_TRACE_BINARY_LOGGING` - Stack logs are printed in the binary format using one of the following independent serial backends of your choice:
+* ``CONFIG_ZBOSS_TRACE_BINARY_LOGGING`` - Stack logs are printed in the binary format using one of the following independent serial backends of your choice:
 
-  * :option:`CONFIG_ZBOSS_TRACE_UART_LOGGING` - UART serial.
+  * ``CONFIG_ZBOSS_TRACE_UART_LOGGING`` - UART serial.
     This backend is enabled by default.
-  * :option:`CONFIG_ZBOSS_TRACE_USB_CDC_LOGGING` - USB CDC serial.
+  * ``CONFIG_ZBOSS_TRACE_USB_CDC_LOGGING`` - USB CDC serial.
 
   To specify the serial device, you need to set the ``ncs,zboss-trace-uart`` choice in devicetree like this:
 
@@ -175,18 +179,19 @@ The stack logs are provided in a binary format and you can configure how they ar
      };
 
   .. note::
-     When you select :option:`CONFIG_ZBOSS_TRACE_USB_CDC_LOGGING`, the USB peripheral is enabled and the USB CDC serial is configured as a part of the :c:func:`zb_osif_serial_logger_init` function.
+     When you select the ``CONFIG_ZBOSS_TRACE_USB_CDC_LOGGING`` Kconfig option, the USB peripheral is enabled and the USB CDC serial is configured as a part of the :c:func:`zb_osif_serial_logger_init` function.
      The application does not wait for the connection to be established and unreceived data is lost.
      For this reason, start collecting the data as soon as you need to.
 
      See `CDC ACM`_ in the Zephyr documentation for more information about how to configure USB CDC ACM instance for logging ZBOSS trace messages.
 
-* :option:`CONFIG_ZBOSS_TRACE_BINARY_NCP_TRANSPORT_LOGGING` - Stack logs are printed in the binary format using the NCP transport channel.
+* ``CONFIG_ZBOSS_TRACE_BINARY_NCP_TRANSPORT_LOGGING`` - Stack logs are printed in the binary format using the NCP transport channel.
 
 Stack logs are stored in the internal buffer if they are printed using Zephyr's `Logging`_ API or the independent serial backend.
-You can customize the buffer size with the :option:`CONFIG_ZBOSS_TRACE_LOGGER_BUFFER_SIZE`.
+You can customize the buffer size with the ``CONFIG_ZBOSS_TRACE_LOGGER_BUFFER_SIZE`` Kconfig option.
 The buffer size must be larger than ``256`` and smaller than ``2147483648``.
-If NCP transport channel is used, stack logs are stored in the buffer used for NCP transport, which size can be configured with :option:`CONFIG_ZIGBEE_UART_TX_BUF_LEN`.
+If NCP transport channel is used, stack logs are stored in the buffer used for NCP transport.
+This buffer's size can be configured with the ``CONFIG_ZIGBEE_UART_TX_BUF_LEN`` Kconfig option.
 
 .. _zigbee_ug_logging_logger_options:
 
@@ -196,12 +201,12 @@ Zephyr's logger options
 You can configure custom logger options for each Zigbee and ZBOSS module.
 To do this, configure the related Kconfig option for one or more modules:
 
-* :option:`CONFIG_ZBOSS_TRACE_LOG_LEVEL`
-* :option:`CONFIG_ZBOSS_OSIF_LOG_LEVEL`
-* :option:`CONFIG_ZIGBEE_SHELL_LOG_LEVEL`
-* :option:`CONFIG_ZIGBEE_APP_UTILS_LOG_LEVEL_CHOICE`
-* :option:`CONFIG_ZIGBEE_LOGGER_EP_LOG_LEVEL_CHOICE`
-* :option:`CONFIG_ZIGBEE_SCENES_LOG_LEVEL`
+* ``CONFIG_ZBOSS_TRACE_LOG_LEVEL``
+* ``CONFIG_ZBOSS_OSIF_LOG_LEVEL``
+* ``CONFIG_ZIGBEE_SHELL_LOG_LEVEL``
+* ``CONFIG_ZIGBEE_APP_UTILS_LOG_LEVEL_CHOICE``
+* ``CONFIG_ZIGBEE_LOGGER_EP_LOG_LEVEL_CHOICE``
+* ``CONFIG_ZIGBEE_SCENES_LOG_LEVEL``
 
 For each of the modules, you can set the following logging options:
 
@@ -211,7 +216,7 @@ For each of the modules, you can set the following logging options:
 * ``LOG_LEVEL_INF`` - Enables logging for informational messages, errors, and warnings.
 * ``LOG_LEVEL_DBG`` - Enables logging for debug messages, informational messages, errors, and warnings.
 
-For example, setting :option:`CONFIG_ZBOSS_TRACE_LOG_LEVEL_INF` will enable logging of informational messages, errors, and warnings for the ZBOSS Trace module.
+For example, setting ``CONFIG_ZBOSS_TRACE_LOG_LEVEL_INF`` will enable logging of informational messages, errors, and warnings for the ZBOSS Trace module.
 
 Reduced power consumption
 =========================