abacusai.health_data_source
Classes
A connected Health data source (a wearable/device via Terra). |
Module Contents
- class abacusai.health_data_source.HealthDataSource(client, healthDataSourceId=None, provider=None, kind=None, status=None, errorDetail=None, connectedAt=None, lastSyncedAt=None, isLiveSync=None, isImported=None, isDeviceUpload=None, errorKind=None)
Bases:
abacusai.return_class.AbstractApiClassA connected Health data source (a wearable/device via Terra).
- Parameters:
client (ApiClient) – An authenticated API Client instance
healthDataSourceId (id) – The ID of the data source.
provider (str) – Provider key (oura, fitbit, garmin, …).
kind (str) – wearable | nutrition | cgm.
status (str) – active | syncing | error | disconnected.
errorDetail (str) – Why this source is not delivering what it should. Set when status is ‘error’, and also on an ‘active’ source that the provider has only partly authorized — the connection works and some data flows, but a whole category of it never will until the user re-grants (see ingestion._missing_scope_advisory). Clients must branch on status for severity rather than treating the presence of this field as failure.
connectedAt (str) – When the source was connected.
lastSyncedAt (str) – Last successful sync time.
isLiveSync (bool) – Whether the server keeps this source current on its own — by pulling the aggregator, or by receiving the provider’s pushes (a Garmin connected directly) — as opposed to the phone feeding it or nothing feeding it. A client treats such a row as a live connection; asking the server to sync it is always safe (a push-fed row answers with nothing to pull). Not derivable from provider: an Apple Health row is live only once the iOS SDK has connected it, and a Garmin row is live whether Terra pulls it or Garmin pushes it, so clients must branch on this rather than on a hardcoded provider list.
isImported (bool) – Whether this source’s readings were uploaded from a file rather than pulled from a provider connection. Such a row reports is_live_sync False, and this is what lets a client say WHY — readings that never came from a device, rather than a connection that broke — which only the server can tell, since the fact behind it (the absent aggregator_ref) is never exposed.
isDeviceUpload (bool) – Whether this source is fed by our own app reading the phone’s health store and uploading (Apple Health on the HealthKit-direct path). Such a row reports is_live_sync False — there is nothing to pull, the upload is the whole feed — yet it is a live connection: a client treats it as connected and refreshes it by uploading, never by asking the server to sync.
errorKind (str) – error_detail as an identifier a client can branch on exactly, instead of inferring it from status and provider: awaiting_first_data (a phone store connected under 48h ago with nothing delivered yet), never_delivered (connected, nothing has ever arrived), provider_permission (the provider refused access or the consent granted no data scope), partial_scope (active, but a permission keeps one category of data from arriving), connection_lost, sync_failed, or unknown for a sentence written before these were fixed. Null when error_detail is null.
- health_data_source_id = None
- provider = None
- kind = None
- status = None
- error_detail = None
- connected_at = None
- last_synced_at = None
- is_live_sync = None
- is_imported = None
- is_device_upload = None
- error_kind = None
- deprecated_keys
- __repr__()