Show HN: Bluetooth USB Peripheral Relay – Bridge Bluetooth Devices to USB

Original Article ↗ Hacker News Discussion ↗

Project purpose and behavior

  • Device bridges Bluetooth HID peripherals (keyboards, mice, etc.) to appear as standard USB HID to a host.
  • Main motivation: use Bluetooth-only devices where Bluetooth is disabled or unavailable (corporate laptops, pre-boot/BIOS, GRUB/UEFI, KVMs, consoles).

Use cases and benefits

  • Use favorite Bluetooth keyboard/mouse on locked-down work machines that ban Bluetooth but allow USB HID.
  • Make Bluetooth keyboards/mice usable in firmware setups, bootloaders, and with USB KVM/switches.
  • Provide a stable Bluetooth “anchor” on a desk: plug one USB cable into any laptop and instantly use the same wireless peripherals, avoiding repeated pairing/unpairing.
  • Potential workaround for OS-specific Bluetooth bugs (e.g., problematic keyboards on macOS but fine under Linux).
  • Helps integrate Bluetooth-only Apple peripherals (Magic Trackpad/Keyboard/Mouse) into multi-computer setups, especially where USB-only KVMs are used.

Relation to older and existing solutions

  • Similar in spirit to now-rare dual-mode HID/HCI Bluetooth adapters that could act as USB HID in pre-boot, then switch to HCI for the OS.
  • Others note existing solutions for wireless serial (RS-232) via Bluetooth/Wi-Fi modules, ESP32/ESP8266, and commercial gateways.
  • Some argue simpler alternatives for multi-host setups: wired or dongle-based wireless keyboards/mice via monitor USB hubs, USB switches, or KVMs with dynamic device mapping.

Implementation choices (Pi vs microcontrollers)

  • Some view using a Raspberry Pi + Linux as overkill and fragile; suggest microcontrollers with Zephyr (nRF52840), ESP32, or Raspberry Pi Pico W.
  • Counterpoint: using a Pi reduced development friction for a personal project and is cheap enough; a microcontroller port is seen as a possible future challenge.
  • Any SBC with USB OTG should work; confirmed for Pi Zero W / Zero 2 W; Pi 4 OTG capability is noted as unclear.

Enterprise policy, security, and shadow IT

  • Debate over whether this would be acceptable in strict IT environments where even unapproved USB devices are banned.
  • Some stress that Bluetooth input has had real-world crypto issues (keystroke sniffing/injection), making bans defensible.
  • Others argue similar risks exist with proprietary 2.4 GHz dongles, and that good official equipment reduces the incentive for “shadow IT.”
  • Warnings that bypassing policy can be career-risky, even if technically feasible.

Extensions, variants, and limitations

  • Frequently requested: audio support (headphones, game headsets, AirPods to consoles/PCs); acknowledged as a much more complex stack and not yet supported.
  • Interest in BT→Internet→BT relays; existing BLE proxies (e.g., for Home Assistant) are noted but not general-purpose.
  • Ideas raised for the reverse direction (USB devices exposed as BLE HID) and for using phones/tablets as Bluetooth keyboards/mice, with some existing Android apps referenced.
  • Latency concerns highlighted for gaming audio over Bluetooth, even if bridging becomes possible.