Issue with SkyConnect Thread Controller on Home Assistant – OTBR Agent Communication Errors

[horvathgergo]

Describe the issue you are experiencing

I’m experiencing communication issues between Home Assistant and the SkyConnect Thread controller (OpenThread Border Router - OTBR). The OTBR agent fails to communicate consistently with the Radio Co-Processor (RCP), logging ChannelAccessFailure and radio tx timeout errors.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

OpenThread Border Router

What is the version of the add-on?

2.11.1

Steps to reproduce the issue

Update Supervisor to the latest version 10.3

System Health information

Version core-2024.10.3
Installation type Home Assistant OS
Development false
Supervisor true
Docker true
User root
Virtual environment false
Python version 3.12.4
Operating system family Linux
Operating system version 6.6.31-haos-raspi
CPU architecture aarch64
Timezone Europe/Budapest
Host operating system Home Assistant OS 13.2
Update channel stable
Supervisor version supervisor-2024.10.3
Agent version 1.6.0
Docker version 27.2.0
Disk total 439.4 GB
Disk used 28.9 GB
Healthy true
Supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization
Board rpi4-64
Supervisor API ok
Version API ok
Installed add-ons File editor (5.8.0), Terminal & SSH (9.15.0), Mosquitto broker (6.4.1), ArgonOne Active Cooling (30a), Home Assistant Google Drive Backup (0.112.1), Zigbee2MQTT (1.40.2-1), Tailscale (0.23.1), Z-Wave JS UI (3.16.0), ESPHome (2024.10.0), Piper (1.5.2), Whisper (2.2.0), Samba share (12.3.2), openWakeWord (1.10.0), Assist Microphone (2.2.3), Matter Server (6.6.0), Z-Wave JS (0.8.1), OpenThread Border Router (2.11.1)

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

No response

Anything in the add-on logs that might be useful for us?

The OTBR agent attempts to connect to the SkyConnect device but fails with ChannelAccessFailure errors. Below is the relevant portion of the log, which repeats similar errors:

Logs

s6-rc: info: service universal-silabs-flasher: starting
[19:27:37] INFO: Checking /dev/ttyUSB0 identifying SkyConnect v1.0 from Nabu Casa.
[19:27:37] INFO: Starting universal-silabs-flasher with /dev/ttyUSB0
2024-10-25 19:27:39.915 HomeAssistant universal_silabs_flasher.flash INFO Extracted GBL metadata: NabuCasaMetadata(metadata_version=1, sdk_version='4.4.3', ezsp_version=None, ot_rcp_version='SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0), cpc_version=None, fw_type=<FirmwareImageType.OT_RCP: 'ot-rcp'>, baudrate=460800)
2024-10-25 19:27:39.916 HomeAssistant universal_silabs_flasher.flasher INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud
2024-10-25 19:27:41.933 HomeAssistant universal_silabs_flasher.flasher INFO Probing ApplicationType.SPINEL at 460800 baud
2024-10-25 19:27:41.964 HomeAssistant universal_silabs_flasher.flasher INFO Detected ApplicationType.SPINEL, version 'SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4' (2.4.0.0) at 460800 baudrate (bootloader baudrate None)
...
00:00:15.536 [C] P-RadioSpinel-: Failed to communicate with RCP - no response from RCP during initialization
00:00:15.536 [C] P-RadioSpinel-: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
00:00:15.536 [C] P-RadioSpinel-: - Make sure RCP is running the correct firmware
00:00:15.536 [C] P-RadioSpinel-: - Double check the config parameters passed as `RadioURL` input

Additional information

Home Assistant Version: (Core, Supervisor, OS 2024.10.3) - RPI4
Hardware: SkyConnect v1.0 (Nabu Casa)
Firmware Version: SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4 (2.4.0.0)
Thread Version: 1.3.0
OTBR Agent Version: 0.3.0-ff7227ea-dirty
Radio URL Parameters: spinel+hdlc+uart:///dev/ttyUSB0?uart-baudrate=460800&uart-flow-control

[horvathgergo]

The issue was caused by changes in serial port assignments. When I first connected the controller, it was assigned to ttyUSB2. However, after a reboot, it was reassigned to ttyUSB0. Since OTBR doesn’t allow manual reassignment of the port, I had to unplug and replug the peripherals until the controller was assigned to ttyUSB2 again.