Test of OpenThread RCP on Espressif hardware

[Nerivec]

Anyone willing and able to build and experiment some more, please share your findings here!

https://github.com/espressif/esp-idf/blob/master/examples/openthread/ot_rcp/README.md

Current reported state:

Known issues:

Known limitations:

[bitcoin1192]

Examples compiled and running. ZoH is working good for me (so far joining and receiving report works) except for a few hiccup like binding device (still exploring this issue). Tested in a network with 8 other devices.

Edit: i notice that ot_rcp over usb on esp32 isn't stable right now ? i am on a build from master branch of esp-idf. What weird is, z2m doesn't restart/crash, and it kept sending to esp but met with no response. Switching to uart interface for stability reason

PS: Did anyone have issue with outgoing connection stop working after restarting z2m ? Receiving works fine, but sending command always fail

[Nerivec]

Thanks for the feedback!
The "binding hiccups" are known, still have to investigate these 😁

[mkopec]

I had a similar experience running the ot_rcp example on my Seeed XIAO ESP32-C6 board. Some crashing was resolved by switching to v6.0-rc1 revision of ESP-IDF. However Z2M still crashes a lot, and loses connectivity to some devices after a restart, requiring a re-pairing. Plus sending commands to devices fails.

[bitcoin1192]

regarding needing to repair zigbee devices, i've seen someone issue in esp-idf repo espressif/esp-idf#18454 where ot-rcp firmware interfere with 802.15.4 address and traffic filtering, that cause ack not being sent when other zigbee device trying to send some unicast message to coordinator. might be relevant here as i capture pretty much the same thing happen in case of zigbee device need to be repair

[tostmann]

Thanks for zigbee-on-host — and for being upfront that single-handedly supporting every radio, ESP32 in particular, isn't something you want to take on. That's entirely fair, and nothing below is a request for you to do so. We just wanted to leave an honest, evidence-based record instead of a silent "didn't work".

We put a considerable amount of time and bench/compute effort into reproducing and diagnosing the ESP32-C6 reports here (and in #40 / #124). Bottom line: we did not reach a comprehensively functional ZOH setup — and that statement is deliberately not ESP-only. We ran the same joiner against a third-party radio (an EFR32 / Silicon Labs OT-RCP, i.e. one in your "ongoing" firmware tier), and the most consequential failure reproduced there too, on the host side.

Host / trust-center — not radio-specific, reproduced on the EFR32 radio. A Zigbee-3.0 joiner that requires the TC-link-key exchange (a standard BDB mechanism; the esp-zigbee end-device sample has it enabled by default) joins fine, completes node-descriptor → active-endpoints → simple-descriptor → modelId read, then sends APS Request-Key (TC link key). ZOH transports back the global default key, and the exchange never completes — no Verify-Key, no Confirm-Key — so the device issues an orderly NWK Leave and rejoins, looping indefinitely with a fresh short address each cycle. Commercial Zigbee-3.0 devices (IKEA, Tuya in our tests) accept the global key and interview cleanly, so this is a specific interop gap with joiners that require the TC-link-key update to be completed, not a blanket failure. It reproduced identically against the EFR32 radio, which is why we flag it as host-side rather than ESP-specific.

Radio / firmware (Spinel) — where our actual doubt lies. Setting ZOH aside: we have justified doubt that the OT-RCP firmware shipping today robustly implements the Spinel raw-802.15.4 (STREAM_RAW) path for the Zigbee use-case. Each firmware-side defect we hit lives in a code path that the Thread/Matter use of these same RCPs does not exercise:

• ESP ot_rcp — otPlatUartSendDone() is not called when a USB-Serial/JTAG write fails, stalling HDLC TX (ot_rcp with USB serial lockups due to intermittent jtag_serial_is_connected()==false (IDFGH-17555) espressif/esp-idf#18490, Espressif-confirmed; fix on master/release branches but in no released tag at the time of writing). A Spinel-transport defect.
• ESP ot_rcp — otPlatRadioEnableSrcMatch ignores its aEnable argument (openthread/ot_rcp: otPlatRadioEnableSrcMatch() ignores its aEnable argument — AUTO_PENDING_DISABLE never selectable, inverts Data-Request auto-ACK frame-pending bit (IDFGH-17778) espressif/esp-idf#18699, triaged by Espressif). The frame-pending / source-match path is exactly what Zigbee indirect transmission to a just-associating child relies on; we confirmed on the bench that driving the RCP source-match table is what makes those joins succeed, and Thread exercises this path very differently.
• EFR32 / Silabs ot-efr32 — under Zigbee broadcast traffic with CCA contention we observed the RCP stop responding over Spinel (a multi-second timeout). ZOH has no Spinel-level recovery path today, so a stall like this is terminal for the session; we've been prototyping exactly that recovery rung (Spinel reset → reopen → retry) as the host-side mitigation.
• XON/XOFF software flow control (EFR32 / Silabs default). Two findings, both from controlled tests: (1) we disabled software flow control and the stall above still occurred, so XON/XOFF is not the cause of the wedge; but (2) once the RCP stalls it leaves XOFF asserted and never sends XON, which deadlocks the host→RCP direction — so the host cannot even drive a reset/recovery over the same link. On a binary HDLC/Spinel stream we'd recommend the radio guidance call this out explicitly: prefer hardware flow control (or none) over XON/XOFF, because XON/XOFF turns a recoverable stall into an unrecoverable one over the wire.

The through-line: "any generic OT-RCP with correct STREAM_RAW + hardware MAC-ACK is sufficient" is a reasonable premise, but the RCP firmware that exists today was validated for Thread (and Matter), and the Zigbee-specific corners — the frame-pending/source-match path, behaviour under broadcast/CCA load, HDLC transport and flow control under load — are where it breaks. That's not a criticism of ZOH; it's a caveat about the firmware half of the Spinel contract, worth making explicit in the radio status table. Some of this we've already turned into concrete fixes/reports (#126 here; esp-idf#18490 and #18699 upstream), and we're happy to share traces for any of the above.