wearable support

[jeremymanning]

add support for connected wearables that can be used to track sleep stages more accurately.

[jeremymanning]

first stage: open API wearables
second stage: add support for all possible devices (cover at least 90+% of the current wearables market)

[jeremymanning]

Wearable Integration Implementation Plan

Goal

Support 90%+ of wearables owned by US users for real-time sleep stage detection.

---

US Wearable Market Share (Estimated 2024-2025)

Device/Platform	Market Share	Sleep Stage API	Real-Time?
Apple Watch	~55%	HealthKit	Post-sleep only*
Fitbit	~12%	Health Connect	Post-sleep only
Samsung Galaxy Watch	~8%	Health Connect	Post-sleep only
Garmin	~7%	Garmin Connect API	Post-sleep only
Oura Ring	~4%	Oura API	Near real-time (cloud)
Whoop	~3%	Whoop API	Post-sleep only
Amazfit	~2%	Zepp API	Limited
Others	~9%	Varies	Varies

Critical finding: Almost no consumer wearables provide TRUE real-time sleep stage data to third-party apps. They compute stages post-sleep.

---

Phase 1: Easy Wins (iOS + Android health platforms)

Apple HealthKit (iOS) - ~55% coverage

• Data available: Sleep analysis with stages (awake, REM, core, deep)
• Real-time: NO - only after sleep session ends
• Workaround: Poll for heart rate + motion during sleep, infer stages
• Integration: expo-health (Expo plugin)
• Effort: Medium (2-3 weeks)

Google Health Connect (Android) - ~25% coverage

• Devices: Fitbit, Samsung, Wear OS, many others
• Data available: Sleep stages, heart rate, SpO2
• Real-time: NO - post-sleep sync
• Workaround: Same as HealthKit - poll vitals, infer stages
• Integration: react-native-health-connect
• Effort: Medium (2-3 weeks)

Phase 1 Total Coverage: ~80%

---

Phase 2: Direct Device APIs

Oura Ring (~4% but growing)

• Advantage: Cloud API with frequent sync (~5 min intervals)
• Data: Sleep stages, HRV, temperature
• Approach: OAuth integration, poll API during sleep
• Effort: Low (1 week)

Garmin Connect (~7%)

• Advantage: Established API
• Data: Sleep, stress, body battery
• Challenge: OAuth flow, rate limits
• Effort: Medium (2 weeks)

Phase 2 Total Coverage: ~90%

---

Phase 3: Enhanced Detection

Hybrid Approach

Combine wearable vitals with existing audio detection:

• Wearable: Heart rate, HRV, motion
• Audio: Breathing patterns, movement sounds
• ML model: Fuse signals for better accuracy

Whoop Integration (~3%)

• Requires partnership/API access
• High-quality HRV data
• Effort: High (requires business relationship)

---

Technical Architecture

┌─────────────────────────────────────────────────────────┐
│                   WearableService                        │
├─────────────────────────────────────────────────────────┤
│  HealthKitProvider  │  HealthConnectProvider  │  OuraProvider
│       (iOS)         │       (Android)          │   (Cloud)
├─────────────────────────────────────────────────────────┤
│                  SleepStageInferenceEngine               │
│   (Combines vitals from any source → sleep stage)        │
├─────────────────────────────────────────────────────────┤
│                  Existing AudioSleepDetector             │
│           (Fallback when no wearable connected)          │
└─────────────────────────────────────────────────────────┘

---

Key Challenges

1. No true real-time data: Must infer from vitals
2. Battery drain: Frequent polling on mobile
3. Permissions: Health data requires careful UX
4. Accuracy: Inferred stages less accurate than post-hoc analysis

Recommended Priority

1. HealthKit (biggest market share, best documented)
2. Health Connect (covers Android ecosystem)
3. Oura (best near-real-time option)
4. Garmin (large user base)

---

Expo/React Native Libraries

• expo-apple-health-kit or react-native-health
• react-native-health-connect
• Custom fetch for Oura/Garmin REST APIs

[jeremymanning]

Revised Plan: Real-Time Sleep Stage Detection

The Core Problem

Consumer wearables compute sleep stages post-hoc using ML models on the full night's data. They don't expose real-time stage predictions because:

1. Accuracy requires context (future data helps classify past segments)
2. Battery optimization - continuous streaming drains devices
3. Business model - keeps users in their ecosystem

However, they DO stream raw vitals (HR, HRV, motion) that we can use to infer stages ourselves.

---

Strategy: Hybrid Real-Time Inference

Instead of relying on device-computed stages, we:

1. Stream raw vitals from wearables (HR, HRV, accelerometer)
2. Run our own sleep stage classifier on the phone
3. Fuse with audio detection for improved accuracy

┌─────────────────┐     ┌─────────────────┐
│   Wearable      │     │   Microphone    │
│  (HR, HRV, Acc) │     │  (Breathing)    │
└────────┬────────┘     └────────┬────────┘
         │ BLE/HealthKit          │ Audio API
         ▼                        ▼
┌─────────────────────────────────────────┐
│      Real-Time Sleep Stage Classifier   │
│  (Lightweight ML model on phone)        │
└────────────────────┬────────────────────┘
                     ▼
              [REM Detected] → Play Dream Audio

---

Real-Time Data Availability by Platform

Apple Watch + HealthKit (iOS)

Data	Real-Time?	Method	Battery Impact
Heart Rate	✅ Yes	HKObserverQuery	Low (sampled)
HRV	✅ Yes	HKObserverQuery	Low
Motion/Accel	✅ Yes	CMMotionManager	Medium
Sleep Stage	❌ No	Post-sleep only	N/A

Approach: Use HKObserverQuery with background delivery for HR/HRV updates every ~5-15 min. Supplement with motion data.

Wear OS / Health Connect (Android)

Data	Real-Time?	Method	Battery Impact
Heart Rate	⚠️ Varies	Health Services API	Medium
HRV	⚠️ Varies	Device-dependent	Medium
Motion	✅ Yes	SensorManager	Medium
Sleep Stage	❌ No	Post-sleep only	N/A

Approach: Use Health Services API for passive heart rate monitoring. Fall back to phone accelerometer + audio if wearable data sparse.

Oura Ring (Cloud API)

Data	Real-Time?	Method	Battery Impact
All vitals	⚠️ ~5 min delay	REST API polling	None (cloud)
Sleep Stage	⚠️ ~5 min delay	REST API	None

Approach: Poll API every 5 min during sleep session. Oura actually DOES provide near-real-time hypnogram data - best option for accuracy!

---

Polling Strategy (Battery-Optimized)

Adaptive Polling Rate

AWAKE:        Poll every 5 min (low frequency)
DROWSY:       Poll every 2 min (increasing)
LIGHT SLEEP:  Poll every 1 min (watching for REM)
REM DETECTED: Poll every 30 sec (confirm stability)
DEEP SLEEP:   Poll every 3 min (REM unlikely soon)

Background Execution

iOS:

• Use BGAppRefreshTask for periodic wakeups
• HKObserverQuery with background delivery for health data
• Audio session keeps app alive during playback

Android:

• Foreground service with low-priority notification
• WorkManager for periodic sync
• Wake locks only during active REM detection

---

Sleep Stage Classification Model

Input Features (from vitals)

• Heart rate (absolute + variability)
• HRV metrics (RMSSD, SDNN)
• Motion intensity (accelerometer magnitude)
• Breathing rate (from audio or derived from HRV)
• Time since sleep onset

Output

• Probability distribution: [Awake, Light, Deep, REM]
• Confidence score

Model Options

1. Rule-based heuristics (MVP - no ML needed)

   • High HRV variability + low motion → likely REM
   • Very low HRV variability + no motion → likely Deep

2. TensorFlow Lite model (v2)

   • Train on public sleep datasets (MESA, Sleep-EDF)
   • ~100KB model, runs on-device

3. Federated learning (future)

   • Improve model with user feedback (did the dream cue feel well-timed?)

---

Revised Implementation Phases

Phase 1: Apple Watch Real-Time (2-3 weeks)

• Implement HKObserverQuery for HR/HRV background delivery
• Add CMMotionManager for motion detection
• Build rule-based sleep stage classifier
• Adaptive polling based on detected state
• Fuse with existing audio-based detection
• Coverage: ~55% of US wearable users

Phase 2: Oura Ring Integration (1-2 weeks)

• OAuth flow for Oura API
• Poll hypnogram endpoint during sleep
• Oura provides actual sleep stages - highest accuracy!
• Coverage: +4% (but high-value users)

Phase 3: Wear OS / Health Connect (2-3 weeks)

• Health Services API for passive HR
• Handle device fragmentation (Samsung vs Fitbit vs Pixel)
• Same classifier as iOS
• Coverage: +25%

Phase 4: ML-Based Classification (2-3 weeks)

• Train TFLite model on public datasets
• A/B test against rule-based approach
• Add user feedback loop ("Was timing good?")

---

Battery Optimization Techniques

1. Batch sensor reads - Collect 10-30 sec of data, process, sleep
2. Adaptive polling - Slow down when sleep is stable
3. Coalesce updates - Process health updates in batches
4. Doze-friendly scheduling - Use platform-recommended APIs
5. User control - Let users choose accuracy vs battery tradeoff

---

Key Insight: Oura is the Best Path

Oura Ring is unique because:

• Cloud-syncs every ~5 minutes during sleep
• API returns computed sleep stages (not just raw vitals)
• No battery drain on phone (data comes from cloud)
• Growing market share, popular with biohackers

Recommendation: Prioritize Oura integration in Phase 2 for best real-time accuracy, while Apple Watch provides widest coverage with acceptable accuracy.

[jeremymanning]

Update: Pixel Watch 3 Priority

Adding Pixel Watch 3 as a Phase 1 target for developer testing.

Pixel Watch 3 Capabilities

Feature	Availability	API
Heart Rate	✅ Continuous	Health Services API
HRV	✅ Yes	Health Services API
SpO2	✅ Yes	Health Services API
Skin Temperature	✅ Yes	Health Services API
Motion/Accel	✅ Yes	SensorManager
Sleep Stages	❌ Post-sleep	Health Connect

Why Pixel Watch is Actually Great for This

1. Health Services API - Google's Wear OS 4+ provides PassiveMonitoringClient for background health data without draining battery
2. Direct sensor access - Can read accelerometer/gyro in real-time via SensorManager
3. Fitbit algorithms - Uses Fitbit's sleep tracking (acquired by Google), high quality
4. Fast Health Connect sync - Syncs to phone frequently

Implementation for Pixel Watch 3

// Passive heart rate monitoring (battery-efficient)
val passiveClient = PassiveMonitoringClient(context)
passiveClient.setPassiveListenerCallback(
    PassiveListenerConfig.builder()
        .setDataTypes(setOf(DataType.HEART_RATE_BPM))
        .build(),
    callback
)

For real-time during sleep session:

// Active measurement when user starts sleep mode
val measureClient = MeasureClient(context)
measureClient.registerMeasureCallback(
    DataType.HEART_RATE_BPM,
    heartRateCallback
)

Revised Phase 1 (Parallel Tracks)

Track A: Apple Watch (iOS) - 2-3 weeks

• HKObserverQuery for HR/HRV
• CMMotionManager for motion
• Rule-based classifier

Track B: Pixel Watch 3 (Android) - 2-3 weeks

• Health Services API (MeasureClient for active, PassiveMonitoringClient for background)
• Health Connect for any cached data
• Same classifier logic as iOS

Both tracks share:

• Sleep stage inference model
• Audio detection fusion
• Adaptive polling logic

Testing Plan

With Pixel Watch 3 available for testing:

1. Validate HR/HRV data quality during sleep
2. Test battery drain with different polling intervals
3. Compare our inferred stages vs Fitbit's post-sleep analysis
4. Tune classifier thresholds based on real data

[jeremymanning]

Web App Feasibility Analysis

The Bad News

Direct wearable access from web browsers is essentially impossible:

API	Web Support	Why Not
Apple HealthKit	❌ No	iOS-only, no web API
Health Services (Wear OS)	❌ No	Android-only
Health Connect	❌ No	Android-only
Web Bluetooth	⚠️ Limited	See below

Web Bluetooth - Could It Work?

Web Bluetooth API exists but has severe limitations:

// This DOES work in Chrome
navigator.bluetooth.requestDevice({
  filters: [{ services: ['heart_rate'] }]
})

Problems:

1. Requires user gesture - Can't auto-connect, user must tap each time
2. No background - Tab must stay open and active
3. No reconnect - Loses connection when screen locks
4. Limited device support - Many wearables don't expose standard BLE services
5. No iOS Safari - Apple blocks Web Bluetooth entirely

Pixel Watch 3 via Web Bluetooth?

• Pixel Watch doesn't advertise standard heart_rate BLE service to phones
• It uses proprietary Wear OS protocols
• Web Bluetooth won't work

Cloud API Workaround

Some services expose data via REST APIs that a web app CAN access:

Service	Web-Accessible?	Real-Time?	Auth
Oura API	✅ Yes	~5 min delay	OAuth
Fitbit Web API	✅ Yes	~15 min delay	OAuth
Garmin Connect	✅ Yes	Hours delay	OAuth
Google Fit REST	✅ Yes	Variable	OAuth
Apple HealthKit	❌ No	N/A	N/A

Best Path for Web: Fitbit/Google Fit API

Since Pixel Watch 3 syncs to Fitbit (Google owns Fitbit):

Pixel Watch 3 → Fitbit servers → Fitbit Web API → Our web app
                     ↑
              ~5-15 min sync interval

Implementation:

1. User authorizes Fitbit OAuth in web app
2. During sleep session, poll Fitbit API every few minutes
3. Fitbit provides intraday heart rate data
4. We run our classifier on that data

Latency: 5-15 minutes (Fitbit sync interval)
Accuracy: Degraded due to delay, but usable for longer REM cycles

Recommendation: Hybrid Approach

Platform	Approach	Latency
Web (any wearable)	Cloud APIs (Fitbit, Oura, Google Fit)	5-15 min
Web (no wearable)	Audio-only detection	Real-time
Native iOS	HealthKit direct	Real-time
Native Android	Health Services direct	Real-time

For Your Pixel Watch 3 Testing (Web)

1. Ensure Pixel Watch syncs to Fitbit account
2. Authorize Fitbit in web app
3. Poll https://api.fitbit.com/1/user/-/activities/heart/date/today/1d/1min.json
4. Get 1-minute resolution heart rate data
5. Run classifier on latest data

Limitation: You'll have 5-15 min delay, so REM detection will lag. For a 20+ minute REM cycle, this might still be useful. For shorter cycles, we'd miss the window.

Conclusion

Web-only with real-time wearable data: Not possible.

Web with cloud APIs: Possible but 5-15 min delayed.

For true real-time: Native app required (or stick with audio-only detection which works great in web).

---

Should we:

1. Implement Fitbit Web API integration (delayed but works)?
2. Prioritize native app development for real-time?
3. Focus on improving audio-only detection for web?

[jeremymanning]

Native App Development - Current State

What's Already Done ✅

Component	Status
Expo SDK 54	✅ Current
React Native 0.81	✅ Current
App identifiers configured	✅ com.dreamstream.app
UI/Navigation/Storage	✅ All cross-platform
Audio playback (expo-av)	✅ Works on native
HealthKit permissions in app.json	✅ Already declared

What's Missing

Component	Effort
Native project files (/android, /ios)	npx expo prebuild - 5 min
Health Connect package	npx expo install - 10 min
Health integration code	1-2 weeks
Audio capture adaptation	2-3 days

To Build Android APK Right Now

# Option 1: Cloud build (no local setup needed)
npx eas build --platform android --profile preview

# Option 2: Local build (requires Android Studio)
npx expo prebuild --platform android
npx expo run:android

Realistic Timeline From Here

Task	Time
First working APK on your Pixel	1 day
Health Connect integration	1 week
Real-time sleep detection working	1-2 weeks
Play Store submission	+1 week

Total to testable Android app with wearable support: ~3 weeks

---

The codebase is already native-ready. Main work is just the health API integration.