mirror of
https://github.com/espressif/esp-matter.git
synced 2026-04-27 19:13:13 +00:00
Merge branch 'docs_update' into 'main'
Update the Matter documentation See merge request app-frameworks/esp-matter!132
This commit is contained in:
+1
-1
@@ -10,7 +10,7 @@ Use actual documentation generated within about 20 minutes on each commit:
|
||||
|
||||
* English: https://docs.espressif.com/projects/esp-matter/
|
||||
|
||||
The above URL is for the master branch latest version. Click the drop-down in the bottom left to choose a particular version or to download a PDF.
|
||||
The above URL is for the main branch latest version. Click the drop-down in the bottom left to choose a particular version or to download a PDF.
|
||||
|
||||
# Building Documentation
|
||||
|
||||
|
||||
Vendored
BIN
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
@@ -1,5 +1,4 @@
|
||||
3. Matter Certification
|
||||
=======================
|
||||
|
||||
todo. Get your product certified. also mention about dcl.
|
||||
|
||||
This section will be updated soon.
|
||||
|
||||
+19
-121
@@ -8,7 +8,7 @@ ESP Matter releases
|
||||
---------------------
|
||||
|
||||
This section talks about setting up your development host, fetching the
|
||||
Git repositories, and instructions for build and flash.
|
||||
Git repositories, and instructions to build and flash.
|
||||
|
||||
2.1.1 Host Setup
|
||||
~~~~~~~~~~~~~~~~
|
||||
@@ -99,7 +99,7 @@ Choose IDF target.
|
||||
- The default device for ``esp32``/``esp32c3`` is
|
||||
``esp32-devkit-c``/``esp32c3-devkit-m``. If you want to use another
|
||||
device, you can export ``ESP_MATTER_DEVICE_PATH`` after choosing
|
||||
correct target, e.g for ``m5stack`` device:
|
||||
the correct target, e.g. for ``m5stack`` device:
|
||||
``export ESP_MATTER_DEVICE_PATH=/path/to/esp_matter/device_hal/device/m5stack``
|
||||
|
||||
- If the device that you have is of a different revision, and is not
|
||||
@@ -138,18 +138,18 @@ Choose IDF target.
|
||||
2.2.1 Test Setup (CHIP Tool)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A host-based chip-tool can be used as a Matter client to commission and control the device.
|
||||
A host-based chip-tool can be used as a commissioner to commission and control a Matter device.
|
||||
|
||||
2.2.1.1 Commissioning
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Use ``chip-tool`` to pair the device:
|
||||
Use ``chip-tool`` to commission the device:
|
||||
|
||||
.. only:: esp32 or esp32c3
|
||||
|
||||
::
|
||||
|
||||
chip-tool pairing ble-wifi 0x7283 <ssid> <password> 20202021 3840
|
||||
chip-tool pairing ble-wifi 0x7283 <ssid> <passphrase> 20202021 3840
|
||||
|
||||
.. only:: esp32h2
|
||||
|
||||
@@ -167,7 +167,7 @@ In the above commands:
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The device would need additional configuration depending on the example,
|
||||
for it to work. Check the example's "Post Commissioning Setup" section for more information.
|
||||
for it to work. Check the "Post Commissioning Setup" section in examples for more information.
|
||||
|
||||
- :project_file:`Light <examples/light/README.md>`
|
||||
- :project_file:`Light Switch <examples/light_switch/README.md>`
|
||||
@@ -290,7 +290,7 @@ the device is helpful.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A device is represented in Matter in terms of its data model. As a first
|
||||
step of building your product, you will define the data model for your
|
||||
step of building your product, you will have to define the data model for your
|
||||
device. Matter has a standard set of device types already defined that you
|
||||
can use. Please refer to the
|
||||
`Espressif Matter Blog <https://blog.espressif.com/matter-clusters-attributes-commands-82b8ec1640a0>`__
|
||||
@@ -300,7 +300,7 @@ for clarity on the terms like endpoints, clusters, etc. that are used in this se
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- Typically, the data model is defined in the example's *app_main.cpp*.
|
||||
First off we start by creating the Matter node, which is the root of
|
||||
First off we start by creating a Matter node, which is the root of
|
||||
the Data Model.
|
||||
|
||||
::
|
||||
@@ -330,7 +330,7 @@ for clarity on the terms like endpoints, clusters, etc. that are used in this se
|
||||
- Whenever a Matter client makes changes to the device, they end up
|
||||
updating the attributes in the data model.
|
||||
|
||||
- When an attribute is updated, the attribute_update callback is used
|
||||
- When an attribute is updated, the attribute_update_cb is used
|
||||
to notify the application of this change. You would typically call
|
||||
device driver specific APIs for executing the required action. Here,
|
||||
if the callback type is ``PRE_UPDATE``, the driver is updated first.
|
||||
@@ -411,22 +411,17 @@ for clarity on the terms like endpoints, clusters, etc. that are used in this se
|
||||
return err;
|
||||
}
|
||||
|
||||
2.4.1.4 Matter Device Ready
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
With the few lines of code that we've written above, your
|
||||
full-certifiable Matter device is now ready.
|
||||
|
||||
2.4.2 Defining your own data model
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Creating standard endpoints, clusters, attributes, commands. This can be
|
||||
used for the fields which HAVE been defined in the Matter specification.
|
||||
This section demonstrates creating standard endpoints, clusters, attributes,
|
||||
and commands that are defined in the Matter specification
|
||||
|
||||
2.4.2.1 Endpoints
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
The 'device' can be customized by editing the endpoint/device_type
|
||||
The device can be customized by editing the endpoint/device_type
|
||||
creating in the *app_main.cpp* of the example. Examples:
|
||||
|
||||
- on_off_light:
|
||||
@@ -474,7 +469,7 @@ Additional clusters can also be added to an endpoint. Examples:
|
||||
2.4.2.3 Attributes and Commands
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Additional attributes or commands can also be added to a cluster.
|
||||
Additional attributes and commands can also be added to a cluster.
|
||||
Examples:
|
||||
|
||||
- attribute: on_off:
|
||||
@@ -506,9 +501,9 @@ Examples:
|
||||
2.4.3 Adding custom data model fields
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Creating custom endpoints, clusters, attributes, commands. This can be
|
||||
used for the fields which HAVE NOT been defined in the Matter
|
||||
specification.
|
||||
This section demonstrates creating custom endpoints, clusters, attributes,
|
||||
and commands that are not defined in the Matter specification and can be
|
||||
specific to the vendor.
|
||||
|
||||
2.4.3.1 Endpoints
|
||||
^^^^^^^^^^^^^^^^^
|
||||
@@ -560,10 +555,9 @@ Non-Standard/Custom attributes can also be created on any cluster:
|
||||
uint32_t custom_command_id = 0x0;
|
||||
command_t *command = command::create(cluster, custom_command_id, COMMAND_FLAG_ACCEPTED, command_callback);
|
||||
|
||||
2.4.4 Adding External Platforms for Matter
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This step is **optional** for most devices. ESP Matter provides support for overriding the default platform layer, so the BLE and Wi-Fi implementations can be customized. Here are the required steps for adding an external platform layer.
|
||||
2.4.4 Advanced Setup
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
This section explains adding external platforms for Matter. This step is **optional** for most devices. ESP Matter provides support for overriding the default platform layer, so the BLE and Wi-Fi implementations can be customized. Here are the required steps for adding an external platform layer.
|
||||
|
||||
2.4.4.1 Creating the external platform directory
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -622,99 +616,3 @@ As an example, you can build *light* example on ``ESP32_custom`` platform with f
|
||||
cd $ESP_MATTER_PATH/examples/light
|
||||
cp sdkconfig.defaults.ext_plat_ci sdkconfig.defaults
|
||||
idf.py build
|
||||
|
||||
You can also refer to the :project_file:`BLE Mesh Bridge example <examples/blemesh_bridge/README.md>`, this example customizes the BLE implementation to meet the BLE mesh bridge application.
|
||||
|
||||
2.5. Common Peripherals
|
||||
-----------------------
|
||||
|
||||
2.5.1 Button Driver
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- In the examples, the boot button on the devkit is mapped to
|
||||
``toggle``. In case the device is a client (eg. light_switch), the toggle
|
||||
command is sent to the binded devices.
|
||||
- Factory reset has also been mapped to the same boot button. When the
|
||||
button is pressed for more than 5 seconds, factory reset is
|
||||
triggered.
|
||||
|
||||
.. _using-a-different-button-driver:
|
||||
|
||||
2.5.1.1 Using a different button driver
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Out of the box, the SDK supports the button driver for buttons connected
|
||||
through GPIO or through ADC using a resistor divider circuit. You can
|
||||
switch the button driver by changing the *button_type* appropriately in
|
||||
your *esp_matter_device.cmake* file.
|
||||
|
||||
The selected button driver will be initialised in *app_driver_init()* by
|
||||
calling the *button_driver_get_config()* and the *iot_button_create()*
|
||||
APIs for that driver. More button driver configurations for button
|
||||
events can be done in *app_driver_init()*.
|
||||
|
||||
2.5.1.2 Writing your own button driver
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the Button driver that you wish to use is not part of Espressif's
|
||||
supported list, you can write a driver for it yourself.
|
||||
|
||||
A reference hollow_button is available within the SDK at
|
||||
:project_file:`hollow_button/button_driver.c <device_hal/button_driver/button/hollow_button/button_driver.c>`. This includes all
|
||||
the skeletal code and the empty APIs that the button driver is supposed
|
||||
to implement to plug into the SDK.
|
||||
|
||||
The driver has to implement the APIs in *button_driver.c*. These
|
||||
typically include APIs for initializing the driver and checking for
|
||||
button events. Take a look at *iot_button.h* for API definitions. You
|
||||
can also take a look at other button drivers for reference.
|
||||
|
||||
The configurations that this driver needs can be done from
|
||||
*button_driver_get_config()* in *device.c*
|
||||
|
||||
Once this driver is implemented, use this driver as mentioned in the
|
||||
subsection for :ref:`Using a different button driver <using-a-different-button-driver>`.
|
||||
|
||||
2.5.2 LED Driver
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
- In the light examples, the led on the devkit is initialized and the
|
||||
default values for power, brightness, hue, saturation, temperature, etc. are set
|
||||
to the default values from the data model.
|
||||
|
||||
.. _using-a-different-led-driver:
|
||||
|
||||
2.5.2.1 Using a different LED driver
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Espressif has production-ready drivers for a known set of LED drivers
|
||||
that we support out of the box. Please reach out to your Espressif
|
||||
representative to get a list of these drivers. Once you have the driver,
|
||||
you can rebuild the SDK by modifying your *esp_matter_device.cmake* file
|
||||
to point to the appropriate LED driver.
|
||||
|
||||
The selected LED driver will be initialised in *app_driver_init()* by
|
||||
calling the *led_driver_get_config()* and the *led_driver_init()* APIs
|
||||
for that driver.
|
||||
|
||||
2.5.2.2 Writing your own LED driver
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the LED driver that you wish to use is not part of Espressif's
|
||||
supported list, you can write a driver for it yourself.
|
||||
|
||||
A reference hollow_led is available within the SDK at
|
||||
:project_file:`hollow_led/led_driver.c <device_hal/led_driver/hollow_led/led_driver.c>`. This includes all the
|
||||
skeletal code and the empty APIs that the LED driver is supposed to
|
||||
implement to plug into the SDK.
|
||||
|
||||
The driver has to implement the APIs in *led_driver.c*. These typically
|
||||
include APIs for initializing the driver and controlling the LEDs. Take
|
||||
a look at *led_driver.h* for API definitions. You can also take a look
|
||||
at other LED drivers for reference.
|
||||
|
||||
If there are any configurations that this driver needs, that can be done
|
||||
from *led_driver_get_config()* in *device.c*
|
||||
|
||||
Once this driver is implemented, use this driver as mentioned in the
|
||||
subsection for :ref:`Using a different led driver <using-a-different-led-driver>`.
|
||||
|
||||
+3
-8
@@ -3,18 +3,13 @@ ESP Matter Programming Guide
|
||||
|
||||
`Matter <https://csa-iot.org/all-solutions/matter/>`__ is a unified IP-based
|
||||
connectivity protocol that is designed to connect and build open, reliable
|
||||
and secure IoT ecosystems. This new technology and royalty-free connectivity
|
||||
standard enables communications among a wide range of smart devices.
|
||||
and secure IoT ecosystems. This new technology and connectivity standard enables
|
||||
communication among a wide range of smart devices. Matter supports IP connectivity over Wi-Fi, Thread and Ethernet.
|
||||
|
||||
ESP Matter is the official Matter development framework for
|
||||
Espressif's ESP32 series SoCs.
|
||||
|
||||
.. figure:: ../_static/solution_architecture.png
|
||||
:align: center
|
||||
:alt: ESP Matter Solution Architecture
|
||||
:figclass: align-center
|
||||
|
||||
Espressif has put together a series of blog posts that talk about various aspects of Matter. You can see here: `Espressif Matter Blog <https://blog.espressif.com/matter-38ccf1d60bcd>`__.
|
||||
We have put together a series of blog posts that introduces various aspects of Matter. We recommend that you go through this `Espressif Matter Blog <https://blog.espressif.com/matter-38ccf1d60bcd>`__.
|
||||
|
||||
Table of Contents
|
||||
=================
|
||||
|
||||
+17
-19
@@ -4,31 +4,36 @@
|
||||
1.1 Espressif Matter Solutions
|
||||
------------------------------
|
||||
|
||||
.. figure:: ../_static/solution_architecture.png
|
||||
:align: center
|
||||
:alt: ESP Matter Solution Architecture
|
||||
:figclass: align-center
|
||||
|
||||
Espressif's Matter Solutions consist of:
|
||||
|
||||
- A Full Spectrum of Matter device platforms
|
||||
- A full spectrum of Matter device platforms
|
||||
- Production ready ESP Matter SDK
|
||||
- Matter and ESP RainMaker integration
|
||||
|
||||
1.1.1 Espressif Matter Platforms
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Espressif provides a full spectrum Matter device platforms:
|
||||
Espressif platform solutions are as shown below:
|
||||
|
||||
.. figure:: ../_static/esp_matter_platform.png
|
||||
:align: center
|
||||
:alt: ESP Matter Platform
|
||||
:figclass: align-center
|
||||
|
||||
- The Wi-Fi-enabled SoCs and modules, such as ESP32, ESP32-C and ESP32-S series can be used to build Matter Wi-Fi devices.
|
||||
- ESP32-H SoCs and modules integrated with 802.15.4 can be used to build Matter Thread devices.
|
||||
- By efficiently combining ESP32-H and Espressif's Wi-Fi SoC, a Thread border router can be built to connect the Thread network with the Wi-Fi network to interconnect devices. Espressif provides hardware devkits, reference design and production-ready SDK, which supports the latest Thread 1.3 feature for Matter, and other features like coexistence and OTA (Over-the-Air) updates.
|
||||
- Espressif also provides Matter-Zigbee and Matter-BLE Mesh bridge solutions that enable non-Matter devices based on Zigbee, Bluetooth LE Mesh and other protocols to connect to the Matter ecosystem. A Matter-Zigbee Bridge uses ESP32-H and another Wi-Fi SoC, while a Matter-BLE Mesh Bridge can be done on single SoC with both Wi-Fi and Bluetooth LE interfaces.
|
||||
- The Wi-Fi-enabled SoCs and modules, such as ESP32, ESP32-C and ESP32-S series can be used to build **Matter Wi-Fi devices**.
|
||||
- ESP32-H SoCs and modules with 802.15.4 can be used to build **Matter Thread devices**.
|
||||
- By efficiently combining ESP32-H and our Wi-Fi SoCs, a **Thread Border Router** can be built to connect the Thread network with the Wi-Fi network. We provide hardware devkits, reference designs and production-ready SDK, which supports the latest Thread 1.3 feature for Matter.
|
||||
- We also provide Matter-Zigbee and Matter-BLE Mesh bridge solutions that enable non-Matter devices based on Zigbee, Bluetooth LE Mesh and other protocols to connect to the Matter ecosystem. A **Matter-Zigbee Bridge** uses ESP32-H and another Wi-Fi SoC, while a **Matter-BLE Mesh Bridge** can be done on a single SoC with both Wi-Fi and Bluetooth LE interfaces.
|
||||
|
||||
1.1.2 ESP Matter SDK
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Espressif's Matter SDK is built on top of `connectedhomeip <https://github.com/project-chip/connectedhomeip/>`__, and integrates ESP Data Model APIs, commonly used peripherals, tools and utilities for security, manufacturing and production accompanied by exhaustive documentation. It is a production ready Matter SDK with rich production references, aimed to simplify the development process of Matter products and enable the users to go to production in the shortest possible time.
|
||||
Espressif's Matter SDK is built on top of the `open source Matter SDK <https://github.com/project-chip/connectedhomeip/>`__, and provides simplified APIs, commonly used peripherals, tools and utilities for security, manufacturing and production accompanied by exhaustive documentation. It includes rich production references, aimed to simplify the development process of Matter products and enable the users to go to production in the shortest possible time.
|
||||
|
||||
.. figure:: ../_static/software_components.png
|
||||
:align: center
|
||||
@@ -42,22 +47,15 @@ In addition, ESP Matter SDK also integrates `ESP RainMaker <https://rainmaker.es
|
||||
|
||||
Espressif's AIoT cloud platform `ESP RainMaker <https://rainmaker.espressif.com/>`__ can provide remote control and enable cloud-based device management for Matter devices.
|
||||
|
||||
By combining the above-mentioned Matter hardware and software solutions with ESP RainMaker, this one-stop Matter ecosystem solution provides:
|
||||
By combining the above-mentioned Matter hardware and software solutions with ESP RainMaker, this one-stop Matter ecosystem solution provides a full-fledged cloud deployment through your own private account with advanced device management features.
|
||||
|
||||
- Full-fledged Cloud deployment through own private account
|
||||
- Privately deployable cloud applications
|
||||
- Ready-made phone apps supporting all common smart-home scenarios and voice-assistant integrations
|
||||
|
||||
Relying on the privatization feature of ESP RainMaker, manufacturers
|
||||
can even build their own brand of an IoT ecosystem, and provide more value-added services to end customers
|
||||
through their own cloud services.
|
||||
|
||||
1.2 Try it yourself
|
||||
-------------------
|
||||
|
||||
1.2.1 ESP Launchpad
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
If you want to test Matter on Espressif devices without any additional setup:
|
||||
|
||||
This allows you to quickly try out Matter on Espressif devices through a web browser.
|
||||
|Try it with Launchpad|_
|
||||
|
||||
ESP Launchpad: https://espressif.github.io/esp-launchpad/.
|
||||
.. |Try it with Launchpad| image:: ../_static/launchpad.png
|
||||
.. _Try it with Launchpad: https://espressif.github.io/esp-launchpad/
|
||||
|
||||
+95
-30
@@ -1,19 +1,92 @@
|
||||
4. Production Considerations
|
||||
============================
|
||||
|
||||
4.1 Over-the-air Updates (OTA)
|
||||
4.1 Prerequisites
|
||||
-----------------
|
||||
|
||||
All Matter examples use certain test or evaluation values that enables you to quickly build and test Matter. As you get ready to go to production, these must be replaced with the actual values. These values are typically a part of the manufacturing partition in your device.
|
||||
|
||||
4.1.1 Vendor ID and Product ID
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A **Vendor Identifier (VID)** is a 16-bit number that uniquely identifies a particular
|
||||
product manufacturer or a vendor. It is allocated by the Connectivity Standards
|
||||
Alliance (CSA). Please reach out to CSA for this.
|
||||
|
||||
A **Product Identifier (PID)** is a 16-bit number that uniquely identifies a product
|
||||
of a vendor. It is assigned by the vendor (you).
|
||||
|
||||
A VID-PID combination uniquely identifies a Matter product.
|
||||
|
||||
4.1.2 Certificates
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A **Device Attestation Certificate (DAC)** proves the authenticity of the device
|
||||
manufacturer and the certification status of the device's hardware and software.
|
||||
Every Matter device must have a DAC and corresponding private key, unique to it.
|
||||
The device should also have a Product Attestation Intermediate (PAI) certificate
|
||||
that was used to sign and attest the DAC. The PAI certificate in turn is signed
|
||||
and attested by Product Attestation Authority (PAA).
|
||||
The PAA certificate is an implicitly trusted self-signed root certificate.
|
||||
|
||||
Please reach out to your Espressif representative for the details about how to
|
||||
procure the DAC.
|
||||
|
||||
4.1.3 Certification Declaration (CD)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A **Certification Declaration (CD)** is a cryptographic document that allows a Matter
|
||||
device to assert its protocol compliance. Once your product is certified, the CSA
|
||||
creates a CD for that device. The CD should then be included in the device firmware
|
||||
by the device manufacturer.
|
||||
|
||||
4.1.4 Setup Passcode, Discriminator and Onboarding Payload
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The unique **setup passcode** serves as the proof of possession and is also used to compute
|
||||
the shared secret during commissioning. The corresponding SPAKE2+ verifier of the
|
||||
passcode is installed on the device and not the actual passcode.
|
||||
|
||||
The **discriminator** is used to easily distinguish between devices to provide a seamless
|
||||
experience during commissioning.
|
||||
|
||||
The onboarding payload is the **QR code** and the **manual pairing code** that assists
|
||||
a commissioner (like a phone app) to allow onboarding a device into the Matter network.
|
||||
The QR code and/or the manual pairing code are generally printed on the packaging of the
|
||||
device.
|
||||
|
||||
|
||||
4.1.5 Manufacturing Partition
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ESP Matter SDK uses a separate manufacturing partition to store all the information
|
||||
mentioned above. Because the DACs are unique to every device, the manufacturing partition
|
||||
will also be unique per device. Thus by moving all the typical per device unique fields into
|
||||
the manufacturing partition, the rest of the components like the bootloader, firmware image
|
||||
are common across all your devices. You can refer the Manufacturing section below for creating
|
||||
a large number of manufacturing partition images.
|
||||
|
||||
Your manufacturing line needs to ensure that these unique manufacturing parition images are
|
||||
correctly written to each device and the appropriate QR code images associated with each device.
|
||||
You may also opt for Espressif's pre-provisioning service that pre-provisions these unique
|
||||
images before shipping the modules and provides a manifest (CSV file) along with QR code images
|
||||
bundle.
|
||||
|
||||
|
||||
4.2 Over-the-Air (OTA) Updates
|
||||
------------------------------
|
||||
|
||||
ESP-IDF has a component for OTA from any URL. More information and
|
||||
details about implementing can be found here:
|
||||
`esp_https_ota <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/esp_https_ota.html#esp-https-ota>`__.
|
||||
Matter devices must support OTA firmware updates, either by using Matter-based OTA
|
||||
or vendor specific means.
|
||||
|
||||
todo. add about DCL.
|
||||
In case of Matter OTA, there's an *OTA provider* that
|
||||
assists an *OTA requestor* to get upgraded. ESP Matter examples support Matter OTA
|
||||
requestor role out of the box. The OTA provider could be a manufacturer specific
|
||||
phone app or any Matter node that has internet connectivity.
|
||||
|
||||
4.2 Getting your own Vendor ID and Product ID
|
||||
---------------------------------------------
|
||||
Alternatively, `ESP RainMaker OTA <https://rainmaker.espressif.com/docs/ota.html>`__
|
||||
service can also be used to upgrade the firmware on the devices remotely. As opposed to the Matter OTA, ESP RainMaker OTA allows you the flexibility of delivering the OTA upgrades incrementally or to groups of devices.
|
||||
|
||||
todo. Info about DAC, pai, paa too.
|
||||
|
||||
4.3 Manufacturing
|
||||
-----------------
|
||||
@@ -27,10 +100,11 @@ For commissioning a device into the Matter Fabric, the device requires the follo
|
||||
- **Discriminator**: advertised during commissioning to easily distinguish between advertising devices.
|
||||
- **Spake2+ parameters**: work as a proof of possession.
|
||||
|
||||
These details are generally programmed in the factory NVS partitions that are unique
|
||||
per device. ESP-Matter provides a utility (mfg_tool.py) to create instances of the factory NVS partition images on a per-device basis for mass manufacturing purposes.
|
||||
These details are generally programmed in the manufacturing partition that is unique
|
||||
per device. ESP-Matter provides a utility (mfg_tool.py) to create these partition images
|
||||
on a per-device basis for mass manufacturing purposes.
|
||||
|
||||
When using the utility, by default, the above details will be included in the generated NVS partition image. The utility also has provision to include additional details in the same NVS image by using the config and value CSV files.
|
||||
When using the utility, by default, the above details will be included in the generated manufacturing partition image. The utility also has a provision to include additional details in the same image by using CSV files.
|
||||
|
||||
Details about using the ESP Matter mass manufacturing utility can be found here:
|
||||
:project_file:`mfg_tool<tools/mfg_tool/README.md>`.
|
||||
@@ -38,21 +112,21 @@ Details about using the ESP Matter mass manufacturing utility can be found here:
|
||||
4.3.2 Pre-Provisioned Modules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
ESP32 modules can be pre-flashed with the factory NVS partition during
|
||||
manufacturing itself and then be shipped to you.
|
||||
ESP32 modules can be pre-flashed with the manufacturing partition images
|
||||
during module manufacturing itself and then be shipped to you.
|
||||
|
||||
This saves you the overhead of securely generating, encrypting and then
|
||||
programming the NVS partition into the device at your end.
|
||||
Pre-provisioning is an optional service which Espressif provides.
|
||||
|
||||
Details about pre-provisioned modules can be found here:
|
||||
`docs <https://glab.espressif.cn/alexa/esp-va-sdk/wikis/home>`__.
|
||||
programming the partition into the device at your end.
|
||||
|
||||
Please contact your Espressif contact person for more information.
|
||||
|
||||
4.4 Security
|
||||
------------
|
||||
|
||||
Matter conformance requires you to protect the DACs that are uniquely programmed
|
||||
on each device. To achieve this, you need to take care of the following aspects.
|
||||
|
||||
|
||||
4.4.1 Secure Boot
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -63,11 +137,8 @@ the software boot loader for authenticity using the RSA algorithm. The
|
||||
verified software boot loader then checks the partition table and
|
||||
verifies the active application firmware and then boots it.
|
||||
|
||||
More information about how secure boot works on ESP32 can be found here:
|
||||
`docs <https://glab.espressif.cn/alexa/esp-va-sdk/wikis/home>`__.
|
||||
|
||||
Details about implementing the secure boot can be found here:
|
||||
`secure_boot <https://docs.espressif.com/projects/esp-idf/en/latest/security/secure-boot.html>`__.
|
||||
`secure_boot <https://docs.espressif.com/projects/esp-idf/en/v4.4.1/security/secure-boot.html>`__.
|
||||
|
||||
4.4.2 Flash Encryption
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -80,11 +151,8 @@ key and place them in the cache after decryption. It also has ability to
|
||||
allow to write the data to the flash by encrypting it. Both the
|
||||
read/write encryption operations happen transparently.
|
||||
|
||||
More information about how flash encryption works on ESP32 can be found
|
||||
here: `docs <https://glab.espressif.cn/alexa/esp-va-sdk/wikis/home>`__.
|
||||
|
||||
Details about implementing the flash encryption can be found here:
|
||||
`flash_encryption <https://docs.espressif.com/projects/esp-idf/en/latest/security/flash-encryption.html>`__.
|
||||
`flash_encryption <https://docs.espressif.com/projects/esp-idf/en/v4.4.1/security/flash-encryption.html>`__.
|
||||
|
||||
4.4.3 NVS Encryption
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -100,8 +168,5 @@ This flash partition is then encrypted using flash encryption. So, flash
|
||||
encryption becomes a mandatory feature to secure the NVS encryption
|
||||
keys.
|
||||
|
||||
More information about how NVS encryption works on ESP32 can be found
|
||||
here: `docs <https://glab.espressif.cn/alexa/esp-va-sdk/wikis/home>`__.
|
||||
|
||||
Details about implementing the NVS encryption can be found here:
|
||||
`nvs_encryption <https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/storage/nvs_flash.html#nvs-encryption>`__.
|
||||
`nvs_encryption <https://docs.espressif.com/projects/esp-idf/en/v4.4.1/api-reference/storage/nvs_flash.html#nvs-encryption>`__.
|
||||
|
||||
Reference in New Issue
Block a user