Duplicate device entries for one physical strap — removal doesn't stick #740

NOOP version

9.1.0

Platform

Android

OS version

Android 17

WHOOP strap model

WHOOP 5.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

Not a test-mode bug

What happens

Three separate problems on v9.1.0 (Android). The 4.0 bonds, syncs and streams live HR fine, so the BLE stack and permissions are healthy — but WORN never flips to Yes, a single strap shows up as two devices that can't be removed, and 5/MG connects loop endlessly.

1. WORN stays "No" on a working 4.0 while live HR is streaming

Strap is on the arm, green optical LEDs are on, NOOP shows a live heart rate — and the Live Body Console still reports WORN: No.

Live HR flowing proves the strap is measuring and the data path works, so this looks like the worn flag is read from a field that isn't populated, or isn't decoded/surfaced correctly — not an actual wear-detection failure.

Same on the 5/MG (WORN: No while worn, LEDs on), though that one never completes a connect (see 3), so it's less conclusive there.

2. One physical strap shows as two devices, neither removal sticks

A single strap appears twice in "Manage devices":

• WHOOP 5.0 Nr.1 — marked Paired
• WHOOP 5AG0393796 — marked Active

Both are the same physical strap. Removing either doesn't stick — "Device removed" is logged repeatedly and the strap is rediscovered and re-targeted within seconds:
08:45:46 Device removed — released the strap: ... (#520)
08:47:44 Device removed — released the strap: ... (#520)
08:49:29 Device removed — released the strap: ... (#520)
08:49:33 Device removed — released the strap: ... (#520)
08:50:27 Device removed — released the strap: ... (#520)
08:52:16 Device removed — released the strap: ... (#520)

3. 5/MG: CLIENT_HELLO always ends in status=22, retries forever

Every 5/MG attempt is identical and repeats (~40+ cycles in a 5-minute log):
Connected — requesting MTU 247 before discovery
MTU negotiated: 247 (status=0)
Discovering services (mtu=247)
WHOOP 5/MG detected — will send CLIENT_HELLO after subscribing (experimental).
Subscribed 00002a37-...
Subscribed 00002a19-...
WHOOP 5/MG: writing CLIENT_HELLO to fd4b0002 with response (to trigger bonding, experimental).
Signal: RSSI -43 dBm
Disconnected (status=22); reconnecting directly in 3s (attempt 1)

RSSI stays strong throughout (-35 to -50 dBm), so this isn't range — the strap appears to terminate the link itself right after CLIENT_HELLO. Occasionally status=133 or status=34 instead of 22.

I understand the fd4b 5/MG path is experimental, so the failure itself may be expected. But should the retry loop back off or stop after N attempts rather than reconnecting every 3s indefinitely? It runs for as long as the app is open and floods the log.

(My other strap advertises PUFFIN service 1150 and is skipped on every scan. I understand from the pending puffin1150 PR that this family is deliberately non-connectable, so I'm not reporting that here.)

For contrast — the 4.0 works

Same phone, same build:
Bonding: confirmed write GET_BATTERY_LEVEL to 61080002
BONDED (confirmed write acknowledged) — custom channels should now flow
Backfill: 14 day(s) banked; newest=2026-07-23, dashboard-today=2026-07-23 (present)

Minor, possibly unrelated

On the 4.0: Alarm: strap reports NO alarm currently stored (epoch 0) — the arm did not persist on the strap, and the log header shows a strap clock mismatch (Strap reports: 2021-09-13 22:43 ⚠️ MISMATCH). Happy to split into its own issue if unrelated.

What you expected instead

1. WORN reflects the actual wear state — Yes when the strap is worn and producing HR.
2. One device entry per physical strap, and a removed strap stays removed until explicitly re-paired.
3. 5/MG retry loop backs off or gives up after N failed attempts instead of reconnecting every 3s indefinitely.

Steps to reproduce

1. Pair a WHOOP 4.0, wear it, wait for live HR to appear in the Live Body Console
2. Observe: HR is streaming, but WORN still shows "No"
3. Open Manage devices — the 5/MG strap appears as two separate entries (one "Paired", one "Active")
4. Remove either entry — it reappears and auto-connect resumes within seconds
5. Leave the app open — the 5/MG reconnect loop runs continuously (CLIENT_HELLO → status=22 → retry in 3s)

Strap log

(In-app Report export not attached — pasted a trimmed excerpt instead, per the "if you can't attach" note.)
Trimmed excerpt — MAC addresses and serial removed, health metrics omitted. Full redacted export available on request.


App:     9.1.0-staging (full)
Device: Google Pixel 9  ·  Android 17 (SDK 37)
Firmware: 41.17.6.0

--- 4.0 bonds and syncs fine ---
08:39:55  Bonding: confirmed write GET_BATTERY_LEVEL to 61080002
08:39:55  BONDED (confirmed write acknowledged) — custom channels should now flow
08:39:55  → TOGGLE_REALTIME_HR payload=01
08:40:00  Backfill: 14 day(s) banked; newest=2026-07-23, dashboard-today=2026-07-23 (present)

--- 5/MG: CLIENT_HELLO → status=22, repeats indefinitely ---
08:53:12  Connected — requesting MTU 247 before discovery
08:53:13  MTU negotiated: 247 (status=0)
08:53:13  Discovering services (mtu=247)
08:53:13  WHOOP 5/MG detected — will send CLIENT_HELLO after subscribing (experimental).
08:53:13  Subscribed 00002a37-0000-1000-8000-00805f9b34fb
08:53:13  Subscribed 00002a19-0000-1000-8000-00805f9b34fb
08:53:13  WHOOP 5/MG: writing CLIENT_HELLO to fd4b0002 with response (to trigger bonding, experimental).
08:53:15  Signal: RSSI -49 dBm
08:53:16  Disconnected (status=22); reconnecting directly in 3s (attempt 1)
08:53:22  Connected — requesting MTU 247 before discovery
08:53:24  MTU negotiated: 247 (status=0)
08:53:24  WHOOP 5/MG detected — will send CLIENT_HELLO after subscribing (experimental).
08:53:24  WHOOP 5/MG: writing CLIENT_HELLO to fd4b0002 with response (to trigger bonding, experimental).
08:53:25  Signal: RSSI -49 dBm
08:53:27  Disconnected (status=22); reconnecting directly in 3s (attempt 1)
08:53:34  Connected — requesting MTU 247 before discovery
08:53:35  WHOOP 5/MG detected — will send CLIENT_HELLO after subscribing (experimental).
08:53:35  WHOOP 5/MG: writing CLIENT_HELLO to fd4b0002 with response (to trigger bonding, experimental).
08:53:37  Signal: RSSI -46 dBm
08:53:38  Disconnected (status=22); reconnecting directly in 3s (attempt 1)
(pattern repeats ~40x over 5 minutes, RSSI -35 to -50 throughout)

--- PUFFIN 1150 strap never connected ---
08:52:19  Discovered WBB5AP… (rssi -53) — WHOOP PUFFIN service 1150 detected but unsupported; NOOP will not connect or send commands.

--- device removal does not stick ---
08:45:46  Device removed — released the strap: stopped auto-reconnect, dropped the link, cleared targeting. (#520)
08:47:44  Device removed — released the strap: … (#520)
08:49:29  Device removed — released the strap: … (#520)
08:49:33  Device removed — released the strap: … (#520)
08:50:27  Device removed — released the strap: … (#520)
08:52:16  Device removed — released the strap: … (#520)

--- alarm / clock (minor) ---
08:39:55  Alarm: armed (epoch 1784844600)
08:39:55  Alarm: strap reports NO alarm currently stored (epoch 0) — the arm did not persist on the strap
Header:   Strap reports: 2021-09-13 22:43  ⚠️ MISMATCH — strap didn't accept the time

Before you submit

• I attached my exported NOOP .zip (not a screenshot of the Live screen). If my bug is a clearly reproducible UI issue I described exactly how to see it instead.
• I attached or pasted a strap log above — or my bug is a clearly reproducible UI issue that doesn't need one (e.g. a typo, a button that does nothing) and I've described exactly how to see it.
• I checked the Troubleshooting guide — especially "history syncs but no data" (most often the strap isn't banking history to flash; charge it to 100% and reconnect).
• I checked the FAQ and — if I'm on a WHOOP 5.0 / MG — the 5.0/MG status page, and this isn't an already-known limit (e.g. SpO₂, or recovery/sleep on the 5/MG).
• I've left out anything personal (strap serial, account email, raw export).