Datler Docs

DatlerDocs

Health and Sensor Data Standards

5 min read

A Puck runs whatever JavaScript it is given, so nothing stops its readings from taking a shape of their own. Every device maker faces the same choice, and how they resolved it says where a reading should take its name, unit and shape. Checked on 2026-10-20; each claim cites where it was read.

Where makers agree

LayerShared?What exists
Device to phone, over BluetoothNoEach watch maker speaks its own protocol, which is why Gadgetbridge carries a driver per brand. The Bluetooth SIG publishes open services, among them Heart Rate, Battery, Environmental Sensing and the Physical Activity Monitor Service for steps and their history [1][2]. No device shipping the last was found.
Activity filesBy habitGarmin’s FIT format, with a public SDK [3]. Strava reads FIT, TCX and GPX, and says no other format is planned [4]. Workouts with a track, not a day’s readings.
The phone’s health storeYesHealth Connect on Android, HealthKit on iPhone. Garmin Connect [6][7] and Gadgetbridge [5] write into Health Connect’s record types, and a Pixel Watch’s sleep sessions, with stages, were found there in a check on 2026-10-10; a maker’s own measures that map to none, such as Garmin’s Body Battery and stress, stay in the maker’s app [6].
Vendor cloudsNoGarmin’s Health and Activity APIs [8], the Google Health API that replaces Fitbit’s, Oura, Whoop and Polar each have their own shapes.
Exchange and researchOn paperOpen mHealth’s schemas, published as IEEE 1752.1, cover sleep and physical activity, step count among them [9][10]. No record of who uses them was found. FHIR serves clinical records.
Home sensorsYesBTHome, an open format for Bluetooth sensor adverts, read by Home Assistant [11][12]; Home Assistant’s sensor device classes name what a home reading is and its unit [13]. Espruino ships a BTHome library [14].

So a body reading’s standard is what Health Connect and HealthKit hold, and a home reading’s is BTHome and Home Assistant.

The shape the phone stores share

Health Connect and HealthKit agree on the shape of a record, if not its names:

  • An interval with a value over it: steps from start to end [15][16].
  • An instant: a temperature at a time.
  • Samples: heart rate as a series in a window.
  • Where it came from on every record: the app that wrote it, the device (maker, model, type), and an id of the writer’s own, which lets two writes of one thing become one record [15].
  • Reading what changed since a bookmark: Health Connect’s change tokens [17], HealthKit’s anchored queries [18]. A reader keeps its own bookmark and asks for what came after it.

BTHome’s button

BTHome defines a button event, object 0x3A, whose value is the event: 0x01 press, 0x02 double press, 0x03 triple press, 0x04 long press, and 0x00 to clear one [19]. A Puck’s button is that object, and Home Assistant shows it as a button’s events with no code of ours. Espruino’s library takes "press", "double_press" and "long_press" under a button_event entry; one entry whose value changes with the press, rather than one entry per kind, sends one event per press [20].

The rule for a reading

  • A body reading takes Health Connect’s record type, unit and shape, with HealthKit’s matching identifier beside it: a Puck’s steps are a steps record over an interval, as HealthKit’s stepCount is [16].
  • A home reading takes BTHome’s object and Home Assistant’s device class and unit: temperature in °C, light in lux, battery in %, a door’s opening, a button’s events.
  • Every reading says where it came from: the device’s own id (never what a platform hands back for it; see Reaching a Puck), its maker, model and firmware, and an id for the reading.
  • Only what no standard covers gets a name of this project’s own, namespaced and documented: a magnetometer’s raw field, say.
  • On the wire: BTHome for what is true now. A device’s stored history has no standard a coin cell can carry, so it is read over a connection in a format of this project’s own (Sensor Data Format), from a bookmark as the phone stores read, and Gadgetbridge’s history request (actfetch) is answered beside it (Reaching a Puck).

Workouts from Garmin and Strava

The same layers apply to workouts:

  • Through the phone’s store. Garmin Connect writes workouts into Health Connect as exercise sessions [6], so a reader of Health Connect gets them without Garmin’s approval, with the measures Health Connect has a type for.
  • As FIT files. The FIT SDK is public [3], so a FIT file a person exports from Garmin Connect can be read whole, track and laps included.
  • Through Garmin’s API. The Activity API serves FIT files to approved business developers [8]. Developer forum reports from 2026 say new access requests are paused, with no date to reopen [21][22]; no announcement from Garmin was found.
  • Strava takes uploads as FIT, TCX or GPX, processed asynchronously, and every record needs a timestamp [4]. Reading a person’s activities goes through its API with their consent; its terms were not checked here.

Sources

  1. Bluetooth SIG, Physical Activity Monitor Service 1.0: https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/PAMS_v1.0/out/en/index-en.html
  2. Bluetooth SIG, Physical Activity Monitor Profile 1.0: https://www.bluetooth.com/specifications/specs/physical-activity-monitor-profile-1-0/
  3. Garmin, FIT SDK overview: https://developer.garmin.com/fit/overview/
  4. Strava, Uploading to Strava: https://developers.strava.com/docs/uploads/
  5. Gadgetbridge, Health Connect integration: https://gadgetbridge.org/basics/integrations/health-connect/
  6. FitMesh, Garmin and Samsung Health sync guide (third party): https://www.fitmesh.fit/en/blog/sync-garmin-samsung-health-guide
  7. Sonar Health, syncing Health Connect and Garmin (third party): https://www.sonarhealth.co/en-GB/blog/sync-health-connect-to-garmin/
  8. Garmin, Activity API: https://developer.garmin.com/gc-developer-program/activity-api/
  9. IEEE 1752.1-2021: https://standards.ieee.org/ieee/1752.1/6982/
  10. IEEE P1752 Physical Activity and Mobility subgroup: https://sagroups.ieee.org/1752/pam-subgroup/
  11. BTHome format: https://bthome.io/format/
  12. Home Assistant, BTHome integration: https://www.home-assistant.io/integrations/bthome/
  13. Home Assistant developer docs, sensor entity and device classes: https://developers.home-assistant.io/docs/core/entity/sensor/
  14. Espruino, BTHome: https://www.espruino.com/BTHome
  15. Android, Health Connect data types: https://developer.android.com/health-and-fitness/guides/health-connect/plan/data-types
  16. Apple, HealthKit stepCount: https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifier/stepcount
  17. Android, Health Connect, synchronizing data: https://developer.android.com/health-and-fitness/guides/health-connect/develop/sync-data
  18. Apple, HKAnchoredObjectQuery: https://developer.apple.com/documentation/healthkit/hkanchoredobjectquery
  19. BTHome v2 library, supported sensors: https://bthomev2.readthedocs.io/en/latest/library/sensors.html
  20. Espruino forum, using the new BTHome library: https://forum.espruino.com/conversations/393639/
  21. Garmin developer forum, Activity API access and the pause: https://forums.garmin.com/developer/connect-iq/f/discussion/440200/connect-developer-program-activity-api-access-no-response-is-the-program-still-paused
  22. Terra, Garmin’s Connect Developer Program is paused (third party): https://tryterra.co/blog/garmin-connect-developer-program-pause

Graph View

Backlinks