--- title: "Connected Devices" canonical: "https://aifitnessapi.com/devices" type: "cluster-index" pages: "12" last_reviewed: "2026-08-14" publisher: "AIFitnessAPI" --- # Connected Devices > 12 pages. Each entry below shows the question the page owns, followed by its answer capsule. ## Connect a Bluetooth Heart Rate Monitor to Your App (2026) - Question: connect a bluetooth heart rate monitor to an app - HTML: https://aifitnessapi.com/devices/bluetooth-heart-rate-monitor - Markdown: https://aifitnessapi.com/devices/bluetooth-heart-rate-monitor.md - Last reviewed: 2026-08-14 A conforming Bluetooth heart rate monitor exposes the standardized Heart Rate service, so one integration works across straps and armbands from any vendor. The Bluetooth SIG's public assigned-numbers registry lists the Heart Rate service as 0x180D, Heart Rate Measurement as 0x2A37 and Body Sensor Location as 0x2A38. The flow is the same everywhere: scan filtered on the service UUID, connect, discover the service and its characteristics, enable notifications on the measurement characteristic, and read the body sensor location once for context. Parse the measurement value against the Heart Rate Service specification published by the Bluetooth SIG rather than against a copied snippet. Wrist and chest readings can differ because placement and sensor type differ, so record the source with every sample instead of assuming the two are interchangeable. ## Reading Cycling Power, Cadence, and Speed Sensors in an App - Question: read cycling power meter cadence sensor app - HTML: https://aifitnessapi.com/devices/cycling-sensors-power-cadence - Markdown: https://aifitnessapi.com/devices/cycling-sensors-power-cadence.md - Last reviewed: 2026-08-14 Three standardized Bluetooth services cover the sensors most cycling and running apps need: Cycling Power 0x1818 with Cycling Power Measurement 0x2A63, Cycling Speed and Cadence 0x1816 with CSC Measurement 0x2A5B, and Running Speed and Cadence 0x1814 with RSC Measurement 0x2A53. The integration pattern is the same for all three: scan filtered on the service UUID, connect, discover by UUID, and enable notifications on the measurement characteristic. Wire formats are defined in the Bluetooth SIG's specifications for each service, so parse against those rather than a copied snippet. The trap is overlap: a smart trainer may expose the Cycling Power service and FTMS Indoor Bike Data at once, so pick one source of truth per metric or you will double-count. ## What Is FTMS? The Bluetooth Fitness Machine Service (2026) - Question: what is FTMS fitness machine service - HTML: https://aifitnessapi.com/devices/ftms-fitness-machine-service - Markdown: https://aifitnessapi.com/devices/ftms-fitness-machine-service.md - Last reviewed: 2026-08-14 FTMS is the Bluetooth SIG's Fitness Machine Service, assigned number 0x1826, and it is the standard way a treadmill, rower, bike or climber streams its own data to an app. It defines a separate data characteristic per machine type: Treadmill Data 0x2ACD, Cross Trainer Data 0x2ACE, Step Climber Data 0x2ACF, Stair Climber Data 0x2AD0, Rower Data 0x2AD1 and Indoor Bike Data 0x2AD2. Capability discovery runs through Fitness Machine Feature 0x2ACC plus the Supported Range characteristics, and control runs through Fitness Machine Control Point 0x2AD9 with Fitness Machine Status 0x2ADA reporting back. Integrators commonly report that many machines broadcast FTMS data but ignore or restrict remote-control commands outside the brand's own app, so treat control as a per-model capability you must test. ## Treadmill App Integration: Reading FTMS Treadmill Data - Question: connect treadmill data to fitness app - HTML: https://aifitnessapi.com/devices/treadmill-app-integration - Markdown: https://aifitnessapi.com/devices/treadmill-app-integration.md - Last reviewed: 2026-08-14 A treadmill that speaks the Bluetooth Fitness Machine Service exposes Treadmill Data on characteristic 0x2ACD under service 0x1826, and that is the one integration you need for the data side. Before rendering anything, read the capability characteristics: Supported Speed Range 0x2AD4 and Supported Inclination Range 0x2AD5 tell you the bounds this machine actually works within. Control is a separate matter: the Fitness Machine Control Point 0x2AD9 exists, but integrators commonly report that many machines broadcast data while ignoring or restricting remote-control commands outside the brand's own app, so treat it as a per-model capability you must test. If you do ship control, engineer it conservatively, because a human is standing on the belt. ## Smart Bike Trainer Integration: FTMS and Cycling Power - Question: integrate smart bike trainer app - HTML: https://aifitnessapi.com/devices/indoor-bike-trainer-integration - Markdown: https://aifitnessapi.com/devices/indoor-bike-trainer-integration.md - Last reviewed: 2026-08-14 A smart trainer usually presents two standardized interfaces at the same time: Indoor Bike Data, characteristic 0x2AD2, under the Fitness Machine Service 0x1826, and the standalone Cycling Power service 0x1818 with its Cycling Power Measurement characteristic 0x2A63. Both can describe the same pedaling, so pick one source of truth per metric per session and record which one you used. Discover capability before you render anything: Supported Resistance Level Range 0x2AD6 and Supported Power Range 0x2AD8 tell you the bounds a given trainer reports. The FTMS Control Point 0x2AD9 exists as a characteristic, but exact command support varies per trainer and integrators commonly report that machines restrict control outside the brand's own app, so verify against the hardware and the vendor's documentation. ## Getting Rowing Machine Data Into an App (2026) - Question: get rowing machine data into app - HTML: https://aifitnessapi.com/devices/rowing-machine-data - Markdown: https://aifitnessapi.com/devices/rowing-machine-data.md - Last reviewed: 2026-08-14 The standard path for ergometer metrics is Rower Data, characteristic 0x2AD1, under the Bluetooth Fitness Machine Service 0x1826. A conforming rower advertises that service and streams its metrics through that characteristic, so one integration covers conforming machines from any vendor rather than one per brand. The exact contents and layout of the value are defined in the FTMS specification published by the Bluetooth SIG, which is the only thing worth parsing against. Some manufacturers also document their own proprietary interfaces alongside or instead of FTMS, and where that is the case the vendor's own documentation is the source of truth. Build the transport and session layers so a second data source can be added without rewriting them. ## Live Heart Rate From Apple Watch in Your App (2026) - Question: get live heart rate from apple watch in app - HTML: https://aifitnessapi.com/devices/apple-watch-live-heart-rate - Markdown: https://aifitnessapi.com/devices/apple-watch-live-heart-rate.md - Last reviewed: 2026-08-14 HealthKit is a store, not a live stream, so polling it harder will not give you a number that updates while somebody is mid-interval. On Apple Watch the live path is a workout session: Apple documents that a session fine-tunes the watch's sensors for the activity you declare, and that all workout sessions generate high-frequency heart rate samples. HKWorkoutSession is available from watchOS 2.0, and Apple also lists iOS, iPadOS and Mac Catalyst 17.0 and visionOS 1.0. Apple Watch runs one session at a time, so a second workout started elsewhere ends yours, which makes session-ended a normal state your UI has to handle. If you need heart rate without requiring an Apple Watch at all, pair a Bluetooth strap directly and read the standard Heart Rate service instead. ## Wear OS Health Services for Live Workout Data (2026) - Question: wear os health services live workout data - HTML: https://aifitnessapi.com/devices/wear-os-health-services - Markdown: https://aifitnessapi.com/devices/wear-os-health-services.md - Last reviewed: 2026-08-14 Health Services is the platform service on Wear OS 3 and later that sits between your app and the watch's sensors and algorithms, so you ask it for metrics rather than reading hardware yourself. Use ExerciseClient for an active workout: it manages the workout, sets exercise goals, reports exercise state updates, and delivers rapid data updates while exercise is in progress, across metrics Google lists as heart rate, distance, calories, elevation, floors, speed, pace and more. Use PassiveMonitoringClient for the long-lived, low-frequency case, which Google describes as suited to experiences where data updates are relatively infrequent. Google states that Health Services conserves battery using sensor configurations optimized for power efficiency, and verifies data consistency across all applications on the same device by using standardized platform computations. You would still pair a Bluetooth sensor directly when the signal has to come from hardware the watch does not contain, or when the same code has to run on phones and in a browser. ## ANT+ vs Bluetooth for Fitness Sensors (2026) - Question: ant+ vs bluetooth fitness sensors - HTML: https://aifitnessapi.com/devices/ant-plus-vs-bluetooth - Markdown: https://aifitnessapi.com/devices/ant-plus-vs-bluetooth.md - Last reviewed: 2026-08-14 For a new fitness app in 2026, Bluetooth Low Energy is the default radio and ANT+ is a compatibility question about hardware your users already own. Widely quoted reporting from January 2025, citing thisisant.com, said the ANT+ membership and certification programs would be discontinued on June 30, 2025, with certification applications accepted only until March 31, 2025; the same coverage reported that device profiles and documentation remain available to developers and that existing ANT+ devices are unaffected. We could not reach the official page through our proxy, so treat those dates as reported rather than verified. BLE APIs are first-class on both iOS and Android, whereas receiving ANT+ on a phone has historically needed extra hardware or platform-specific plugins, which you should verify against current vendor documentation. The practical answer: build on BLE, and treat ANT+ as an ecosystem you interoperate with rather than a second radio you design around. ## Web Bluetooth for Fitness Apps in the Browser (2026) - Question: web bluetooth fitness app browser - HTML: https://aifitnessapi.com/devices/web-bluetooth-fitness - Markdown: https://aifitnessapi.com/devices/web-bluetooth-fitness.md - Last reviewed: 2026-08-14 Web Bluetooth lets a web page talk to heart rate straps and gym machines over the same standard GATT profiles a native app uses, but the browser support is the whole story. Per the caniuse dataset, it is supported in Chrome 56 and later, Edge 79 and later, Opera 43 and later, and Samsung Internet 6.2 and later; it is not supported in Firefox at any version, and not in Safari on desktop or iOS, where a third-party app polyfill exists but is not WebKit. Support also varies by operating system, with Windows, macOS, Linux, Android from M, and ChromeOS listed. The product conclusion follows directly: a Chromium-only, kiosk-style or desktop experience is viable, and any product that must reach iPhone users in Safari cannot be built on it. ## Core Bluetooth for Fitness Devices on iOS (2026) - Question: ios core bluetooth fitness devices - HTML: https://aifitnessapi.com/devices/ios-ble-fitness-devices - Markdown: https://aifitnessapi.com/devices/ios-ble-fitness-devices.md - Last reviewed: 2026-08-14 Core Bluetooth is the iOS framework for talking to heart rate straps, cycling sensors and gym machines, and Apple's abstract for it is to communicate with Bluetooth low energy and BR/EDR Classic devices. Your fitness app is almost always the central: CBCentralManager scans for, connects to and manages peripherals, while CBPeripheralManager is the other role, for advertising services from the device your code runs on. Since iOS 13 you must include NSBluetoothAlwaysUsageDescription in Info.plist, and Apple states that your app will crash if its Info.plist doesn't include usage description keys for the types of data it needs to access; iOS 12 and earlier used NSBluetoothPeripheralUsageDescription. Apple also says not to subclass any Core Bluetooth class, because overriding them isn't supported and results in undefined behavior. Keep the framework behind a narrow protocol so recorded device data can drive the rest of your pipeline without hardware. ## Testing Bluetooth Fitness Device Integrations (2026) - Question: test bluetooth fitness device integration - HTML: https://aifitnessapi.com/devices/testing-ble-fitness-devices - Markdown: https://aifitnessapi.com/devices/testing-ble-fitness-devices.md - Last reviewed: 2026-08-14 A physical device is the only reliable test target for live Bluetooth behavior, so the goal is not to fake the radio but to make sure almost nothing in your product depends on it. Put a narrow seam between the platform Bluetooth API and everything downstream, record real notification streams from real sensors and machines, and replay those recordings as fixtures in CI so parsing, aggregation and session assembly are covered without hardware. That leaves a small set of behaviors that only a device lab catches, in our judgement: first-time pairing, reconnection after a dropout, and interference in a room full of other sensors. Cover those with a short manual matrix per release rather than pretending a green CI run has tested them.