# Fitbit Sense 2 + Hevy — Options Race Summary

Date: 2026-05-26

## Current leaderboard

### 1) Path A — Fitbit owns live workout state, syncs completed workout to Hevy

**Status:** GO. Most robust product path.

Directory: `/home/ubuntu/fitbit-hevy-spike/path-a-companion/`

Created scaffold:
- Fitbit app + companion skeleton
- state machine
- GUI sketch
- backend API sketch
- smoke test plan

Core idea:
```text
Hevy routine -> Pipo backend -> Fitbit app live logging -> backend -> POST completed workout to Hevy
```

Pros:
- Does not depend on hidden Hevy endpoints.
- Gives best UX for workout flow, rest timer, RIR logging.
- Works even if Hevy never exposes live state.

Cons:
- Fitbit sideload/dev bridge must work.
- Need to build enough app UI ourselves.

Next gate:
```bash
cd /home/ubuntu/fitbit-hevy-spike/path-a-companion
npm install
npx tsc --noEmit
npx fitbit-build
```
Then real Sense 2 Developer Bridge connection.

### 2) Path B — Reverse-engineer Hevy live/draft state

**Status:** FEASIBLE research path. Highest upside, most uncertain.

Directory: `/home/ubuntu/fitbit-hevy-spike/path-b-hevy-live/`

Key findings:
- Hevy Android is React Native (`com.hevy`).
- JS bundle likely contains API call strings.
- React Native AsyncStorage may live at `/data/data/com.hevy/databases/RKStorage`.
- Known internal API exists (`dmzoneill/hevyapp-api`) with headers like `klean_kanteen_insulated` / `shelobs_hevy_web`.
- Official public API has no live workout endpoint.
- Wear OS live sync suggests live state exists somewhere, likely local/device-layer, not public cloud.

Best experiments:
1. Hevy web DevTools/HAR capture.
2. ADB extract app storage during active workout.
3. APK decompile + bundle string search.
4. mitmproxy if needed.

Pros:
- If live state endpoint/storage is found, Fitbit can act closer to YouTube Music remote.
- Could integrate with Hevy's native session rather than replacing it.

Cons:
- Could break any app update.
- Android app storage may require root/debuggable app; `run-as com.hevy` may fail.
- Cert pinning may complicate MITM.

### 3) Path C — Pixel-side bridge controls/reads Hevy UI/notifications

**Status:** VIABLE pragmatic bridge.

Directory: `/home/ubuntu/fitbit-hevy-spike/path-c-android-bridge/`

Core idea:
```text
Hevy Android app -> NotificationListener / AccessibilityService / Tasker -> Pipo backend -> Fitbit companion
```

Fastest MVP:
- Tasker + AutoNotification reads Hevy persistent/live workout notification.
- POSTs parsed state to Pipo backend.
- Fitbit companion polls backend.

Fallback:
- Custom Android APK with NotificationListenerService.
- AccessibilityService for richer UI tree and possible button taps.

Pros:
- Does not require hidden Hevy cloud endpoint.
- Can piggyback current Hevy app behavior.
- Fastest real-world test if Hevy notifications contain enough data.

Cons:
- Notification may not contain enough detail.
- Accessibility UI scraping is fragile.
- Fitbit companion cannot directly talk to Hevy; backend mediation required.

## Best strategy

Run all three, but in this order for execution gates:

1. **A build gate:** can we compile/install a Sense 2 app?
2. **C observation gate:** what does Hevy expose via Android notifications/accessibility during a real active workout?
3. **B discovery gate:** is there a live Hevy state source in web/app storage/internal API?

If A passes, build the product around A. If B or C finds live Hevy control, plug it into A as optional adapter.

## Immediate user-side requirements

Need Chicho with:
- Sense 2 on charger
- Fitbit phone app open
- Developer Bridge enabled if available
- Pixel 9a connected by ADB for Android/Hevy capture
- A test workout started in Hevy for notification/storage/network observations

## Project directories

```text
/home/ubuntu/fitbit-hevy-spike/
├── README.md
├── OPTIONS-RACE-SUMMARY.md
├── path-a-companion/
├── path-b-hevy-live/
└── path-c-android-bridge/
```