Repository navigation
[iOS][Oura] Live Console shows WHOOP pairing state and WHOOP battery while Oura Ring 5 is active #2075
Description
NOOP version
11.5.0
Platform
macOS
OS version
iOS 27.0 (24A435)
WHOOP strap model
WHOOP 5.0
Where the data is coming from
Oura import
Test Centre profile
Not a test-mode bug
What happens
When Oura Ring 5 is selected as the active device, the Live Console shows a partially paired / WHOOP-style connection state and appears to use WHOOP battery state instead of the active Oura battery.
The Live Console shows:
- Device: Oura Ring 5
- Status: “Live HR (not fully paired)”
- Battery: 72%
However, the Oura connection itself is successfully authenticated and streaming.
The log shows:
- Oura notifications enabled
- Oura auth OK
- Oura live-HR enabled
- Oura ring WORN
- Oura history caught up
- Oura skin temperature decoded
- Oura live HR / IBI streaming
The strongest indication of a wrong-device state leak is the battery value:
Oura reports:
Oura: battery 93%
WHOOP reports:
SUPERVISOR: SOC report: 72.40
But the Live Console displays:
Oura Ring 5 — Battery 72%
So the UI appears to be displaying WHOOP/shared strap battery state while Oura Ring 5 is the active device.
The app also attempts WHOOP-only commands while Oura is active, for example:
send(R10/R11 Realtime (raw stream)) ignored — command characteristic unavailable
send(Toggle Realtime HR) ignored — command characteristic unavailable
refreshBattery ignored — not connected
send(Run Haptics Pattern) ignored — command characteristic unavailable
Meanwhile the registry correctly reports:
WHOOP is no longer the active device — not scanning or connecting until it is again (#1881)
Active device oura-… is not a WHOOP — leaving sample attribution on my-whoop (#1881)
This appears to be an iOS device-state / UI-routing issue rather than an Oura authentication failure.
What you expected instead
When Oura Ring 5 is the active device, the Live Console should use Oura-specific connection and battery state.
Expected behavior:
- Oura should be shown as fully authenticated/connected after auth succeeds.
- The “Live HR / not fully paired” WHOOP-style state should not appear for an authenticated Oura ring.
- The battery value should come from the Oura battery response.
- WHOOP-only connection state or battery state should not appear in the Oura Live Console.
- WHOOP-only controls should not be routed to the active Oura device.
Steps to reproduce
- Have both a WHOOP 5.0 and an Oura Ring 5 registered in NOOP.
- Select Oura Ring 5 as the active device.
- Allow NOOP to connect and authenticate with the Oura ring.
- Confirm in the log that Oura reports “auth OK” and “live-HR enabled”.
- Open the Live Console.
- Observe that the device is correctly labeled Oura Ring 5.
- Observe that the status says “Live HR (not fully paired)”.
- Observe the battery value shown in the Live Console.
- Compare it with the log:
- Oura battery: 93%
- WHOOP SOC: 72.40%
- Live Console displays: 72%
noop-connection-iOS-v11.5.0-260910-1954.zip
Strap log
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).
Activity
ryanbr commentedon Sep 11, 2026
Thanks @rafaelphh, this was a good report and the battery comparison is what made it quick to localise. Ring 93, strap 72.40, console drawing 72 pinned it to the readout rather than to the Oura connection, exactly as you said.
Both halves were real and they had one cause.
LiveStateis a single object every live source writes into, so "is this field populated" is not the same question as "does this field describe the device on screen", and nothing in the console asked the second.The pill was a precedence bug rather than a missing case. Its ring branch already existed, but
activeConnectionis pure WHOOP state and is tested first, so a bonded strap made the ring branch unreachable. It is now gated on the active device actually being a WHOOP, which also settles your last point: the bond-only controls (buzz, alarm, HRV snapshot) all key off the same flag, so they stop being live while a ring is active.The battery was missing plumbing. The ring's charge was decoded and held in the Oura source but never published, so the console had nothing but the WHOOP field to draw. It now publishes beside the wear state, and a non-WHOOP active device never falls back to the strap's number: an em dash means "not reported", where the strap's charge under the ring's name is a confident lie.
Two things your report led to beyond what you filed. The same leak reached the Devices list and the home-screen widget, on both platforms, so those are covered too. And it was never Apple-only: Android had the identical ordering.
PR #2076 has landed and it is in testing build 485. Your form said macOS while the OS line said iOS 27, which made no difference here since that console is shared, but worth knowing for the next one.
pipiche38 commentedon Sep 11, 2026
@rafaelphh I'm glag to find an Oura user, and even better you have an Gen5 ring.
if @ryanbr does agree and if you accept , I would appreciate to have your support to send me time to time some NOOP logs for investigations and to fine tune the Oura plumbing in the best way
fix(oura): exempt oura-raw.jsonl from the WHOOP-serial hex redaction …
fix(oura): never write GetProductInfo replies into the raw diagnostic…
fix(oura): mask an Oura serial in the log redactors, both platforms (r…
fix(oura): mask an Oura serial in the log redactors, both platforms (#…
rafaelphh commentedon Sep 11, 2026
@pipiche38 I’m very interested in helping make Oura support work as well as possible in NOOP. My Oura Ring has never been connected to the official Oura app, so it may be a useful test case for fully local/offline behavior.
I’ve also noticed that NOOP tries to read some Ring features that remain OFF from factory/default state, and from the reverse-engineering work around Oura it appears some of those features can be enabled through feature-mode commands rather than being permanently unavailable. That may be worth investigating further for local-only rings.
You have my full attention for any logs, traces, tests, or diagnostics you need. Just tag me and tell me exactly what to capture or try, and I’ll send it.
pipiche38 commentedon Sep 11, 2026
@rafaelphh are you on discord ?
rafaelphh commentedon Sep 11, 2026
@pipiche38 yes. https://discord.gg/pBa9w7b8
pipiche38 commentedon Sep 14, 2026
@rafaelphh this should be fixed with NOOP 11.6.0 and above.
Kindly confirm and close if that is confirmed
doc(issues): let the bug form name an Oura ring, not only a WHOOP str…
doc(readme): say which ring each Oura row was measured on, and update…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(live): no WHOOP strap picker or Scan / Re-scan under an active Ou…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(oura): do not arm daytime HR on a connect made while live HR is s…
fix(today): draw the active ring's own battery in the Liquid header i…
fix(today): draw the active ring's own battery in the Liquid header i…
today: draw the active ring's own battery in the Liquid header (#2374)
fix(oura): do not arm daytime HR on a connect made while live HR is s…