Merge branch 'master' into fix_color_temperature_light

docs/guides/nrfconnect_examples_configuration.md

@@ -25,7 +25,7 @@ Regardless of the option, you will need to rebuild your application. This will
 require you to provide the build target name of the kit you are using. You can
 find the build target names in the Requirements section of the example you are
 building or on the
-[Board support](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/board_support/index.html)
+[Board support](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/board_support/index.html)
 page in the nRF Connect SDK documentation.
 
 ### Temporary changes to configuration
@@ -97,7 +97,7 @@ them values of proper type. Few examples:
     `CONFIG_SAMPLE_STRING_OPTION="some_text"`
 
 For more detailed information, read about
-[setting Kconfig values](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/kconfig/setting.html#setting-configuration-values)
+[setting Kconfig values](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/kconfig/setting.html)
 in the nRF Connect SDK documentation.
 
 Because Kconfig configuration files are used in the building process, make sure
@@ -150,7 +150,7 @@ from your perspective:
           $ west build -b build-target -- -DOVERLAY_CONFIG=overlay_file_name
 
 Read the
-[Kconfig](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/kconfig/index.html#kconfig)
+[Kconfig](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/kconfig/index.html)
 guide in the nRF Connect SDK's Zephyr documentation if you are interested in
 getting more advanced and detailed information about the configuration
 structure.
@@ -214,7 +214,7 @@ performance in case it has been polluted with unwanted entries.
 #### Logging
 
 You can enable logging for both the stack and Zephyr’s
-[Logging](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/reference/logging/index.html#logging-api)
+[Logging](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/logging/index.html)
 API by setting the `CONFIG_LOG` option.
 
 Zephyr allows you to configure log levels of different software modules

docs/guides/nrfconnect_examples_software_update.md

@@ -6,7 +6,7 @@ protocols:
 
 -   Matter-compliant OTA update protocol that uses the Matter operational
     network for querying and downloading a new firmware image.
--   [Simple Management Protocol](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/services/device_mgmt/smp_protocol.html)
+-   [Simple Management Protocol](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/device_mgmt/smp_protocol.html)
     over Bluetooth LE. In this case, the DFU can be done either using a
     smartphone application or a PC command line tool. Note that this protocol is
     not part of the Matter specification.
@@ -125,11 +125,9 @@ rebooted to apply the update.
 To upgrade your device firmware over Bluetooth LE using a smartphone, complete
 the following steps:
 
-1. Install _one_ of the following applications on your smartphone:
-
-    - [nRF Connect for Mobile](https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Connect-for-mobile)
-    - [nRF Toolbox](https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Toolbox)
-
+1. Install the
+   [nRF Connect Device Manager](https://www.nordicsemi.com/Products/Development-tools/nrf-connect-device-manager)
+   application on your smartphone.
 2. Push the appropriate button on the device to enable the software update
    functionality (if it is not enabled by default) and start the Bluetooth LE
    advertising of the SMP service. See the user interface section in the example
@@ -138,8 +136,10 @@ the following steps:
    advertising. See the user interface section in the example documentation to
    check the button number.
 4. Follow the instructions about downloading the new image to a device on the
-   [FOTA upgrades](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/working_with_nrf/nrf52/developing.html#fota-updates)
-   page in the nRF Connect SDK documentation.
+   FOTA updates page for either
+   [nRF52 Series devices](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf52/fota_update.html)
+   or the
+   [nRF5340 DK](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/fota_update_nrf5340.html).
 
 <hr>
 
@@ -171,7 +171,7 @@ Complete the following steps to perform DFU using mcumgr:
 > (for example, `MatterLock`).
 
 1.  Install the tool by following the
-    [mcumgr command line tool installation instructions](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/device_mgmt/index.html#command-line-tool).
+    [mcumgr command line tool installation instructions](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/device_mgmt/mcumgr.html#command-line_tool).
 2.  Push the appropriate button on the device to enable the software update
     functionality (if it is not enabled by default) and start the Bluetooth LE
     advertising of SMP service. See the user interface section in the example
@@ -342,6 +342,6 @@ Swapping operation can take some time, and after it completes, the new firmware
 is booted.
 
 Visit the
-[mcumgr image management](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/device_mgmt/indexhtml#image-management)
+[mcumgr image management](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/device_mgmt/mcumgr.html#image_management)
 section to get familiar with all image management commands supported by the
 tool.

docs/guides/nrfconnect_factory_data_configuration.md

@@ -24,7 +24,7 @@ data secure by applying hardware write protection.
 
 > **Note:** Due to hardware limitations, in the nRF Connect platform, protection
 > against writing can be applied only to the internal memory partition. The
-> [Fprotect](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/libraries/others/fprotect.html)
+> [Fprotect](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/libraries/security/bootloader/fprotect.html)
 > is the hardware flash protection driver, and we used it to ensure write
 > protection of the factory data partition in internal flash memory.
 
@@ -643,7 +643,7 @@ $ west build -b nrf52840dk_nrf52840 -- \
 
 The factory data partition is an area in the device's persistent storage where a
 factory data set is stored. This area is configured using the
-[Partition Manager](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/scripts/partition_manager/partition_manager.html),
+[Partition Manager](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/scripts/partition_manager/partition_manager.html),
 within which all partitions are declared in the `pm_static.yml` file.
 
 To prepare an example that supports factory data, add a partition called
@@ -845,7 +845,7 @@ snippet:
 
 > **Note:** To get more information about how to use the interactive Kconfig
 > interfaces, read the
-> [Kconfig documentation](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/kconfig/menuconfig.html).
+> [Kconfig documentation](https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/build/kconfig/menuconfig.html).
 
 ### Default Kconfig values and developing aspects
 

docs/guides/nrfconnect_platform_overview.md

@@ -18,7 +18,7 @@ communication purposes:
 ## nRF Connect SDK
 
 Nordic Semiconductor's
-[nRF Connect SDK](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/index.html)
+[nRF Connect SDK](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/index.html)
 allows to build a range of applications, including cellular IoT (LTE-M and
 NB-IoT), Bluetooth Low Energy, Thread, Zigbee, and Bluetooth mesh. The SDK
 contains samples, libraries and a full set of drivers for Nordic Semiconductor's
@@ -57,8 +57,8 @@ Bluetooth LE concurrently with other stacks on the same radio chip.
 
 Read more in the nRF Connect SDK documentation:
 
--   [SoftDevice Controller](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html)
--   [Multiprotocol Service Layer](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/mpsl/README.html)
+-   [SoftDevice Controller](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/README.html)
+-   [Multiprotocol Service Layer](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/mpsl/README.html)
 
 <hr>
 
@@ -72,9 +72,9 @@ network layer functionalities provided by the Zephyr.
 
 Read more in the nRF Connect SDK documentation:
 
--   [Multiprotocol Service Layer](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/mpsl/README.html)
--   [nRF 802.15.4 Radio Driver](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/nrf_802154/README.html)
--   [OpenThread integration](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/thread/overview/ot_integration.html)
+-   [Multiprotocol Service Layer](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/mpsl/README.html)
+-   [nRF 802.15.4 Radio Driver](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/nrf_802154/README.html)
+-   [OpenThread integration](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/thread/overview/ot_integration.html)
 
 <hr>
 
@@ -105,7 +105,7 @@ agnostic interfaces and no additional platform-related actions are needed to
 perform communication through the Matter stack.
 
 For more information, see the
-[Matter integration in the nRF Connect SDK](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/matter/overview/integration.html)
+[Matter integration in the nRF Connect SDK](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/matter/overview/integration.html)
 page in the SDK documentation.
 
 <hr>
@@ -126,5 +126,5 @@ library file is imported during the compilation process.
 
 For more information about the build system in Zephyr and the nRF Connect SDK,
 see the
-[Build and configuration system](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_dev/build_and_config_system/index.html)
+[Build and configuration system](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/config_and_build/config_and_build_system.html)
 page in the SDK documentation.

docs/guides/openthread_rcp_nrf_dongle.md

@@ -13,14 +13,14 @@ Once programmed, the dongle can be used for
 ## Requirements
 
 You need to set up the
-[nRF Connect SDK](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/index.html)
+[nRF Connect SDK](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/index.html)
 to build and program the OpenThread Radio Co-Processor to the nRF52840 Dongle.
 Read the
-[nRF Connect SDK Getting started](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/getting_started.html)
+[nRF Connect SDK installation](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/installation.html)
 documentation for more information.
 
 ## Building and programming the RCP firmware onto an nRF52840 Dongle
 
 After you set up the nRF Connect SDK, follow the steps in the
-[Configuring a radio co-processor](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_thread_tools.html#configuring-a-radio-co-processor)
+[Configuring a radio co-processor](https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/thread/tools.html#configuring_a_radio_co-processor)
 section for the nRF52840 Dongle (USB transport).

examples/all-clusters-app/all-clusters-common/all-clusters-app.matter

@@ -2554,7 +2554,7 @@ cluster TimeSynchronization = 56 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/all-clusters-app/linux/ValveControlDelegate.cpp

@@ -35,7 +35,7 @@ DataModel::Nullable<chip::Percent> ValveControlDelegate::HandleOpenValve(DataMod
     sLastOpenDuration          = 0;
     ChipLogProgress(NotSpecified, "Valve opening from level: %d to %d", currentLevel, sLevel);
 
-    // In this demo application, the trasition is considered instant,
+    // In this demo application, the transition is considered instant,
     // so current level is set to the requested level and current state is set to kOpen.
     currentLevel = sLevel;
     Attributes::CurrentState::Set(kValveEndpoint, ValveConfigurationAndControl::ValveStateEnum::kOpen);

examples/all-clusters-minimal-app/all-clusters-common/all-clusters-minimal-app.matter

@@ -2286,7 +2286,7 @@ cluster EthernetNetworkDiagnostics = 55 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/bridge-app/bridge-common/bridge-app.matter

@@ -1921,7 +1921,7 @@ cluster EthernetNetworkDiagnostics = 55 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/chef/devices/rootnode_genericswitch_2dfff6e516.matter

@@ -1251,7 +1251,7 @@ cluster GeneralDiagnostics = 51 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/chef/devices/rootnode_genericswitch_9866e35d0b.matter

@@ -1251,7 +1251,7 @@ cluster GeneralDiagnostics = 51 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/contact-sensor-app/linux/README.md

@@ -69,11 +69,6 @@ details.
 
 ## Running the Complete Example on Raspberry Pi 4
 
-> If you want to test Echo protocol, please enable Echo handler
->
->     gn gen out/debug --args='chip_app_use_echo=true'
->     ninja -C out/debug
-
 -   Prerequisites
 
     1. A Raspberry Pi 4 board
@@ -112,7 +107,7 @@ details.
                   $ cd ~/connectedhomeip/examples/contact-sensor-app/linux
                   $ sudo out/debug/chip-contact-sensor-app --ble-device [bluetooth device number]
                   # In this example, the device we want to use is hci1
-                  $ sudo out/debug/chip-contact-sensor-app --ble-device 1
+                  $ sudo out/debug/contact-sensor-app --ble-device 1
 
         -   Test the device using ChipDeviceController on your laptop /
             workstation etc.

examples/fabric-admin/commands/pairing/PairingCommand.h

@@ -250,7 +250,7 @@ class PairingCommand : public CHIPCommand,
     const PairingNetworkType mNetworkType;
     const chip::Dnssd::DiscoveryFilterType mFilterType;
     Command::AddressWithInterface mRemoteAddr;
-    NodeId mNodeId;
+    NodeId mNodeId = chip::kUndefinedNodeId;
     chip::Optional<uint16_t> mTimeout;
     chip::Optional<bool> mDiscoverOnce;
     chip::Optional<bool> mUseOnlyOnNetworkDiscovery;
@@ -272,18 +272,18 @@ class PairingCommand : public CHIPCommand,
     TypedComplexArgument<chip::app::DataModel::List<chip::app::Clusters::TimeSynchronization::Structs::DSTOffsetStruct::Type>>
         mComplex_DSTOffsets;
 
-    uint16_t mRemotePort;
-    uint16_t mDiscriminator;
-    uint32_t mSetupPINCode;
-    uint16_t mIndex;
+    uint16_t mRemotePort    = 0;
+    uint16_t mDiscriminator = 0;
+    uint32_t mSetupPINCode  = 0;
+    uint16_t mIndex         = 0;
     chip::ByteSpan mOperationalDataset;
     chip::ByteSpan mSSID;
     chip::ByteSpan mPassword;
-    char * mOnboardingPayload;
-    uint64_t mDiscoveryFilterCode;
-    char * mDiscoveryFilterInstanceName;
+    char * mOnboardingPayload           = nullptr;
+    uint64_t mDiscoveryFilterCode       = 0;
+    char * mDiscoveryFilterInstanceName = nullptr;
 
-    bool mDeviceIsICD;
+    bool mDeviceIsICD = false;
     uint8_t mRandomGeneratedICDSymmetricKey[chip::Crypto::kAES_CCM128_Key_Length];
 
     // For unpair

examples/fabric-admin/scripts/run_fabric_sync.sh

@@ -14,7 +14,9 @@ DEFAULT_BRIDGE_CHOICES=(
     "./fabric-bridge-app"
     "out/debug/standalone/fabric-bridge-app"
     "out/linux-x64-fabric-bridge-rpc/fabric-bridge-app"
+    "out/linux-x64-fabric-bridge-rpc-no-ble/fabric-bridge-app"
     "out/darwin-arm64-fabric-bridge-rpc/fabric-bridge-app"
+    "out/darwin-arm64-fabric-bridge-rpc-no-ble/fabric-bridge-app"
 )
 FABRIC_ADMIN_LOG="/tmp/fabric_admin.log"
 FABRIC_BRIDGE_APP_LOG="/tmp/fabric_bridge_app.log"

examples/fabric-bridge-app/linux/README.md

@@ -92,7 +92,7 @@ defined:
 
     ```
     source scripts/activate.sh
-    ./scripts/build/build_examples.py --target linux-x64-fabric-bridge-rpc build
+    ./scripts/build/build_examples.py --target linux-x64-fabric-bridge-rpc-no-ble build
     ```
 
     ### For Raspberry Pi 4 example:

examples/light-switch-app/light-switch-common/light-switch-app.matter

@@ -1897,7 +1897,7 @@ cluster TimeSynchronization = 56 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;

examples/light-switch-app/qpg/zap/switch.matter

@@ -1953,7 +1953,7 @@ cluster ThreadNetworkDiagnostics = 53 {
 Two types of switch devices are supported: latching switch (e.g. rocker switch) and momentary switch (e.g. push button), distinguished with their feature flags.
 Interactions with the switch device are exposed as attributes (for the latching switch) and as events (for both types of switches). An interested party MAY subscribe to these attributes/events and thus be informed of the interactions, and can perform actions based on this, for example by sending commands to perform an action such as controlling a light or a window shade. */
 cluster Switch = 59 {
-  revision 1;
+  revision 2;
 
   bitmap Feature : bitmap32 {
     kLatchingSwitch = 0x1;