Title: Oura Ring (Gen 3) not found during BLE scan (v0.9.29+) #372

Activity

1. pipiche38 commented on Oct 3, 2026

   

   pipiche38

   on Oct 3, 2026

   Contributor

   More actions

   having the same issue
2. pipiche38 commented on Oct 3, 2026

   

   pipiche38

   on Oct 3, 2026

   Contributor

   More actions

   I think I've found the cause, at least on iOS 18+. Same symptom here: iPhone, nothing paired in Edge yet, the Oura app and the other ring app killed with their Bluetooth permission switched off, and the ring never appears in the sensor search. The WHOOP search, on the other hand, does find a strap.

   Edge has no Bluetooth permission at all. Settings → Apps → Edge has no Bluetooth row (screenshot attached), so iOS never granted Edge normal CoreBluetooth access. Edge declares NSAccessorySetupKitSupports = Bluetooth in ios/Runner/Info.plist. As far as I can tell from third-party AccessorySetupKit write-ups and an Apple developer-forum report, an app in that mode doesn't get the standard Bluetooth prompt, and a CoreBluetooth scan or connect only reaches accessories the user approved through the ASK picker.

   That explains the split:

   • WHOOP pairing works because it goes through AccessorySetup.showPicker().
   • Every notify-class sensor goes through HrsLink.scanFor / scanForAny. That is a plain FlutterBluePlus.startScan(withServices: …), and it only ever sees ASK-approved peripherals. The Oura service 98ED0001-A541-11E4-B6A0-0002A5D5C51B is not in NSAccessorySetupBluetoothServices, so the ring can't be approved anywhere, and the search returns an empty list with no error.

   tool/gen_ios_ask_plist.dart states the assumption that breaks here: "A notify-only sensor is connected straight from its stored remote id during a workout and needs no ASK descriptor." That only holds for an app that also has global Bluetooth authorization, and this one doesn't. If that's right, it affects every non-WHOOP sensor on iOS 18+ (chest straps, Polar, the rings), not just Oura.

   PR #484's systemDevices (retrieveConnectedPeripherals) is limited the same way, so I don't think it fixes this case on its own.

   Possible direction, untested:

   1. Declare the sensor services in the ASK block. The generator currently takes kFramedBands only.
   2. Let showPicker take a per-call service filter, so the WHOOP picker doesn't start showing rings and straps. The existing gen4 retry also assumes items[0] is the WHOOP 4.0 item.
   3. On iOS 18+, pair sensors through the picker, then use the returned bluetoothIdentifier as remoteId for the existing connect path, e.g. pairOuraRing(BluetoothDevice.fromId(id)).

   Two unknowns:

   • The "CBManager is active with global permissions" ordering constraint that _provisionAdditionalAccessory already works around. A sensor search that already ran in the same process probably blocks the picker until the next launch.
   • Whether the ASK picker matches the ring's 128-bit service. Another app does find this ring with the same withServices filter, but that doesn't prove the service is in the primary advertisement rather than the scan response.

   Happy to test a build on my iPhone and ring.
3. pipiche38

   added a commit that references this issue on Oct 3, 2026

   oura: say which pairing ran, and probe the ring before connecting

   ...

   6caa923
4. abdulsaheel

   added a commit that references this issue on Oct 4, 2026

   ios: pair the oura ring through its own accessorysetupkit picker

   ...

   8a7473d