Guidance Needed: Implementing OTA Firmware Updates Over Thread Mesh Network Using ESP-IDF (IDFGH-15267)

[kunj2308]

Is your feature request related to a problem?

I'm developing an OTA update solution for Thread mesh networks using Espressif hardware and would appreciate expert advice. My current setup consists of:

Border Router Configuration:

ESP32 (Wi-Fi) running the ot_br example

Connected via UART to ESP32-C6 running the ot_rcp example

Thread End Device:

ESP32-C6 running the ot_cli example

Implementation Goal:

Download firmware binary on Border Router (via Wi-Fi/Internet)

Transfer firmware securely over Thread mesh network to end device

Implement reliable OTA update process using ESP-IDF's OTA API

Technical Questions:

What modifications are needed to the OpenThread examples to support:

Firmware transfer over Thread

Chunking strategy for Thread's 127-byte MTU

Integrity verification (SHA256) and secure reboot

Are there known limitations with:

Thread network reliability for large binary transfers

ESP32-C6 flash write performance during OTA

Border router throughput constraints

Would alternative approaches be more suitable? For example:

Using CoAP for firmware transfer

Implementing a custom fragmentation protocol

Reference Materials:

ESP-IDF OpenThread Guide

Thread Network Specifications

OpenThread MTU Discussion

Additional Request:
If anyone has implemented similar OTA-over-Thread solutions, I would greatly appreciate any code examples or design insights you could share.

Describe the solution you'd like.

No response

Describe alternatives you've considered.

No response

Additional context.

No response

[tanyanquan]

Hi @kunj2308 thank you for your question. We currently don't have an example specifically designed for OTA updates using Thread on an end device, but the required components (such as the OTA API which you mentioned) are all available.

This is because OTA updates are typically handled at the application layer, such as Matter-over-Thread or Rainmaker-over-Thread, which will be more convenient instead. Could you let us know a bit more details about your goals below so we can provide a more targeted solution?

• Are you planning to use any application-layer protocols / ecosystems for your solution?

If you wish to try out a simple solution for OTA-updating a Thread device, we already have an example here for a Thread Border Router. If you connect another Thread BR (BR2) to the same network without connecting it to Wi-Fi, it will take on the role of end device and you can call the same command to start the OTA process for BR2 as well. Do note that depending on the stability of your Wi-Fi / Thread networks, this could take a long time and you may need to change some settings (e.g. http client timeout).

We are also working on extending the OTA API example to support Thread devices as well, which you can try in the near future!

[kunj2308]

Hi @kunj2308 thank you for your question. We currently don't have an example specifically designed for OTA updates using Thread on an end device, but the required components (such as the OTA API which you mentioned) are all available.

This is because OTA updates are typically handled at the application layer, such as Matter-over-Thread or Rainmaker-over-Thread, which will be more convenient instead. Could you let us know a bit more details about your goals below so we can provide a more targeted solution?

• Are you planning to use any application-layer protocols / ecosystems for your solution?

If you wish to try out a simple solution for OTA-updating a Thread device, we already have an example here for a Thread Border Router. If you connect another Thread BR (BR2) to the same network without connecting it to Wi-Fi, it will take on the role of end device and you can call the same command to start the OTA process for BR2 as well. Do note that depending on the stability of your Wi-Fi / Thread networks, this could take a long time and you may need to change some settings (e.g. http client timeout).

We are also working on extending the OTA API example to support Thread devices as well, which you can try in the near future!

Thank you @tanyanquan for the detailed explanation and guidance!

To clarify my goal:

I am building a custom Thread mesh network using ESP32-C6 devices, where each device operates as an end node (e.g., lighting controller). My intent is to:

Control GPIOs on the end device (e.g., switch lights ON/OFF).

Deploy firmware OTA over the Thread network to these end devices.

Avoid using higher-level ecosystems like Matter or Rainmaker, and instead work directly with OpenThread and the ESP-IDF OTA API.

Key Questions:
Can you share a list of Thread-based lighting end devices (either evaluation boards or commercial products) that:

Support OTA natively over Thread (not via Matter).

Can be integrated or emulated using ESP32-C6 or OpenThread CLI?

In current market implementations (besides Matter), how do companies implement OTA updates over Thread? Are they using CoAP-based fragmentation or some proprietary protocol layered over Thread?

Does Espressif have internal or upcoming OTA-over-Thread examples specifically for ESP32-C6 devices running as Thread end devices (e.g., light nodes)?

I'm working directly at the application layer using OpenThread CLI and ESP-IDF, and would prefer not to integrate Matter at this stage.

Thank you again for your help! If there's any beta/example code for Thread-based OTA end device support, I would be happy to test and contribute feedback.

[tanyanquan]

Hi @kunj2308 thanks for the clarifications. We understand that you prefer to avoid higher-level ecosystems - could you share with us what your considerations are (i.e. why you wish to implement your own application layer)? While there are many commercial products out there which opt to implement their own application layer (on top of Thread), these are normally proprietary implementations which are unfortunately seldomly shared openly.

Importantly, we would like to highlight that Thread is a network-layer protocol which does not intrinsically take care of application-layer features such as integrity verification / chunking which you have mentioned. The other features such as lighting control, OTA updates and more are also handled by the application-layer protocol (e.g. Matter, Rainmaker, or even HTTP). Depending on your needs, if you do not wish to use Matter or Rainmaker, you will need to implement many of these features yourself. For example, some of the design considerations include how both devices (host + end device) will coordinate the transfer of the OTA firmware (e.g. server + client structure), frequency of OTA update checks etc.

For now, if you want something simple to try out OTA updates using Thread network, perhaps you can consider using something simpler such as HTTP first. Have you seen our ESP HTTP OTA documentation? The steps required are roughly summarized below:

1. Set up HTTP server (e.g. on your own computer) connected to Wi-Fi network
2. Use a Thread Border Router (connected to the same Wi-Fi network) to start a Thread Network
3. Use your End Device to join the Thread Network created earlier
4. Call ota update via http URL on End Device

It would be somewhat similar to the simple ota example. This example currently supports Wi-Fi OTA updates but can also be extended to support Thread (albeit quite a bit slower) - could you let us know if this is something which fits your requirements?

[kunj2308]

Hi @tanyanquan ,

Thank you for the detailed clarifications and support.

We are from xyz Automations ,and we want to developing our own custom ecosystem based on a Thread mesh network using ESP32-C6 devices.

Our Goals:
We want to:

Build a minimal, lightweight system without Matter or Rainmaker

Control GPIOs on Thread end devices (e.g., switch lights ON/OFF)

Communicate directly via Thread protocol using OpenThread CLI and UDP messaging

Implement OTA firmware updates over the Thread mesh (without relying on Wi-Fi or external ecosystems)

We are intentionally avoiding Matter to keep the firmware lightweight and to maintain full control over the application layer. We understand this means we need to handle chunking, integrity checks (e.g., SHA256), and reliable transfer logic ourselves — and we are ready to do that.

Questions:
Is it mandatory to use Matter with Thread for real-world applications? Or is it fully acceptable to use Thread independently, with our own protocol for lighting control and OTA?

You mentioned that ESP-IDF has OTA examples like simple_ota_example, which works over Wi-Fi. Could you share a working (or in-development) example for OTA on Thread end devices (ESP32-C6 with ot_cli), where:

The firmware is downloaded on the Thread Border Router

It is sent to an end device over Thread (using chunked UDP or CoAP)

The ESP-IDF OTA API is used to write it to flash on the end device

If a working example doesn’t exist yet, is there a recommended way to extend the existing OpenThread CLI/ESP-IDF to enable this flow? Even an experimental branch would help — we’d be glad to test it and contribute feedback.

Thanks again for your support. A minimal OTA-over-Thread setup would greatly accelerate our development, and we are committed to building on Espressif’s stack for our production rollout.

[tanyanquan]

Hi @kunj2308 thanks for your clarifications! We are happy to hear that you intend to implement your own application layer using Thread as the networking protocol and that is definitely possible.

If you wish to use the simple_ota_example, we can start by extending it to include C6 (using Thread, so we'll need to turn off Wi-Fi). By default, this example uses HTTP (or HTTPS), so you can take a look at the set up instructions for simple_ota example.

We've prepared an esp-idf patch here which you can try: thread_ota.txt

Please add the following config options to examples/system/ota/simple_ota_example/sdkconfig.defaults (remember to change CONFIG_EXAMPLE_FIRMWARE_UPGRADE_URL):

CONFIG_EXAMPLE_FIRMWARE_UPGRADE_URL="https://192.168.0.123:8070/blink.bin"
CONFIG_EXAMPLE_SKIP_COMMON_NAME_CHECK=y

CONFIG_OPENTHREAD_ENABLED=y
CONFIG_EXAMPLE_CONNECT_WIFI=n
CONFIG_EXAMPLE_CONNECT_ETHERNET=n
CONFIG_EXAMPLE_CONNECT_THREAD=y
CONFIG_MBEDTLS_CMAC_C=y

You may also need to change the default Thread network configurations in idf.py menuconfig:

Component config → OpenThread → OpenThread → Thread Core Features → Thread Operational Dataset

We've tried this using a HTTP server on a Linux host machine + Thread BR (both connected to the same Wi-Fi network) + C6 end device. Do let us know how it goes 😄