OpenThread Border Router: Allow network_device without USB device

[jmarcelomb]

I'm trying to use an SLZB-MR4 (network-connected RCP) on my Raspberry Pi 4B. The add-on requires device to be set even though I'm using network_device — there's no USB serial device to provide, and setting a dummy value feels wrong.

This makes device optional in the schema and adds a check that fails clearly if neither device nor network_device is configured.

Summary by CodeRabbit

• New Features

  • Device configuration is now optional, allowing setups without an explicit device entry.

• Bug Fixes

  • Startup now validates configuration and exits early with a clear error when neither device nor network device is provided.
  • When a network device is selected, the runtime automatically uses an appropriate virtual device for operation.

[home-assistant]

Hi @jmarcelomb

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Stale

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6159500a-74f2-4f12-bd87-ad6768c7fa6f

📥 Commits

Reviewing files that changed from the base of the PR and between 8a9e83e and 965016d.

📒 Files selected for processing (2)

• openthread_border_router/config.yaml
• openthread_border_router/rootfs/etc/s6-overlay/s6-rc.d/otbr-agent/run

---

📝 Walkthrough

Walkthrough

Schema now allows omitting device; startup script enforces that at least one of device or network_device is configured and sets device to /tmp/ttyOTBR when network_device is used.

Changes

Optional Device Configuration with Fallback

Layer / File(s)	Summary
Device configuration schema and runtime validation openthread_border_router/config.yaml, openthread_border_router/rootfs/etc/s6-overlay/s6-rc.d/otbr-agent/run	options.device schema changed from device(subsystem=tty) to device(subsystem=tty)? (optional). Startup script adds an early check that exits if neither device nor network_device is configured; when network_device is present the script sets device to /tmp/ttyOTBR, otherwise it reads device from the config.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: making the device option optional to allow network_device configuration without a USB device.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@openthread_border_router/rootfs/etc/s6-overlay/s6-rc.d/otbr-agent/run`:
- Around line 51-53: The current check uses if [ -z "${device}" ] which can be
bypassed because bashio::config returns the literal "null"; replace this logic
by using bashio::config.has_value for both keys (device and network_device) and
fail only when neither has_value returns true; update the run script's
validation block to call bashio::config.has_value "device" and
bashio::config.has_value "network_device" and invoke bashio::exit.nok with the
same message when both are absent to ensure proper detection of unset configs.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 08380915-989d-438b-95ae-13f03a6da18f

📥 Commits

Reviewing files that changed from the base of the PR and between 1c1a052 and acf4dc9.

📒 Files selected for processing (2)

• openthread_border_router/config.yaml
• openthread_border_router/rootfs/etc/s6-overlay/s6-rc.d/otbr-agent/run

[SveLil]

@agners Can you take a look and approve? There are quite a lot of people waiting for this (see #4299)

[agners]

@agners Can you take a look and approve? There are quite a lot of people waiting for this (see #4299)

I don't really like it. It means that users who use a USB device get a strange error if they forget to select it. And these users should be our primary concern.

Tunneling Thread radio messages through network is generally a bad idea, it is a timing sensitive protocol and the higher level protocol itself is a network protocol, so why not just install a BR firmware on the device if its network capable!? 🤷

What I actually would prefer is have a separate app, which we'd then also could clearly mark as experimental. It would also have the advantage that you can run a proper locally connected radio still.

[el-gee]

why not just install a BR firmware on the device if its network capable!?

devices are starting to offer this, but it's often beta support at best. Users may have an acceptable network and be willing to accept the risks of tunneling thread radio message between the radio and the OTBR server (a common use case being HA physically running in a suboptimal location for radio placement -- aka a corner in the basement) .

It feels like there are 2 things worth keeping distinct in discussion: The oddity of the UI behavior here and the general complications and nuances of the configuration it currently blocks: network only radio devices.

[fueltank34]

Blocking useful network functionality because a USB user might misconfigure their settings feels like the wrong trade-off. Instead of restricting choices for users who intentionally deploy network-attached coordinators, shouldn't we just improve the UI validation or error messaging to guide the USB users better?

Network-attached RCPs (like the SLZB-06 or TubeZB coordinators) are incredibly common for centralising radios away from server racks.

Giving users the choice of how they connect their hardware, while keeping the configuration unified in one place, is a massive UX win.

[SveLil]

I agree that using a network_device instead of a USB device isn't ideal, but as OTBR suppots this, this app should support the configuration.

[zeratul021]

@jmarcelomb @agners any chance we could support this in some mode, possibly with some checkbox/tunable?
It is bit frustrating having to select fake USB devices for something that is already supported to work.