WHOOP MG / 5.0: band not discovered by AccessorySetupKit pairing sheet (No Accessory Found) even when flashing blue and visible in system Bluetooth

[dev-noaman]

Summary

On iOS 18+, OpenStrap pairs exclusively through the AccessorySetupKit (ASK) system sheet. The ASK discovery descriptor matches only the WHOOP 4.0 "Harvard" service UUID 61080001-8D6D-82B8-614A-1C8CB0F8DCC6, and that is the only UUID declared in Info.plist under NSAccessorySetupBluetoothServices.

A WHOOP MG / 5.0 does not advertise that service, so the ASK sheet has nothing to match and shows "No Accessory Found" — regardless of the band being in pairing mode, flashing blue, and plainly visible to the rest of the system.

There is also no fallback: on iOS 18+ the pairing screen short-circuits to the ASK path before the service-filtered scan is ever reached, so a gen5 owner has no route to pairing at all.

Environment

Band	WHOOP MG, serial redacted (advertises as WHOOP MGB…)
Phone / OS	iOS 18+ (AccessorySetupKit path)
Edge version	v0.9.25-whoop5-experimental and earlier whoop5 tags
Official WHOOP app	Force-quit for the whole test
Band state	Pairing mode, LED flashing blue

Steps to reproduce

1. Force-quit the official WHOOP app.
2. Put the WHOOP MG on its charger and enter pairing mode (LED flashes solid blue).
3. Open OpenStrap → pairing screen → tap "My strap is in pairing mode" → tap Pair.
4. The system AccessorySetupKit sheet appears.

Expected

The ASK sheet lists WHOOP MGB… (or a generic "WHOOP band" row) and lets me select it, after which OpenStrap provisions it and connects.

Actual

The ASK sheet stays empty and shows:

No Accessory Found.
Make sure the accessory is nearby and ready to connect.

The band never appears in the sheet, even while flashing blue and even though it is simultaneously listed in Settings → Bluetooth → My Devices as WHOOP MGB… — Connected.

Additional observations

• In iOS Bluetooth Settings the entry frequently has no (i) button, so it cannot be forgotten normally — only a full Reset Network Settings clears it. Worth establishing whether that stale/foreign bond has any effect on ASK discovery, or whether it is a red herring next to the descriptor mismatch below.
• The 4.0 flow on the same phone/build is unaffected.

Where this appears to come from

Reading main at 6bddec4 (pubspec.yaml version 0.9.26+57):

Location	What it does
ios/Runner/AccessorySetup.swift:31	whoopServiceUUID hardcoded to the gen4 service only
ios/Runner/AccessorySetup.swift:148	The single ASDiscoveryDescriptor matches only that UUID
ios/Runner/Info.plist:54-57	NSAccessorySetupBluetoothServices declares only that UUID; no NSAccessorySetupBluetoothNames
lib/ui/pairing_screen.dart:217-222	On iOS 18+ the screen returns at askReady — the scan fallback is unreachable
lib/ble/ble_engine.dart:1081,1091,1098	The non-ASK scan also filters on the gen4 service only
lib/ble/ble_engine.dart:1275	Post-connect service discovery requires a 61080001… service or aborts

ASK will only surface an accessory that matches a descriptor whose every criterion is also declared in Info.plist. With only the gen4 UUID declared and matched, a gen5 / MG band can never appear in the sheet. This is sufficient on its own to produce the reported symptom — no bond weirdness required.

Note on the current gen5 claims

README.md:146-147 states that "WHOOP 5.0 / MG support is in progress and experimental — the band is detected and spoken to". On main today there is no gen5 code at all: fd4b appears nowhere in the repository, and lib/sync/sync_policy.dart:7-11 records that the one speculative WHOOP5 helper was removed as unwired dead code ("WHOOP 4.0 only (the only family OpenStrap supports)").

If the whoop5-experimental tags carry gen5 work on a branch, that's fine — but the README on main currently overstates the state of support, which is how a gen5 owner ends up here expecting discovery to work.

Why community captures matter here

The maintainer does not own a 5.0 or MG strap, so every gen5 path is written from captures and community reports.

I have an MG and can capture whatever is useful. Tell me what you want and I'll produce it. The most valuable single artifact is a raw BLE advertisement dump of the band in pairing mode:

• nRF Connect (iOS or Android) → scan → find WHOOP MGB… → export the full RAW advertisement, including:
  • Complete/shortened local name
  • Service UUIDs in both the advertisement and the scan response
  • Manufacturer-specific data (company ID + payload)
  • Service data, TX power, flags
• The same capture again after connecting, showing the full GATT service and characteristic tree.

If a 16-bit 0xFD4B service is what the band advertises, it should be visible in an ordinary unfiltered iOS scan — iOS only hides 128-bit UUIDs that land in the scan response's hashed overflow area. That makes the capture cheap and decisive.

Suggested direction

1. Declare and match the gen5 service UUID(s) in both Info.plist and the ASK descriptor, as an additional ASPickerDisplayItem so the 4.0 path is untouched (a single descriptor AND-combines its criteria — gen4 and gen5 must be separate items).
2. Add a name-substring descriptor (WHOOP, with a matching NSAccessorySetupBluetoothNames entry) as a safety net while the gen5 UUID is unconfirmed.
3. Extend the Dart scan filter and post-connect service discovery to accept the gen5 UUID family alongside gen4.
4. Add an opt-in discovery-probe / diagnostics dump to the pairing screen so gen5 owners can report a real capture from inside the app.
5. Keep every gen5 path explicitly marked experimental in comments and release notes.

I've taken a run at all five — draft PR incoming, linked below. It is unbuilt (authored on Windows, no Xcode) and the gen5 UUID in it is a guess, so please treat it as a starting point rather than a finished change.

Suggested labels: bug, iOS, and a gen5 / whoop5 label if you want one — neither of the latter two exist on the repo yet.

[dev-noaman]

Root cause found — and it is not quite what this issue says

The diagnosis here was right that the ASK descriptor cannot match a WHOOP 5.0 / MG. It
was wrong about the fix, and I want to correct that publicly because #238 originally
proposed a UUID that would not have worked either.

The gen5 service UUID is fd4b0001-cce1-4033-93ce-002d5875f58a.

Not 0000FD4B-0000-1000-8000-00805F9B34FB. 0xFD4B is a real Bluetooth SIG member
UUID assigned to WHOOP, so expanding it against the Bluetooth base UUID looked correct —
but it is actually the first 32 bits of a 128-bit vendor UUID, in precisely the shape
gen4 already uses:

gen4:  61080001-8d6d-82b8-614a-1c8cb0f8dcc6
gen5:  fd4b0001-cce1-4033-93ce-002d5875f58a

Characteristics are numbered identically off each prefix (0002 write, 0003/4/5
notify, 0007 debug). Cross-checked against two independent public gen5 clients that
agree exactly: b-nnett/goose (GooseBLEClient.swift) and its Kotlin port
dsp515/GooseAndroid (WhoopUUIDs.kt).

Since ASK matches a declared descriptor byte-for-byte, one wrong UUID produces no error
and no partial match — just an empty sheet, permanently. That is the whole of this bug.

The bigger finding

Gen5 is not a separate protocol. Packet types, command opcodes and the record header
are identical to 4.0 — including the per-version HR offset table {7:27, 9:17, 12:17, 18:14, 24:17}, which this repo and goose derived independently, from different hardware,
and got identical. Only the UUID prefix and the frame envelope differ (8-byte header with
a CRC-16/MODBUS, vs 4-byte with a CRC-8).

So a real transport was ~150 lines of framing, not a second stack. #238 now carries it,
tested against real WHOOP 5.0 captures.

A second cause this issue may also be hitting

Worth separating, because it is not fixed by any of the above: the report notes the band
shows as WHOOP MGB… — Connected under My Devices with no (i) button.

A band already connected at system level is not advertising, and then no app can
discover it regardless of which UUIDs are declared. If you are testing this, forget the
device first. I have no evidence either way about whether this suppressed ASK discovery
here — flagging it as an independent hypothesis rather than a claim.

Still unverified

Nobody working on this owns a 5.0 or MG, and the iOS target is unbuilt (Windows dev
machine, no Xcode). Android shares the whole transport and needs no Xcode, so an Android
gen5 owner is the cheapest first real-hardware signal.

[dev-noaman]

Status update, and the one capture that would close the remaining gap.

The fix is on main

FD4B0001-CCE1-4033-93CE-002D5875F58A is now in ios/Runner/Info.plist, and the Dart
scan filter matches fd4b0001. That is the cause of this issue: ASK matches a declared
service byte-for-byte, and the previously declared 0000FD4B-0000-1000-8000-00805F9B34FB
— the 16-bit member UUID expanded against the Bluetooth base UUID — is a different UUID
that no band advertises. One wrong constant, zero results, no error to debug.

Credit where due: @abdulsaheel reached the same 128-bit UUID independently, and the wire
format landed in the protocol package (protocol#27 + edge#97) rather than in edge, so both
generations share one codec.

What is still unknown

From the #238 close:

whether the fd4b service UUID is in the primary advertisement or only the scan response.
we believe it is advertised, but nobody has put a real WHOOP 5 in front of the app.

This matters because iOS cannot filter on a 128-bit UUID that only appears in the scan
response — those land in a hashed overflow area that CoreBluetooth will not surface as a
readable UUID. If fd4b0001… is scan-response-only, the service descriptor can never
match on iOS and the name-substring item is the only thing that can work. On Android it
would make no difference.

I have a WHOOP MG and will capture this.

What to capture, for anyone else with a gen5 band

nRF Connect (iOS or Android, free), band in pairing mode (flashing blue), official
WHOOP app force-quit:

1. Scanner tab → find the WHOOP … entry
2. Tap it to expand → RAW / "Advertising data"
3. Screenshot or export both sections separately:
   • Advertising Data (the 31-byte primary packet)
   • Scan Response Data

The question is simply: which of those two contains FD4B0001-CCE1-4033-93CE-002D5875F58A,
or the 16-bit 0xFD4B, or neither.

Also worth recording while you are there: the complete Local Name, and whether
connectable is true.

Android is the better capture. It returns the full advertisement with no overflow
hashing, so it answers the question outright. An iOS capture can show the band by name
while hiding the very 128-bit UUID we are asking about — which is the failure mode in
question, not evidence against it.

Please redact before posting

An nRF Connect screenshot shows every device in range, not just yours — names are often
people's names, and addresses are MACs. Crop to the WHOOP entry, and mask your own band's
serial in the Local Name (WHOOP 5A…, WHOOP MGB…) — the prefix is the only part that
carries model information. GitHub's after-the-fact redaction is not reliable.

One thing to check before concluding the band is undiscoverable

If the sheet still shows nothing on a build with the corrected UUID: look at whether the
band appears as Connected under Settings → Bluetooth → My Devices. A band already
connected at system level is not advertising, and then no app can discover it whatever the
UUIDs say. Forget the device first, then retry. That is a separate cause from this issue
and was never ruled out here.