Treadmill App Integration: Reading FTMS Treadmill Data

A treadmill is the easiest machine in the FTMS family to read and the most consequential one to write to. Both halves are worth doing carefully, and they deserve different amounts of caution.

Where treadmill data lives#

The Bluetooth SIG's public assigned-numbers registry lists the Fitness Machine Service as 0x1826 and the Treadmill Data characteristic as 0x2ACD. A conforming treadmill advertises the service and streams its metrics through that characteristic, which means your integration is not against a manufacturer — it is against the profile. Discovery, subscription and reconnection are the same code you would write for a rower or an indoor bike; only the parsing changes.

What the characteristic's value contains and how it is laid out is defined in the FTMS specification published by the Bluetooth SIG. We are not paraphrasing byte layouts here, and neither should your parser be written from a forum post. Read the spec, and diff any borrowed parsing code against it.

Read the ranges before you draw a dial#

Two capability characteristics matter for treadmills specifically: Supported Speed Range, 0x2AD4, and Supported Inclination Range, 0x2AD5. The service also carries Fitness Machine Feature, 0x2ACC, for the machine's feature declaration.

Read them at connection time and cache them per device. This is judgement rather than a spec requirement, but it pays for itself immediately: a treadmill in a hotel gym and a treadmill in a garage are different machines with different bounds, and a UI that renders a 0-to-15 incline slider on a machine with no incline motor is a bug report waiting to be filed. Range data also gives you your clamps, which matters enormously the moment you write anything back.

The design rule we would apply: nothing appears in the interface that the connected machine has not confirmed. Not a metric tile, not a slider, not a workout preset that depends on incline.

Control is a per-model question, not a spec question#

FTMS includes Fitness Machine Control Point, 0x2AD9, for writing commands, and Fitness Machine Status, 0x2ADA, through which the machine reports state changes. That is the mechanism.

Whether a given treadmill honors a command is a different matter, and here the honest answer is a reported one rather than a verified one. It is widely reported by integrators and reviewers that many machines broadcast FTMS data but ignore or restrict remote-control commands — speed and incline included — outside the brand's own app, and that control support varies by model and by region. We could not verify a universal rule, and you should not assume one.

Plan accordingly. The presence of 0x2AD9 in a characteristic list proves the characteristic exists, not that your write will move the belt. If control is on your roadmap, budget for a hardware test matrix, keep a per-model capability flag in your own configuration rather than inferring it, and design the product so that a machine which declines control is a supported configuration and not an error state.

If you ship control, engineer it like machinery#

This section is engineering judgement, stated as such, and it comes from a simple observation: writing a speed command to a machine that a human is currently standing on is not the same class of operation as changing a setting. A UI mistake here has a physical consequence. Everything below is what we would consider a minimum.

Clamp to discovered ranges, always. Never send a value your app has not confirmed against Supported Speed Range or Supported Inclination Range, and clamp in the layer closest to the write, not in the view.

Rate-limit and serialize writes. A slider that emits a command per pixel of drag is a stress test of firmware you did not write. Debounce, send the settled value, and do not pipeline commands.

Confirm rather than assume. Do not update your UI optimistically from what you sent. Update it from Machine Status and from the data characteristic — the machine's own report of what happened. A control loop with no feedback leg is a display that lies at exactly the moment the user needs it to be truthful.

Make jumps deliberate. Large speed or incline changes deserve an explicit confirmation, and automated programs deserve a visible preview of what is about to happen and when. Ramping is kinder than stepping.

Own the stop path. There must be a way to stop that does not depend on your animation loop, your Bluetooth queue being drained, or the user finding the right screen. And the physical controls on the machine are always the real safety mechanism — your app is an accessory to them, never a replacement.

Decide what a disconnect means before it happens. If the link drops mid-program, the machine is left in whatever state your last command put it in. Never resume an interval program automatically on reconnect; require a deliberate action to re-enter a controlling state.

None of this makes your app a safety-certified controller, and you should not describe it as one. It makes it a conservative accessory to a machine the user is responsible for.

Reconciling treadmill data with everything else#

A user on an instrumented treadmill wearing a watch and carrying a phone is generating three claims about the same run. If you sum them, their day doubles. Pick one source of truth per metric per session, record which source each sample came from, and reconcile explicitly — the design is in deduplicating health data, and the surrounding metrics live in step counting and calorie tracking.

Heart rate is a separate connection with a separate lifecycle, through service 0x180D — see Bluetooth heart rate monitors. And session boundaries need a decision about whose midnight ends the day, covered in time zones and day boundaries.

Testing#

A physical device is the only reliable test target for BLE, and a treadmill is not a thing you can keep on every developer's desk. Put a seam in front of the transport so recorded treadmill streams can drive parsing, range clamping, session assembly and reconnect handling in CI, then reserve hardware time for the control matrix, which is the part that genuinely requires a machine. Testing BLE fitness devices and device lab and CI cover the setup.