[nrfconnect] Update factory data guide with additional rotating id info (#27209)
* Adapt docs to the changed chip-tool command naming.
Recently the otasoftwareupdaterequestor attributes' and
commands' names have been slightly modified in chip-tool
but it looks like the correlated documentation has not been synced.
Also fixed spell checker errors.
Signed-off-by: Marcin Kajor <marcin.kajor@nordicsemi.no>
* Update the nrfconnect Factory Data docs with extended rd_uid info.
Also aligned the related json schema with the docs.
Signed-off-by: Marcin Kajor <marcin.kajor@nordicsemi.no>
---------
Signed-off-by: Marcin Kajor <marcin.kajor@nordicsemi.no>
diff --git a/.github/.wordlist.txt b/.github/.wordlist.txt
index 6e43cf4..4375a4e 100644
--- a/.github/.wordlist.txt
+++ b/.github/.wordlist.txt
@@ -979,6 +979,7 @@
OTAProvider
OTAProviderIpAddress
OTAProviderNodeId
+otaproviders
OTAProviderSerialPort
OTARequesterImpl
OTARequestorDriver
diff --git a/docs/guides/esp32/ota.md b/docs/guides/esp32/ota.md
index fb24373..7c9c388 100644
--- a/docs/guides/esp32/ota.md
+++ b/docs/guides/esp32/ota.md
@@ -35,15 +35,15 @@
### Using Console
-After commissioning is successful, read the default-ota-providers list of
+After commissioning is successful, read the default-otaproviders list of
requestor using the command below.
```
./out/debug/chip-tool otasoftwareupdaterequestor read default-otaproviders <REQUESTOR NODE ID> 0
```
-If the list does not have your provider, write into default-ota-providers list
-of requestor using the command below.
+If the list does not have your provider, write into default-otaproviders list of
+requestor using the command below.
```
./out/debug/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"fabricIndex": 1, "providerNodeID": <PROVIDER_NODE_ID_1>, "endpoint": 0}, {"fabricIndex": 1, "providerNodeID": <PROVIDER_NODE_ID_2>, "endpoint": 0}]' <REQUESTOR_NODE_ID> 0
@@ -65,7 +65,7 @@
chip-tool. On receiving this command OTA requestor will query for OTA image.
```
-./out/debug/chip-tool otasoftwareupdaterequestor announce-ota-provider <PROVIDER NODE ID> 0 0 0 <REQUESTOR NODE ID> 0
+./out/debug/chip-tool otasoftwareupdaterequestor announce-otaprovider <PROVIDER NODE ID> 0 0 0 <REQUESTOR NODE ID> 0
```
## Encrypted OTA
diff --git a/docs/guides/infineon_psoc6_software_update.md b/docs/guides/infineon_psoc6_software_update.md
index 713b0b1..4367142 100644
--- a/docs/guides/infineon_psoc6_software_update.md
+++ b/docs/guides/infineon_psoc6_software_update.md
@@ -69,7 +69,7 @@
* Once the commissioning process completes enter:
```
- ./out/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+ ./out/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
```
* The application device will connect to the Provider and start the image
diff --git a/docs/guides/nrfconnect_examples_software_update.md b/docs/guides/nrfconnect_examples_software_update.md
index 608c29f..ebaf08f 100644
--- a/docs/guides/nrfconnect_examples_software_update.md
+++ b/docs/guides/nrfconnect_examples_software_update.md
@@ -81,7 +81,7 @@
Requestor Endpoint ID, respectively):
```
- ./out/chiptool/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"fabricIndex": 1, "providerNodeID": 1, "endpoint": 0}]' 2 0
+ ./out/chiptool/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"fabricIndex": 1, "providerNodeID": 1, "endpoint": 0}]' 2 0
```
9. Configure the OTA Provider with the access control list (ACL) that grants
@@ -109,7 +109,7 @@
Requestor Endpoint ID, respectively):
```
- ./out/chiptool/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+ ./out/chiptool/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
```
Once the device is made aware of the OTA Provider node, it automatically
diff --git a/docs/guides/nrfconnect_factory_data_configuration.md b/docs/guides/nrfconnect_factory_data_configuration.md
index 59eb99b..2abb6e5 100644
--- a/docs/guides/nrfconnect_factory_data_configuration.md
+++ b/docs/guides/nrfconnect_factory_data_configuration.md
@@ -89,28 +89,28 @@
The following table lists the parameters of a factory data set:
-| Key name | Full name | Length | Format | Conformance | Description |
-| :------------------: | :----------------------------------: | :------------------: | :----------: | :---------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
-| `version` | factory data version | 2 B | uint16 | mandatory | A version of the current factory data set. It cannot be changed by a user and it must be coherent with current version of the Factory Data Provider on device side. |
-| `sn` | serial number | <1, 32> B | ASCII string | mandatory | A serial number parameter defines an unique number of manufactured device. The maximum length of the serial number is 32 characters. |
-| `vendor_id` | vendor ID | 2 B | uint16 | mandatory | A CSA-assigned ID for the organization responsible for producing the device. |
-| `product_id` | product ID | 2 B | uint16 | mandatory | A unique ID assigned by the device vendor to identify the product. It defaults to a CSA-assigned ID that designates a non-production or test product. |
-| `vendor_name` | vendor name | <1, 32> B | ASCII string | mandatory | A human-readable vendor name that provides a simple string containing identification of device's vendor for the application and Matter stack purposes. |
-| `product_name` | product name | <1, 32> B | ASCII string | mandatory | A human-readable product name that provides a simple string containing identification of the product for the application and the Matter stack purposes. |
-| `date` | manufacturing date | <8, 10> B | ISO 8601 | mandatory | A manufacturing date specifies the date that the device was manufactured. The date format used is ISO 8601, for example `YYYY-MM-DD`. |
-| `hw_ver` | hardware version | 2 B | uint16 | mandatory | A hardware version number that specifies the version number of the hardware of the device. The value meaning and the versioning scheme is defined by the vendor. |
-| `hw_ver_str` | hardware version string | <1, 64> B | uint16 | mandatory | A hardware version string parameter that specifies the version of the hardware of the device as a more user-friendly value than that presented by the hardware version integer value. The value meaning and the versioning scheme is defined by the vendor. |
-| `rd_uid` | rotating device ID unique ID | <16, 32> B | byte string | mandatory | The unique ID for rotating device ID, which consists of a randomly-generated 128-bit (or longer) octet string. 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. |
-| `dac_cert` | (DAC) Device Attestation Certificate | <1, 602> B | byte string | mandatory | The Device Attestation Certificate (DAC) and the corresponding private key are unique to each Matter device. The DAC is used for the Device Attestation process and to perform commissioning into a fabric. The DAC is a DER-encoded X.509v3-compliant certificate, as defined in RFC 5280. |
-| `dac_key` | DAC private key | 68 B | byte string | mandatory | The private key associated with the Device Attestation Certificate (DAC). This key should be encrypted and maximum security should be guaranteed while generating and providing it to factory data. |
-| `pai_cert` | Product Attestation Intermediate | <1, 602> B | byte string | mandatory | An intermediate certificate is an X.509 certificate, which has been signed by the root certificate. The last intermediate certificate in a chain is used to sign the leaf (the Matter device) certificate. The PAI is a DER-encoded X.509v3-compliant certificate as defined in RFC 5280. | |
-| `spake2_it` | SPAKE2+ iteration counter | 4 B | uint32 | mandatory | A SPAKE2+ iteration counter is the amount of PBKDF2 (a key derivation function) interactions in a cryptographic process used during SPAKE2+ Verifier generation. |
-| `spake2_salt` | SPAKE2+ salt | <32, 64> B | byte string | mandatory | The SPAKE2+ salt is a random piece of data, at least 32 byte long. It is used as an additional input to a one-way function that performs the cryptographic operations. A new salt should be randomly generated for each password. |
-| `spake2_verifier` | SPAKE2+ verifier | 97 B | byte string | mandatory | The SPAKE2+ verifier generated using SPAKE2+ salt, iteration counter, and passcode. |
-| `discriminator` | Discriminator | 2 B | uint16 | mandatory | A 12-bit value matching the field of the same name in the setup code. The discriminator is used during the discovery process. |
-| `passcode` | SPAKE passcode | 4 B | uint32 | optional | A pairing passcode is a 27-bit unsigned integer which serves as a proof of possession during the commissioning. Its value must be restricted to the values from `0x0000001` to `0x5F5E0FE` (`00000001` to `99999998` in decimal), excluding the following invalid passcode values: `00000000`, `11111111`, `22222222`, `33333333`, `44444444`, `55555555`, `66666666`, `77777777`, `88888888`, `99999999`, `12345678`, `87654321`. |
-| `product_appearance` | Product visible appearance | 2 B | CBOR map | optional | The appearance field is a structure that describes the visible appearance of the product. This field is provided in a CBOR map and consists of two attributes: `finish` (1 B), `primary_color` (1 B). See the [Appearance field description](#appearance-field-description) to learn how to set all attributes. |
-| `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. It is provided as a CBOR map type from persistent storage and should be parsed in the user application. This data is not used by the Matter stack. To learn how to work with user data, see the [How to set user data](#how-to-set-user-data) section. |
+| Key name | Full name | Length | Format | Conformance | Description |
+| :------------------: | :----------------------------------: | :------------------: | :----------: | :---------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
+| `version` | factory data version | 2 B | uint16 | mandatory | A version of the current factory data set. It cannot be changed by a user and it must be coherent with current version of the Factory Data Provider on device side. |
+| `sn` | serial number | <1, 32> B | ASCII string | mandatory | A serial number parameter defines an unique number of manufactured device. The maximum length of the serial number is 32 characters. |
+| `vendor_id` | vendor ID | 2 B | uint16 | mandatory | A CSA-assigned ID for the organization responsible for producing the device. |
+| `product_id` | product ID | 2 B | uint16 | mandatory | A unique ID assigned by the device vendor to identify the product. It defaults to a CSA-assigned ID that designates a non-production or test product. |
+| `vendor_name` | vendor name | <1, 32> B | ASCII string | mandatory | A human-readable vendor name that provides a simple string containing identification of device's vendor for the application and Matter stack purposes. |
+| `product_name` | product name | <1, 32> B | ASCII string | mandatory | A human-readable product name that provides a simple string containing identification of the product for the application and the Matter stack purposes. |
+| `date` | manufacturing date | 10 B | ISO 8601 | mandatory | A manufacturing date specifies the date that the device was manufactured. The date format used is ISO 8601, for example `YYYY-MM-DD`. |
+| `hw_ver` | hardware version | 2 B | uint16 | mandatory | A hardware version number that specifies the version number of the hardware of the device. The value meaning and the versioning scheme is defined by the vendor. |
+| `hw_ver_str` | hardware version string | <1, 64> B | uint16 | mandatory | A hardware version string parameter that specifies the version of the hardware of the device as a more user-friendly value than that presented by the hardware version integer value. The value meaning and the versioning scheme is defined by the vendor. |
+| `rd_uid` | rotating device ID unique ID | <16, 32> B | byte string | mandatory | The unique ID for rotating device ID, which consists of a randomly-generated 128-bit (or longer) octet string. 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 `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. |
+| `dac_cert` | (DAC) Device Attestation Certificate | <1, 602> B | byte string | mandatory | The Device Attestation Certificate (DAC) and the corresponding private key are unique to each Matter device. The DAC is used for the Device Attestation process and to perform commissioning into a fabric. The DAC is a DER-encoded X.509v3-compliant certificate, as defined in RFC 5280. |
+| `dac_key` | DAC private key | 68 B | byte string | mandatory | The private key associated with the Device Attestation Certificate (DAC). This key should be encrypted and maximum security should be guaranteed while generating and providing it to factory data. |
+| `pai_cert` | Product Attestation Intermediate | <1, 602> B | byte string | mandatory | An intermediate certificate is an X.509 certificate, which has been signed by the root certificate. The last intermediate certificate in a chain is used to sign the leaf (the Matter device) certificate. The PAI is a DER-encoded X.509v3-compliant certificate as defined in RFC 5280. |
+| `spake2_it` | SPAKE2+ iteration counter | 4 B | uint32 | mandatory | A SPAKE2+ iteration counter is the amount of PBKDF2 (a key derivation function) interactions in a cryptographic process used during SPAKE2+ Verifier generation. |
+| `spake2_salt` | SPAKE2+ salt | <32, 64> B | byte string | mandatory | The SPAKE2+ salt is a random piece of data, at least 32 byte long. It is used as an additional input to a one-way function that performs the cryptographic operations. A new salt should be randomly generated for each password. |
+| `spake2_verifier` | SPAKE2+ verifier | 97 B | byte string | mandatory | The SPAKE2+ verifier generated using SPAKE2+ salt, iteration counter, and passcode. |
+| `discriminator` | Discriminator | 2 B | uint16 | mandatory | A 12-bit value matching the field of the same name in the setup code. The discriminator is used during the discovery process. |
+| `passcode` | SPAKE passcode | 4 B | uint32 | optional | A pairing passcode is a 27-bit unsigned integer which serves as a proof of possession during the commissioning. Its value must be restricted to the values from `0x0000001` to `0x5F5E0FE` (`00000001` to `99999998` in decimal), excluding the following invalid passcode values: `00000000`, `11111111`, `22222222`, `33333333`, `44444444`, `55555555`, `66666666`, `77777777`, `88888888`, `99999999`, `12345678`, `87654321`. |
+| `product_appearance` | Product visible appearance | 2 B | CBOR map | optional | The appearance field is a structure that describes the visible appearance of the product. This field is provided in a CBOR map and consists of two attributes: `finish` (1 B), `primary_color` (1 B). See the [Appearance field description](#appearance-field-description) to learn how to set all attributes. |
+| `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. It is provided as a CBOR map type from persistent storage and should be parsed in the user application. This data is not used by the Matter stack. To learn how to work with user data, see the [How to set user data](#how-to-set-user-data) section. |
### Factory data format
diff --git a/docs/guides/silabs_efr32_software_update.md b/docs/guides/silabs_efr32_software_update.md
index adc9560..3d8649c 100644
--- a/docs/guides/silabs_efr32_software_update.md
+++ b/docs/guides/silabs_efr32_software_update.md
@@ -61,7 +61,7 @@
- Once the commissioning process completes enter:
- ./out/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+ ./out/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
- The application device will connect to the Provider and start the image
download. Once the image is downloaded the device will reboot into the
diff --git a/examples/all-clusters-app/telink/Readme.md b/examples/all-clusters-app/telink/Readme.md
index ececcdb..aaea384 100644
--- a/examples/all-clusters-app/telink/Readme.md
+++ b/examples/all-clusters-app/telink/Readme.md
@@ -163,7 +163,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/all-clusters-minimal-app/telink/Readme.md b/examples/all-clusters-minimal-app/telink/Readme.md
index f2fc7f4..1051c07 100644
--- a/examples/all-clusters-minimal-app/telink/Readme.md
+++ b/examples/all-clusters-minimal-app/telink/Readme.md
@@ -146,7 +146,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/bridge-app/telink/README.md b/examples/bridge-app/telink/README.md
index bec1790..34ce68e 100644
--- a/examples/bridge-app/telink/README.md
+++ b/examples/bridge-app/telink/README.md
@@ -308,7 +308,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/contact-sensor-app/nxp/k32w/k32w0/README.md b/examples/contact-sensor-app/nxp/k32w/k32w0/README.md
index bfbf287..af98333 100644
--- a/examples/contact-sensor-app/nxp/k32w/k32w0/README.md
+++ b/examples/contact-sensor-app/nxp/k32w/k32w0/README.md
@@ -642,7 +642,7 @@
Start the OTA process:
```
-user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
```
### Known issues ota
diff --git a/examples/contact-sensor-app/telink/README.md b/examples/contact-sensor-app/telink/README.md
index d8d60e6..68475be 100755
--- a/examples/contact-sensor-app/telink/README.md
+++ b/examples/contact-sensor-app/telink/README.md
@@ -165,7 +165,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/light-switch-app/telink/README.md b/examples/light-switch-app/telink/README.md
index bca9837..76f62c6 100755
--- a/examples/light-switch-app/telink/README.md
+++ b/examples/light-switch-app/telink/README.md
@@ -286,7 +286,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/lighting-app/nxp/k32w/k32w0/README.md b/examples/lighting-app/nxp/k32w/k32w0/README.md
index 5019e8a..674960e 100644
--- a/examples/lighting-app/nxp/k32w/k32w0/README.md
+++ b/examples/lighting-app/nxp/k32w/k32w0/README.md
@@ -655,7 +655,7 @@
Start the OTA process:
```
-user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
```
## Known issues ota
diff --git a/examples/lighting-app/telink/README.md b/examples/lighting-app/telink/README.md
index e9c4c5a..ddb5364 100644
--- a/examples/lighting-app/telink/README.md
+++ b/examples/lighting-app/telink/README.md
@@ -251,7 +251,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/lock-app/telink/README.md b/examples/lock-app/telink/README.md
index 8905d99..d6eefac 100755
--- a/examples/lock-app/telink/README.md
+++ b/examples/lock-app/telink/README.md
@@ -168,7 +168,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/ota-requestor-app/ameba/README.md b/examples/ota-requestor-app/ameba/README.md
index 73be70b..029cbed 100644
--- a/examples/ota-requestor-app/ameba/README.md
+++ b/examples/ota-requestor-app/ameba/README.md
@@ -53,7 +53,7 @@
4. Write the Default OTA providers into Ameba
- $ ./chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"fabricIndex": 1, "providerNodeID": 2, "endpoint": 0}]' 1 0
+ $ ./chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"fabricIndex": 1, "providerNodeID": 2, "endpoint": 0}]' 1 0
5. Configure the ACL of the ota-provider-app to allow access for Ameba
@@ -61,7 +61,7 @@
6. Use the chip-tool to announce the ota-provider-app to start the OTA process
- $ ./chip-tool otasoftwareupdaterequestor announce-ota-provider 1 0 0 0 2 0
+ $ ./chip-tool otasoftwareupdaterequestor announce-otaprovider 1 0 0 0 2 0
7. The OTA process should include downloading the image, verification of image
header, erasing upgraded flash partition, writing to flash and checksum
diff --git a/examples/ota-requestor-app/esp32/README.md b/examples/ota-requestor-app/esp32/README.md
index 7349857..1951b45 100644
--- a/examples/ota-requestor-app/esp32/README.md
+++ b/examples/ota-requestor-app/esp32/README.md
@@ -28,7 +28,7 @@
chip-tool. On receiving this command OTA requestor will query for OTA image.
```
-./out/debug/chip-tool otasoftwareupdaterequestor announce-ota-provider <PROVIDER NODE ID> 0 0 0 <REQUESTOR NODE ID> 0
+./out/debug/chip-tool otasoftwareupdaterequestor announce-otaprovider <PROVIDER NODE ID> 0 0 0 <REQUESTOR NODE ID> 0
```
Once the transfer is complete, OTA requestor sends ApplyUpdateRequest command to
diff --git a/examples/ota-requestor-app/infineon/cyw30739/README.md b/examples/ota-requestor-app/infineon/cyw30739/README.md
index 0a55e93..629418c 100644
--- a/examples/ota-requestor-app/infineon/cyw30739/README.md
+++ b/examples/ota-requestor-app/infineon/cyw30739/README.md
@@ -135,5 +135,5 @@
chip-tool pairing onnetwork-vendor 4321 20202021 9050
# Announce the OTA provider to the requestor
- chip-tool otasoftwareupdaterequestor announce-ota-provider 4321 9 0 0 1234 0
+ chip-tool otasoftwareupdaterequestor announce-otaprovider 4321 9 0 0 1234 0
```
diff --git a/examples/ota-requestor-app/linux/README.md b/examples/ota-requestor-app/linux/README.md
index 9cb4717..d347ffa 100644
--- a/examples/ota-requestor-app/linux/README.md
+++ b/examples/ota-requestor-app/linux/README.md
@@ -306,7 +306,7 @@
**Write to the DefaultOTAProviders attribute**
```
-out/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"providerNodeID": 3735928559, "endpoint": 0}]' 0x1234567890 0
+out/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"providerNodeID": 3735928559, "endpoint": 0}]' 0x1234567890 0
```
Every 60 seconds from when the OTA Requestor application has launched, the OTA
@@ -400,15 +400,15 @@
**Write/Read DefaultOTAProviders on the first fabric (alpha)**
```
-out/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"providerNodeID": 12648430, "endpoint": 0}]' 0xDEB 0
-out/chip-tool otasoftwareupdaterequestor read default-ota-providers 0xDEB 0
+out/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"providerNodeID": 12648430, "endpoint": 0}]' 0xDEB 0
+out/chip-tool otasoftwareupdaterequestor read default-otaproviders 0xDEB 0
```
**Write/Read DefaultOTAProviders on second fabric (beta)**
```
-out/chip-tool otasoftwareupdaterequestor write default-ota-providers '[{"providerNodeID": 45242, "endpoint": 0}]' 0xB0B 0 --commissioner-name beta
-out/chip-tool otasoftwareupdaterequestor read default-ota-providers 0xB0B 0 --commissioner-name beta
+out/chip-tool otasoftwareupdaterequestor write default-otaproviders '[{"providerNodeID": 45242, "endpoint": 0}]' 0xB0B 0 --commissioner-name beta
+out/chip-tool otasoftwareupdaterequestor read default-otaproviders 0xB0B 0 --commissioner-name beta
```
**Write ACL for the first OTA Provider application**
diff --git a/examples/ota-requestor-app/telink/Readme.md b/examples/ota-requestor-app/telink/Readme.md
index 00ed51b..b1f2947 100755
--- a/examples/ota-requestor-app/telink/Readme.md
+++ b/examples/ota-requestor-app/telink/Readme.md
@@ -154,7 +154,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/pump-app/telink/README.md b/examples/pump-app/telink/README.md
index b1e9238..19bdcc2 100755
--- a/examples/pump-app/telink/README.md
+++ b/examples/pump-app/telink/README.md
@@ -169,7 +169,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/pump-controller-app/telink/README.md b/examples/pump-controller-app/telink/README.md
index 1f3cd01..253b676 100755
--- a/examples/pump-controller-app/telink/README.md
+++ b/examples/pump-controller-app/telink/README.md
@@ -170,7 +170,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/temperature-measurement-app/telink/README.md b/examples/temperature-measurement-app/telink/README.md
index 68c79aa..4b33ad8 100644
--- a/examples/temperature-measurement-app/telink/README.md
+++ b/examples/temperature-measurement-app/telink/README.md
@@ -150,7 +150,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/thermostat/telink/Readme.md b/examples/thermostat/telink/Readme.md
index c8c306b..9b097c0 100755
--- a/examples/thermostat/telink/Readme.md
+++ b/examples/thermostat/telink/Readme.md
@@ -161,7 +161,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/examples/window-app/telink/README.md b/examples/window-app/telink/README.md
index a19defc..d8e0213 100644
--- a/examples/window-app/telink/README.md
+++ b/examples/window-app/telink/README.md
@@ -232,7 +232,7 @@
- Use the chip-tool to announce the ota-provider-app to start the OTA process
```
- ./chip-tool otasoftwareupdaterequestor announce-ota-provider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
+ ./chip-tool otasoftwareupdaterequestor announce-otaprovider ${OTA_PROVIDER_NODE_ID} 0 0 0 ${DEVICE_NODE_ID} 0
```
here:
diff --git a/scripts/tools/nrfconnect/nrfconnect_factory_data.schema b/scripts/tools/nrfconnect/nrfconnect_factory_data.schema
index 0c61d33..8c2d249 100644
--- a/scripts/tools/nrfconnect/nrfconnect_factory_data.schema
+++ b/scripts/tools/nrfconnect/nrfconnect_factory_data.schema
@@ -26,7 +26,7 @@
"description": "Current version of the factory data set",
"type": "integer",
"minimum": 0,
- "maximum": 255
+ "maximum": 65535
},
"sn": {
"description": "Serial number of device",
@@ -82,7 +82,7 @@
"description": "Hardware version - integer",
"type": "integer",
"minimum": 0,
- "maximum": 65536
+ "maximum": 65535
},
"hw_ver_str": {
"description": "A string representation of hardware version",
