Bluetooth chess clocks and browser limits

Compatible hardware

A browser may connect to a Bluetooth Low Energy clock that exposes documented GATT services. There is no universal web chess-clock service, so support must be built for each published protocol. The Bluetooth clock on this site ships drivers for the DGT3000 BLE Gateway and for Pegasus, Chessnut, Millennium and Lichess-protocol boards, plus a generic mode for DIY buttons; it does not claim universal hardware control.

Source for the factual guidance above: Web Bluetooth specification.

Phone-to-phone play

For two nearby phones, use an invite room over the internet or pass-and-play on one screen. That produces the Game Boy-like handoff experience without pretending Web Bluetooth can create a peer link it does not expose.

Privacy and support

Device discovery requires a secure context, explicit user action and a compatible browser. No nearby-device list is sent to our server. Unsupported browsers receive a clear explanation and retain the local clock.

A connection-readiness checklist

Use a compatible browser in a secure context, enable Bluetooth at the operating-system level, and keep the peripheral nearby and awake. Start discovery from a deliberate button press because browsers do not allow silent scanning. Choose only the intended device and expect the permission to cover specific services. A successful chooser or transport connection does not prove that clock data can be read. The webpage still needs the correct GATT service and characteristic identifiers plus the model's command format.

Source for the factual guidance above: Web Bluetooth specification.

What a real clock integration requires

A developer needs a documented protocol or careful permission to test the hardware. The integration must identify services, subscribe to button or state notifications, decode time and side data, and send only commands the device accepts. It also needs recovery behavior for disconnects, sleep, low battery, and a clock that changes state while the page is unavailable. Model names alone are insufficient because firmware revisions can differ. Support should therefore be advertised per tested model and protocol version, not as universal Bluetooth compatibility.

Choose the right connection model

Use Web Bluetooth when one browser is controlling or reading a supported nearby peripheral. Use an online invite room when two phones need synchronized player views. Use one shared screen for the simplest pass-and-play setup. These are different architectures, not interchangeable transport options. If privacy or network availability matters, explain what stays local and what requires a server before the game begins. Choosing the correct model prevents a connected-device indicator from promising synchronization or control that the underlying browser role cannot provide.