Skip to main content
Use the box’s own Bluetooth adapter to find your DUT advertising, connect to it, and enumerate its GATT services.

Handle

BLE is a box-level capability, not a net: it drives the box’s own adapter. There is no net name and no name().

Methods

Types

Method Reference

scan(timeout: f64) -> Result<Vec<BleDevice>>

Scan for advertising devices for timeout seconds, which must be between 0.1 and 300. Named devices sort first.

scan_named(timeout: f64, name_contains: &str) -> Result<Vec<BleDevice>>

The same scan, filtered by a case-insensitive name substring.

info(address: &str) -> Result<BleDeviceInfo>

Connect briefly and enumerate the device’s GATT services.

connect(address: &str) -> Result<BleDeviceInfo> and disconnect(address: &str) -> Result<()>

Connect to, or ensure disconnection from, a device by address.

Examples

Assert the DUT advertises with the right service

Notes

  • One adapter per box. The box serializes all BLE and BluFi work on it, so concurrent calls queue rather than fail. A BluFi provisioning run and a BLE scan cannot overlap.
  • capabilities.ble_command being true means the box serves the route, not that it can do the work. A box whose host has no BlueZ running answers with Error::Box and HTTP 502 carrying BlueZ is not running on the box host (an older box image sends The name org.bluez was not provided by any .service files). This happens even with a Bluetooth controller present on the USB bus. Check the error, not just the capability flag. lager update installs BlueZ on the host.
  • The box-side connect timeout for info, connect and disconnect is 10 seconds; the client allows that plus 30.
  • rssi is a snapshot from the advertisement that happened to be received. Treat it as an ordering hint, not a measurement.