OpenThread Border Router fails to start with SONOFF Dongle Plus MG24 / ZBDongle-E unless hardware flow control is disabled

[boysie123]

Describe the issue you are experiencing

The OpenThread Border Router add-on fails to start when using a SONOFF Dongle Plus MG24 (Dongle-PMG24, same EFR32MG24 hardware family as the ZBDongle-E) flashed with SONOFF's own "OpenThread RCP" firmware. The add-on's universal_silabs_flasher client never receives a response to the initial Spinel RESET or the subsequent PROP_VALUE_GET, times out after 3 retries, and otbr-agent exits with code 1 (add-on ends in error state).

The root cause turned out to be the add-on's flow_control option defaulting to true (hardware RTS/CTS flow control). This dongle's OpenThread RCP firmware does not implement/expect hardware flow control the way Nabu Casa's own SkyConnect/Connect ZBT-1/Yellow radios do. Setting flow_control: false (baudrate left at 460800) immediately resolved it — the very next handshake succeeded, otbr-agent started, and Home Assistant's thread/otbr config entries were created automatically via discovery.

This isn't documented anywhere in DOCS.md, and there's no diagnostic hint in the failure output pointing a user toward flow control — the only symptom is a silent timeout plus a Python traceback, which took extensive log analysis (and cross-referencing a Home Assistant Community forum thread) to resolve.

Before landing on flow_control, I ruled out:

• Firmware/category — SONOFF's own web flasher confirmed the device was running genuine "OpenThread 2.4.4" RCP firmware (not MultiPAN RCP or Zigbee); reflashed fresh mid-troubleshooting with identical results.
• Baud rate — tried both 460800 (matches the flashed rate) and 115200, both with default flow_control: true, both failed identically.
• USB/power/cable — host kernel log shows clean enumeration (cp210x, VID:PID 10c4:ea60, the same Silicon Labs USB-UART bridge family used on Nabu Casa-compatible boards), no descriptor read errors, no disconnect/reconnect loops.

Only toggling flow_control to false changed the outcome.

Environment

• Installation type: Home Assistant OS
• Operating system: Home Assistant Operating System 18.2 (aarch64, Home Assistant Yellow)
• App: OpenThread Border Router
• App version: 3.1.0
• Home Assistant Core: 2026.8.1
• Supervisor: 2026.07.5
• Radio: SONOFF Dongle Plus MG24 (Dongle-PMG24), OpenThread RCP firmware v2.4.4, flashed via SONOFF's official web flasher (dongle.sonoff.tech)

Steps to reproduce the issue

1. Flash a SONOFF Dongle Plus MG24 with the "OpenThread RCP" firmware option via SONOFF's official web flasher.
2. Plug it into a Home Assistant Yellow (or any HAOS host).
3. Install/configure the OpenThread Border Router add-on, pointing device at the dongle's /dev/serial/by-id/... path, default options (baudrate: 460800, flow_control: true).
4. Start the add-on.
5. Observe: add-on ends in error state; log shows Device did not respond to reset, continuing, followed by repeated Failed to send SpinelFrame ... trying again, then TimeoutError / otbr-agent exited with code 1.
6. Set flow_control: false (baudrate unchanged) and restart the add-on.
7. Observe: RESET and PROP_VALUE_GET both get immediate responses, otbr-agent starts successfully, and a Thread network forms.

Anything in the app logs that might be useful for us?

flow_control: true (failing):

Opening a serial connection to '/dev/serial/by-id/usb-SONOFF_SONOFF_Dongle_Plus_MG24_...' (baudrate=460800, xonxoff=False, rtscts=True)
...
Sending frame SpinelFrame(... command_id=<CommandID.RESET: 1> ...)
Device did not respond to reset, continuing
Sending frame SpinelFrame(... command_id=<CommandID.PROP_VALUE_GET: 2> ...)
Failed to send SpinelFrame(...), trying again in 0.10s (attempt 1 of 3)
Failed to send SpinelFrame(...), trying again in 0.10s (attempt 2 of 3)
Failed to send SpinelFrame(...), trying again in 0.10s (attempt 3 of 3)
TimeoutError
[WARNING] otbr-agent exited with code 1 (by signal 0).

flow_control: false (working):

Opening a serial connection to '/dev/serial/by-id/usb-SONOFF_SONOFF_Dongle_Plus_MG24_...' (baudrate=460800, xonxoff=False, rtscts=False)
...
Sending frame SpinelFrame(... command_id=<CommandID.RESET: 1> ...)
Received b'~\x80\x06\x00p\xeet~'
Decoded HDLC frame: HDLCLiteFrame(data=b'\x80\x06\x00p')
Parsed frame SpinelFrame(... command_id=<CommandID.PROP_VALUE_IS: 6> ...)
Sending frame SpinelFrame(... command_id=<CommandID.PROP_VALUE_GET: 2> ...)
Received b'~\x83\x06\x084\x8d}3\xff\xfe}1s"k\xc2~'
...
[NOTE]-AGENT---: Running 0.3.0-ec16e396
[NOTE]-AGENT---: Thread version: 1.4.0
INFO: Successfully sent discovery information to Home Assistant.
[N] BorderRouting-: Local on-link prefix: fdde:f9b3:a0cc:276d::/64
[N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset

Additional information

Suggested improvements:

1. Document in DOCS.md that the SONOFF Dongle Plus MG24 / ZBDongle-E — a very commonly recommended third-party Thread RCP dongle — requires flow_control: false. The current guidance ("If hardware flow control should be enabled (depends on firmware)") gives no way for a user to know which value their specific firmware needs.
2. Consider surfacing a clearer error/hint when the RCP never responds to RESET/PROP_VALUE_GET at all (e.g. suggesting the user try toggling flow control), rather than a bare TimeoutError and Python traceback — this is currently very hard for a non-expert user to self-diagnose without deep log analysis.

I searched the repo and didn't find an existing open issue covering this specific combination.

[boysie123]

Related issues, for anyone landing here from a search:

• TimeOut Error with the OpenThread Border Router Addon and ZBT-1 #4277 — same exact hardware/firmware combination (Sonoff Dongle Plus MG24, OT-RCP FW 2.4.4) hitting the same TimeoutError on earlier add-on versions (2.15.3/2.16.3). Worth reading in combination with this report: the fixes people found there are inconsistent (some needed flow control on, some off, some said neither helped), which lines up with my suggestion below that the correct flow_control value isn't discoverable without trial and error — documenting it for this dongle family would have saved that whole thread a lot of guessing.
• migrate_otbr_settings.py TimeoutError on fresh install with Sonoff Dongle Lite MG21 prevents otbr-agent from starting #4475 — same migrate_otbr_settings.py TimeoutError signature, different Sonoff dongle (Lite MG21), but a different root cause: SONOFF's flasher silently wrote CPC/MultiPAN firmware despite the UI showing "OpenThread RCP" selected. I'm linking it because it shows this exact error message can come from at least two unrelated causes (bad firmware category vs. flow control mismatch) — supporting the case for a clearer failure message that gives users something to differentiate on, rather than a bare TimeoutError/traceback either way.