oss.sarwagya.wtf

beta@0xsarwagya/agnostic-web-ble

Bluetooth Low Energy for the web, whatever your browser might be.

I refuse to write device logic for browsers.

A web application should describe how it wants to communicate with a BLE device. It should not need to know which browser it is running in, whether native Web Bluetooth exists, or how this runtime happens to represent devices, characteristics, and disconnects. Your application should know the device. The adapter should know the runtime.

Install
pnpm add @0xsarwagya/agnostic-web-ble# or: npm install @0xsarwagya/agnostic-web-ble

One interface

import { createBluetooth } from "@0xsarwagya/agnostic-web-ble";
import { nativeWebBluetoothAdapter } from "@0xsarwagya/agnostic-web-ble/adapters/native";
 
const bluetooth = createBluetooth({
  adapters: [nativeWebBluetoothAdapter()],
});
 
const device = await bluetooth.requestDevice({
  filters: [{ services: ["180f"] }],
});
 
const connection = await device.connect();
const service = await connection.getPrimaryService("180f");
const characteristic = await service.getCharacteristic("2a19");
 
const value = await characteristic.readValue();

The model

Adapters own runtime weirdness. The application receives one API, one binary type, one error taxonomy, and honest capability information — never browser detection.

Compatibility

Compatibility is reported from what is actually exercised, not from marketing.

RuntimeAdapterRequestConnectReadWriteNotify
Any JS runtimemockTested in CITested in CITested in CITested in CITested in CI
Chromium-based browsersnative-web-bluetoothImplementedImplementedImplementedImplementedImplemented
Manual hardware verification pending; treat as beta.

Errors are part of the product

if (isBluetoothError(error) && error.code === "PERMISSION_DENIED") {
  // explain what the user can do — no string parsing
}