Using the /service WebSocket endpoint for a custom Android remote?

Hi Andreas,

I've been building a web-based remote control for BTT that runs on an Android phone — basically a custom alternative to BTT Mobile. It's a single HTML page served from BTTWebServer that talks to the HTTP API.

The good news: it works. Buttons via /trigger_named/ are snappy, and cursor movement via /trigger_action/ with action type 153 (anchor 6, duration 0) functions correctly. I've got a trackpad surface, tap-to-click, and even S Pen hover support using Pointer Events.

The bottleneck: each cursor move is a full HTTP GET request/response cycle. Over WiFi that's 15-50ms per move, which makes the trackpad usable but noticeably stuttery compared to a real pointing device. Buttons are fine — it's the continuous high-frequency input that suffers.

I noticed the webserver docs mention a WebSocket endpoint at /service. I have a few questions about it:

1. Is the WebSocket available for third-party use?
Is /service intended as a public API, or is it internal to BTT Mobile? I don't want to build on something that might change without notice.

2. Is there any documentation or message format reference?
Even a rough sketch of the protocol would save me from reverse-engineering it. What messages can be sent/received? Is it JSON-based?

3. Can mouse movement be sent over it?
The main thing I'd want is to stream relative mouse deltas over a persistent connection instead of one HTTP request per move. Does the WebSocket support triggering actions like the HTTP API does?

4. Does it push state changes?
For example, an "active application changed" event. This would let me build app-aware button switching on the Android side without polling.

Thanks Andreas!

unfortunately the websocket endpoint is currently unused, it ist just a test endpoint that returns the current date when pinged. I once had planes to make the BTT functions available via the websocket, but so far this is not implemented.

Ah, bummer! I might have a go at building a Websocket bridge with Hammerspoon, then the round-trip HTTP handshake between HS and BTT webserver should be smoother, being both on-machine.

But I’ll remember that next time I need to check what day it is! :upside_down_face: