Make your own Thread Border Router for just $5

Community Guides
,
61

Hi,

what’s your setup? i was having the same errors with only one device that sleeps most of the time and i solved the problem adding one esp32c6 reporting his uptime every 15s.

My theory is that the rcp goes to deep sleeps and HA cannot wake up Make your own Thread Border Router for just $5 - #60 by qi4k5w

62

Devices that sleep most of the time should not cause any issues. On my network, I have a single device that only wakes up every 10 minutes.

The RCP disconnecting and needing to power cycle error was related to a bug in ESP-IDF which was fixed in the v6.0-beta1 branch, and people had reported it fixed it. So, I don’t know what is causing the issue, and why would adding a device that reports every 15s fixes it.

The only thing that comes to mind is either 1) quirks of the specific USB port on the machine (try different machine) 2) new changes in OTBR image which causes this issue. Maybe try downgrading OTBR addon/container to a version a month or two earlier?

I assume you’re correctly using the port labeled /dev/ttyACM.. or /dev/tty/serial/by-id/..., and not the port labeled /dev/ttyAMA.... And I assume Hardware Flow Control is disabled in your configuration.

Let me know if compiling the binaries yourself work. The instructions are in the guide.

63

using the latest esp-idf 6.0 release, which should be far ahead of beta1 and beta2 in commits. also using the latest latest otbr-br-posix… still experiencing issues. problems persist when using the home assistant otbr add-on aswell.

went ahead and enabled the watchdog in the esp-idf build and flashed today, will report back if this helps.

64

I can’t check right now, but that’s not guaranteed at all, and likely it doesn’t contain the necessary 2 patches. When compiling yourself, please follow the instructions in the guide to git clone from the esp-idf repository instead of using their releases.

65

which commits were you referring to? any of these?

Deadlock fixes:

  • 6334987031 + a4090d1f3b — fix(openthread): resolve deadlock issues due to switching_lock, a deadlock in the
    OpenThread library that would cause the RCP to stop responding entirely

802.15.4 radio fixes:

  • 0d8d079c79 — fix(802.15.4): fixed energy detection result
  • 77792ad373 — fix(802.15.4): fixed security frame configuration
  • 46c14be3d3 — fix(802.15.4): locate the ieee802154_sec_clear on the noflash — prevents crash during security
    operations + flash access

USB Serial/JTAG fixes:

  • 93d9104e29 — fix(esp_driver_usb_serial_jtag): check USJ accessibility before read/write, prevents crashes when
    USB drops
  • 512444f47c — fix(usb_serial_jtag): tx_ring_buf not checked for successful allocation

All of these are included in GitHub - espressif/esp-idf at release/v6.0 · GitHub

Using the beta1 branch in the OP also experiences the same issues.

66

The patch that fixed the dropping issue was this one: Openthread RCP using USB to control it · openthread · Discussion #11627 · GitHub
And the other one is the one that enabled USB support for RCP: feat(openthread): support rcp based on USB Serial JTAG · espressif/esp-idf@51bcec7 · GitHub

I don’t know why you are experiencing issues, since so many others say it works.

67

Since I cannot edit my post, I’m replying to myself.

I compiled it myself and tried using it (without my uptime “workaround”), and it dropped the connection at around ~12 hours (twice). Then I tried it with the uptime sensor, and it worked for ~40 hours without dropouts.

Finally, I thought: what if I only disconnect the uptime sensor? After that, it stayed connected for about 3 days, until I started experiencing small disconnections.

However, the error is different now. Before, it said something about OTBR being unable to communicate with the RCP via Spinel. Now, I’m seeing a lot of:

Dropping IPv6 UDP msg

and

Failed to send IPv6 UDP msg

I’ll probably try adding the uptime sensor again, just for fun.

edit: I think these latest errors might be caused by the sensor rather than the RCP.

68

I’m really new to Thread (literally my first time using it), and I just wanted to learn and test.

As far as I understand, the sensor (it’s a door sensor) only reports its state when it changes, and for some reason it also reports its state every night at 2:22 AM.

  1. I tried two different ports on one machine (virtual), and I also thought it might be something related to HAOS being virtualized, so I tested another machine with bare-metal HAOS.
  2. I didn’t try that because I’ve never had a working setup before, but I think it’s a good idea. The only problem is I don’t know how to do it yet, but I’ll give it a try.

The port is labeled as /dev/tty/serial/by-id/..., and hardware flow control is disabled.

It’s probably something weird with my setup :slightly_smiling_face:

69

@parhelion I have things working with your pre-compiled c6 bin file. However I would love to see the sdkconfig file for it so I can reproduce it later with my own compiles. Everything I have tried using the build instructions has failed to build a working RCP :frowning:

70

I use a C6 and it is connected to my HA but I can’t select any network.

2026-03-29
2026-03-29581×574 15.9 KB

71

It is solved. After restart of HA my preferred network was set.

72

Have sameone make it with only C6 wifi connection no usb wifi.
Cant make usb pass VM. I was trying with IDF and have problems end errors. Can sameone make flash with my wifi password and SSID

73

I’ve been seeing the same issue(but with an ESP32-H2 for testing) and I only have (again for testing) a single ESP32-H2 with esphome that just repeats the internal temperature sensors reading at semi random intervals(it only reports new temps I think?). Did you find any fixes that are better than the regularly updating sensor?