What Is FTMS? The Bluetooth Fitness Machine Service (2026)

FTMS is the answer to "why does every treadmill ship its own app". It is the Bluetooth SIG's Fitness Machine Service, and the SIG's public assigned-numbers registry lists it as 0x1826. Where a proprietary interface means one integration per manufacturer, FTMS means one integration per machine type — and often one integration full stop, because the shape of the work is identical across all six.

This page is the anchor explainer for the cluster. The per-machine pages go deeper: treadmill app integration, indoor bike trainer integration and rowing machine data.

One service, six machine data characteristics#

A machine advertises 0x1826 and exposes the data characteristic matching what it is. From the SIG registry:

There is also a Training Status characteristic, 0x2AD3, for the machine's own view of the training state.

The architectural consequence is worth stating plainly, because it shapes your code: your transport layer, discovery logic, subscription handling, reconnection policy and session assembly are shared across every machine type, and only the parsing and the domain model differ per characteristic. Teams that structure the integration the other way round — a treadmill module, then a bike module cloned from it — end up maintaining six copies of the same reconnect bug.

Capability discovery comes before anything you render#

FTMS gives you two mechanisms for asking a machine what it can do, and using them is not optional if you want a UI that is honest on hardware you have never seen.

Fitness Machine Feature, 0x2ACC, is the feature declaration for the machine. The Supported Range characteristics describe the bounds of the things it can report or accept: Supported Speed Range 0x2AD4, Supported Inclination Range 0x2AD5, Supported Resistance Level Range 0x2AD6, Supported Heart Rate Range 0x2AD7 and Supported Power Range 0x2AD8.

Our recommendation, as judgement rather than a spec requirement: read the feature and range characteristics at connection time, cache them per device, and drive your UI from them. Never render a metric tile or a control affordance you have not confirmed the connected machine supports. A greyed-out control that reflects the real device is a better product than a bright one that silently does nothing, and it is a much better product than a number field that shows a stale zero forever.

Control point and status channel#

FTMS includes Fitness Machine Control Point, 0x2AD9, the characteristic an app writes commands to, and Fitness Machine Status, 0x2ADA, through which the machine reports state changes. Together they are the two halves of a control loop: you ask, the machine tells you what actually happened.

We are deliberately not documenting op codes or command layouts here. We have not read the specification PDF, and repeating a byte layout from memory is exactly the failure mode that produces subtly broken integrations. The FTMS specification published by the Bluetooth SIG is the source of truth for every wire format on this page.

The honest caveat about control#

Here is the thing that catches teams out, and it is reported rather than something we verified at source: it is widely reported by integrators and reviewers that many machines broadcast FTMS data but ignore or restrict remote-control commands — speed, incline, resistance — outside the brand's own app, and that control support varies per machine and per region.

So the planning rule is: treat data as the thing FTMS reliably buys you, and treat control as a per-model capability you must test on the actual hardware you intend to support. The presence of 0x2AD9 in the characteristic list is evidence that the characteristic exists, not evidence that a given command will be honored. If control is on your roadmap, budget for a hardware matrix, a per-model capability flag in your own config, and a graceful path for machines that decline.

What FTMS is not#

It is not a history API. FTMS streams live; if you want a session record, your app builds it from the stream, timestamps it, and files it — which drags in day boundaries and user time zones, covered in time zones and day boundaries.

It is not a heart rate service. Heart rate has its own standardized service, 0x180D, and a machine's grip sensors or a user's chest strap are a separate connection with a separate lifecycle. See Bluetooth heart rate monitors.

It is not the only source of cycling data. Many trainers also expose the standalone Cycling Power service, which means one device can report the same work through two interfaces — see cycling power and cadence sensors and, for the reconciliation problem it creates, deduplicating health data.

And it is not an identity system. A machine in a gym does not know who is on it. Attribution is your problem.

Platform and testing notes#

On iOS, this is Core Bluetooth work, and Apple's documented requirements apply: NSBluetoothAlwaysUsageDescription in Info.plist since iOS 13, with Apple stating that "your app will crash if its Info.plist doesn't include usage description keys for the types of data it needs to access". Apple also documents that you should not subclass Core Bluetooth's classes, because "overriding these classes isn't supported and results in undefined behavior". See iOS BLE fitness devices.

On the web, Web Bluetooth is supported in Chrome 56+, Edge 79+, Opera 43+ and Samsung Internet 6.2+ per the caniuse dataset, with no support in Firefox at any version and none in Safari on desktop or iOS — a hard constraint for a browser-based gym product. See Web Bluetooth for fitness.

For testing, a physical device is the only reliable target, so build a seam that lets recorded machine data drive your pipeline in CI and reserve the hardware for what only hardware proves. Testing BLE fitness devices covers the pattern, and mocking wearable data covers the fixtures.