From 2516016ddcc3fab96437c59823efd1c7ef84cbf2 Mon Sep 17 00:00:00 2001 From: Marcin Kajor <98948394+markaj-nordic@users.noreply.github.com> Date: Wed, 14 Jun 2023 11:34:04 +0200 Subject: [PATCH] [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 * 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 --------- Signed-off-by: Marcin Kajor --- .github/.wordlist.txt | 1 + docs/guides/esp32/ota.md | 8 ++-- docs/guides/infineon_psoc6_software_update.md | 2 +- .../nrfconnect_examples_software_update.md | 4 +- .../nrfconnect_factory_data_configuration.md | 44 +++++++++---------- docs/guides/silabs_efr32_software_update.md | 2 +- examples/all-clusters-app/telink/Readme.md | 2 +- .../all-clusters-minimal-app/telink/Readme.md | 2 +- examples/bridge-app/telink/README.md | 2 +- .../nxp/k32w/k32w0/README.md | 2 +- examples/contact-sensor-app/telink/README.md | 2 +- examples/light-switch-app/telink/README.md | 2 +- .../lighting-app/nxp/k32w/k32w0/README.md | 2 +- examples/lighting-app/telink/README.md | 2 +- examples/lock-app/telink/README.md | 2 +- examples/ota-requestor-app/ameba/README.md | 4 +- examples/ota-requestor-app/esp32/README.md | 2 +- .../infineon/cyw30739/README.md | 2 +- examples/ota-requestor-app/linux/README.md | 10 ++--- examples/ota-requestor-app/telink/Readme.md | 2 +- examples/pump-app/telink/README.md | 2 +- examples/pump-controller-app/telink/README.md | 2 +- .../telink/README.md | 2 +- examples/thermostat/telink/Readme.md | 2 +- examples/window-app/telink/README.md | 2 +- .../nrfconnect/nrfconnect_factory_data.schema | 4 +- 26 files changed, 57 insertions(+), 56 deletions(-) diff --git a/.github/.wordlist.txt b/.github/.wordlist.txt index 6e43cf46167d78..4375a4e77f3204 100644 --- a/.github/.wordlist.txt +++ b/.github/.wordlist.txt @@ -979,6 +979,7 @@ otaissues OTAProvider OTAProviderIpAddress OTAProviderNodeId +otaproviders OTAProviderSerialPort OTARequesterImpl OTARequestorDriver diff --git a/docs/guides/esp32/ota.md b/docs/guides/esp32/ota.md index fb243735fc9696..7c9c388b422cb9 100644 --- a/docs/guides/esp32/ota.md +++ b/docs/guides/esp32/ota.md @@ -35,15 +35,15 @@ control list. ### 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 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": , "endpoint": 0}, {"fabricIndex": 1, "providerNodeID": , "endpoint": 0}]' 0 @@ -65,7 +65,7 @@ After commissioning is successful, announce OTA provider's presence using chip-tool. On receiving this command OTA requestor will query for OTA image. ``` -./out/debug/chip-tool otasoftwareupdaterequestor announce-ota-provider 0 0 0 0 +./out/debug/chip-tool otasoftwareupdaterequestor announce-otaprovider 0 0 0 0 ``` ## Encrypted OTA diff --git a/docs/guides/infineon_psoc6_software_update.md b/docs/guides/infineon_psoc6_software_update.md index 713b0b1409b254..4367142b79e4d8 100644 --- a/docs/guides/infineon_psoc6_software_update.md +++ b/docs/guides/infineon_psoc6_software_update.md @@ -69,7 +69,7 @@ Infineon PSoC6 example applications by passing the * 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 608c29f444fd70..ebaf08f46a587f 100644 --- a/docs/guides/nrfconnect_examples_software_update.md +++ b/docs/guides/nrfconnect_examples_software_update.md @@ -81,7 +81,7 @@ To test the DFU over Matter, you need to complete the following steps: 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 @@ To test the DFU over Matter, you need to complete the following steps: 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 59eb99b50ad101..2abb6e58e17f96 100644 --- a/docs/guides/nrfconnect_factory_data_configuration.md +++ b/docs/guides/nrfconnect_factory_data_configuration.md @@ -89,28 +89,28 @@ about 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 adc95607914000..3d8649cf91511b 100644 --- a/docs/guides/silabs_efr32_software_update.md +++ b/docs/guides/silabs_efr32_software_update.md @@ -61,7 +61,7 @@ where operationalDataset is obtained from the OpenThread Border Router. - 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 ececcdb4a1fd0b..aaea384d83b4c5 100644 --- a/examples/all-clusters-app/telink/Readme.md +++ b/examples/all-clusters-app/telink/Readme.md @@ -163,7 +163,7 @@ Usage of OTA: - 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 f2fc7f4d0518ee..1051c077a3ed11 100644 --- a/examples/all-clusters-minimal-app/telink/Readme.md +++ b/examples/all-clusters-minimal-app/telink/Readme.md @@ -146,7 +146,7 @@ Usage of OTA: - 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 bec1790828de37..34ce68e54edb3d 100644 --- a/examples/bridge-app/telink/README.md +++ b/examples/bridge-app/telink/README.md @@ -308,7 +308,7 @@ Usage of OTA: - 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 bfbf287e113d6c..af98333cb8b99f 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 @@ user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing ble-th 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 d8d60e627d8875..68475be1d69c9b 100755 --- a/examples/contact-sensor-app/telink/README.md +++ b/examples/contact-sensor-app/telink/README.md @@ -165,7 +165,7 @@ Usage of OTA: - 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 bca98378dd8e6f..76f62c6db681ee 100755 --- a/examples/light-switch-app/telink/README.md +++ b/examples/light-switch-app/telink/README.md @@ -286,7 +286,7 @@ Usage of OTA: - 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 5019e8a4f612f6..674960ee0d560c 100644 --- a/examples/lighting-app/nxp/k32w/k32w0/README.md +++ b/examples/lighting-app/nxp/k32w/k32w0/README.md @@ -655,7 +655,7 @@ user@computer1:~/connectedhomeip$ : ./out/chip-tool-app/chip-tool pairing ble-th 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 e9c4c5a104780c..ddb536496e77bc 100644 --- a/examples/lighting-app/telink/README.md +++ b/examples/lighting-app/telink/README.md @@ -251,7 +251,7 @@ Usage of OTA: - 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 8905d996d7f666..d6eefac21b5fdd 100755 --- a/examples/lock-app/telink/README.md +++ b/examples/lock-app/telink/README.md @@ -168,7 +168,7 @@ Usage of OTA: - 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 73be70beeef4f2..029cbed876b7ba 100644 --- a/examples/ota-requestor-app/ameba/README.md +++ b/examples/ota-requestor-app/ameba/README.md @@ -53,7 +53,7 @@ A prototype application that demonstrates OTA Requestor capabilities. 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 @@ A prototype application that demonstrates OTA Requestor capabilities. 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 734985783df06c..1951b4535b13ca 100644 --- a/examples/ota-requestor-app/esp32/README.md +++ b/examples/ota-requestor-app/esp32/README.md @@ -28,7 +28,7 @@ After commissioning is successful, announce OTA provider's presence using chip-tool. On receiving this command OTA requestor will query for OTA image. ``` -./out/debug/chip-tool otasoftwareupdaterequestor announce-ota-provider 0 0 0 0 +./out/debug/chip-tool otasoftwareupdaterequestor announce-otaprovider 0 0 0 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 0a55e93bf60a1d..629418c395d552 100644 --- a/examples/ota-requestor-app/infineon/cyw30739/README.md +++ b/examples/ota-requestor-app/infineon/cyw30739/README.md @@ -135,5 +135,5 @@ Put the CYW30739 in to the recovery mode before running the flash script. 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 9cb47171aae555..d347ffaf0e52a6 100644 --- a/examples/ota-requestor-app/linux/README.md +++ b/examples/ota-requestor-app/linux/README.md @@ -306,7 +306,7 @@ out/chip-tool pairing onnetwork-long 0x1234567890 20202021 18 **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 @@ out/chip-tool pairing onnetwork-long 0xB0B 20202021 18 --commissioner-name beta **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 00ed51bbb4182d..b1f2947a4e3a1b 100755 --- a/examples/ota-requestor-app/telink/Readme.md +++ b/examples/ota-requestor-app/telink/Readme.md @@ -154,7 +154,7 @@ Usage of OTA: - 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 b1e923856b2588..19bdcc291e5fb6 100755 --- a/examples/pump-app/telink/README.md +++ b/examples/pump-app/telink/README.md @@ -169,7 +169,7 @@ Usage of OTA: - 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 1f3cd0130f248a..253b676e7392fa 100755 --- a/examples/pump-controller-app/telink/README.md +++ b/examples/pump-controller-app/telink/README.md @@ -170,7 +170,7 @@ Usage of OTA: - 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 68c79aabd1b2f4..4b33ad843c7e84 100644 --- a/examples/temperature-measurement-app/telink/README.md +++ b/examples/temperature-measurement-app/telink/README.md @@ -150,7 +150,7 @@ Usage of OTA: - 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 c8c306bda9d73b..9b097c02ad9611 100755 --- a/examples/thermostat/telink/Readme.md +++ b/examples/thermostat/telink/Readme.md @@ -161,7 +161,7 @@ Usage of OTA: - 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 a19defc822f1a4..d8e02132cd6bec 100644 --- a/examples/window-app/telink/README.md +++ b/examples/window-app/telink/README.md @@ -232,7 +232,7 @@ Usage of OTA: - 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 0c61d3330826c3..8c2d249bb7bdc0 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",