OTBR Add-on doesn't work without (dummy) USB Device / Documentation mentions non-existing one (for HAOS)

[joergbattermann]

Describe the issue you are experiencing

I wanted to use a networked SLZB-06M as OTBR together with my RPI4 installed HA instance / the OTBR add-on but I can't as I have no dummy USB device and the OTBR, for whatever reason, requires one to function.

I am not sure what sort of issue this correctly would be - a feature request that the OTBR shouldn't enforce and require a physical /dev/tty* USB device connected when using a network(ed) device and/or the documentation should reference a non-existing /dev/ttyS3 one.

HAOS 15.2 has no such device, see

and no matter what else I pick from /dev/tty* I get a different error that it can't be used. So - how DO I use a network_device? I tried to connect a normal USB stick as dummy device but that's not good enough... soooo what to do?

OS Version: Home Assistant OS 15.2 Home Assistant Core: 2025.4.3

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.13.0

Steps to reproduce the issue

1. Setup a network OTBR
2. Try to use it w/ the OTBR HA add-on on a HAOS 15.2 / RPI4 installation without having any USB device (?) connected

3. You can't, the config validation logic says the /dev/ttyS3 as per config doesn't exist ...

System Health information

System Information

version	core-2025.4.3
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.2
os_name	Linux
os_version	6.6.74-haos-raspi
arch	aarch64
timezone	America/Los_Angeles
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	1663
Downloaded Repositories	5

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 15.2
update_channel	stable
supervisor_version	supervisor-2025.04.0
agent_version	1.7.2
docker_version	28.0.4
disk_total	57.8 GB
disk_used	35.5 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_addons	Advanced SSH & Web Terminal (20.0.2), Mosquitto broker (6.5.0), Matter Server (7.0.0), Samba share (12.5.0), File editor (5.8.0), ESPHome Device Builder (2025.4.0), SQLite Web (4.3.1), Studio Code Server (5.19.1), Let's Encrypt (5.4.4), Stream mqtt from Enphase Envoy (1.0.18), OpenThread Border Router (2.13.0)

Dashboards

dashboards	2
resources	0
views	2
mode	storage

Network Configuration

adapters	lo (disabled), end0 (enabled, default, auto), hassio (disabled), docker0 (disabled), veth3b6beca (disabled), veth41b9646 (disabled), veth4b862ac (disabled), vethdfb4f56 (disabled), veth4e3269a (disabled), veth3b0000f (disabled), vetha055e45 (disabled), veth662aa46 (disabled), wpan0 (disabled)
ipv4_addresses	lo (127.0.0.1/8), end0 (192.168.0.35/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), veth3b6beca (), veth41b9646 (), veth4b862ac (), vethdfb4f56 (), veth4e3269a (), veth3b0000f (), vetha055e45 (), veth662aa46 (), wpan0 ()
ipv6_addresses	lo (::1/128), end0 (REMOVED_PUBLIC_IPV6_ADDRESS/64, fe80::2fad:df7f:6e0a:f1d9/64), hassio (fe80::fce8:b9ff:fe36:61bd/64), docker0 (fe80::405d:84ff:fe81:9d3d/64), veth3b6beca (fe80::9044:24ff:fecc:fcf8/64), veth41b9646 (fe80::7091:7ff:fe79:1376/64), veth4b862ac (fe80::7c55:2fff:fe62:abd4/64), vethdfb4f56 (fe80::40e4:84ff:fed2:55fc/64), veth4e3269a (fe80::7c17:e6ff:fe13:c2a/64), veth3b0000f (fe80::f0c8:9fff:fe5d:3da9/64), vetha055e45 (fe80::4819:5bff:fee3:e0a3/64), veth662aa46 (fe80::840f:2ff:fe83:81bd/64), wpan0 (fd2d:7f0c:a011:cd15:6261:de9d:9628:a552/64, fe80::d0cc:e9b:cd88:7b56/64)
announce_addresses	192.168.0.35, REMOVED_PUBLIC_IPV6_ADDRESS, fe80::2fad:df7f:6e0a:f1d9

Recorder

oldest_recorder_run	April 8, 2025 at 05:00
current_recorder_run	April 20, 2025 at 16:56
estimated_db_size	2337.95 MiB
database_engine	sqlite
database_version	3.48.0

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

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

Additional information

No response

[evakq8r]

I also have the same issue (using an RPI4B). The "workaround" (which doesn't apply to most) is to use a Skyconnect as the USB device and enter in the network credentials for the SLZB-06MG24 I have (as it's the only USB device I have that is identified in the OTBR config page). That however defeats the purpose as I then potentially have two radios (not sure it works that way), but I too am unable to select a ttyS3 in the device listing as it does not exist.

[joergbattermann]

Yeah I am using an old Conbee USB Stick that I still had in the drawer for now.. which obviously feels.. ahem.. unnecessary/unneeded for something entirely unrelated & it just being a dummy feels... dumb.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rosicenko]

Same issue here. Makes absolutely no sense especially with the rise of PoE working coordinators as SMLIGHT.

[maxlahn]

I'm experiencing the same issue trying to connect the SMLight SLZB-MR1 to my HAOS installed on a Raspberry Pi 4B, and I'll add that depending on what devices exist inside the OTBR container, this issue might be able to be solved by allowing users to enter a non TTY dummy device like /dev/null or /dev/zero. As it currently stands, the configuration gives the following error message:

[joergbattermann]

@maxlahn You might want/need to disable 'autoflash_firmware' for the SMLight.. but that's not solving the issue. I have (since opening this issue) moved on to running HA in a proxmox environment and no longer need my old Conbee stick as mentioned above.

I can gladly send it your ways in a small padded envelope if you want it / want to workaround this issue.. just lmk!

[rosicenko]

Cheap option is also to use ESP connected with USB. You can leave it empty or use it as WLED controller, bluetooth proxy, sensor, ...

[MiguelAngelLV]

Same problem.

With the OpenThread on EspHome released, more people will use Thread, so, this need be fixed.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ewster]

Same problem here with SLZB-MR3 on HAOS. Trying to load OTBR 2.13.0, there are no devices to select and no way to complete configuration.

Home Assistant OS Core 2025.8.0 Supervisor 2025.07.3 Operating System 16.0 Frontend 20250806.0

[zekone-boar]

Same issue here with the SLZB-MR2 on HAOS.

[ThatBoyPamp]

Hey everyone, I hope you have found a solution by now but if you haven't I just wanted to let you guys know I found something that worked for me.

I had to take the sd card out of my Pi and change a couple of things in the config.txt file. There are two lines that need to be uncommented.

enable_uart=1 #dtoverlay=rpi-rf-mod

Once I did that I had to update my firmware on my SLZB MR4 because I was behind a couple versions but then I had my serial device showing up, where I previously did not, and I was able to connect and start setting up devices!

Hope this helps someone!