Bridge binary reference

The bridge is a small standalone binary that runs on your local network and relays a fixed set of requests to the backend when the backend can't reach your network directly — see Devices & the local network bridge for what it's for and why it only exposes five specific operations rather than acting as a general HTTP proxy.

Registering a device token

Generate a one-time registration code from the Devices page in the web UI, then exchange it for a permanent device token:

bridge -register -server https://myinstance.example.com -code ABCD-1234 -name "Home bridge"

This prints the issued token — save it somewhere safe; it isn't shown again and can't be recovered from the server, only revoked and reissued.

Running it

bridge -server https://myinstance.example.com -token fmdt_...

Both flags can be set via environment variables instead, which is generally more convenient for a systemd unit or container:

export FM_SERVER_URL=https://myinstance.example.com
export FM_DEVICE_TOKEN=fmdt_...
bridge

The bridge keeps a permanent WebSocket connection open to the backend, reconnecting automatically with exponential backoff if the connection drops, and answers requests concurrently over that one connection.

Protocol versioning

The bridge reports its protocol version to the backend on every connection. If the backend expects a newer version than the connected bridge speaks, the web UI's Devices page shows a warning — redeploy the bridge binary to pick up whatever changed. The protocol is intentionally a small, closed set of named operations (not a generic proxy), so a version bump only ever adds or changes one of those fixed operations, never widens what the bridge is willing to do on the backend's say-so.

Container image

A Dockerfile.bridge build is also published — see Docker & Helm — for running the bridge as a container instead of a bare binary, e.g. on a small always-on machine on your network.