Skip to content

Effort on top and strain in key metrics no longer the same #1001

Closed

Description

@bartmuskala

NOOP version

9.3.0

Platform

Android

OS version

16

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

Since the last update the effort score is calculated more effectively/ as expected. But the stain score is no longer the same. Potentially also elsewhere a discrepancy (coupled view?).

Image

What you expected instead

The same scores everywhere.

Steps to reproduce

See results in screenshot.

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

  1. KOUSHIK-9 commented on Jul 31, 2026

    @KOUSHIK-9

    Problem: The "Effort" score shown in the hero rings (top of screen) and the "Key Metrics" grid were out of sync for TODAY.
    Root Cause:

    • Hero ring used effortStrain(d) which includes live in-progress strain (liveTodayStrain) for TODAY
    • Key Metrics tile used d?.strain directly (stored daily value only)
      Fix Applied (both TodayView and LiquidTodayView):
    1. Classic TodayView (Strand/Screens/TodayView.swift:3303-3318):
    • Changed Key Metrics Effort tile to use effortStrain(d) instead of d?.strain
    1. Liquid LiquidTodayView (Strand/Liquid/LiquidTodayView.swift):
    • Added liveTodayStrain state variable
    • Added live strain computation in load() function (computes strain from HR samples since midnight for TODAY)
    • Added effortStrain(_:) helper function mirroring classic TodayView's logic
    • Updated both hero Effort ring and Key Metrics Effort tile to use effortStrain(displayDay)
      Now for TODAY, both the hero ring and Key Metrics tile show the live in-progress effort (floored at the stored value to prevent drops), and for past days both show the stored daily value.
  2. pilleuspulcher-blip commented on Jul 31, 2026

    @pilleuspulcher-blip

    For me it's okay, effort on top of today' and effort (Belastung) in key metrics are equal. But I use a Whoop 4.0. 🤔

    Image
  3. bartmuskala commented on Jul 31, 2026

    @bartmuskala
    Author

    Now it is also the same again. Before it was not. Sometimes it is not in sync, moments/a while later it is.

  4. ryanbr commented on Jul 31, 2026

    @ryanbr
    Owner

    Confirmed from the screenshot, and it is a display inconsistency rather than a scoring one — the 2.3 is right and the 0.5 is stale.

    Effort is shown in three places on Today, and only one of them recomputes:

    • the hero ring takes the live in-progress value, integrating today's HR from local midnight to now, floored at the day's already-earned Effort — 2.3
    • the Key Metrics tile reads the last persisted daily row — 0.5
    • the HR chart's edge badge reads the same persisted row — 0.5

    That row is only rewritten when the heavy daily pass runs. Your chart shows HR flat at 44–57 overnight and then climbing hard from about 09:00, with the screenshot taken at 12:22, so the stored row predates this morning entirely. The hero counts that climb; the other two have not seen it yet.

    Recovery and Rest match across all their read-outs precisely because neither has a live path — nothing to disagree with.

    Not caused by the 9.3.0 Effort change, though I understand why it looks that way. The live hero landed in v4.0.1 on 15 June and the Key Metrics tile has read the stored column unchanged since 14 June, so the split is about six weeks old. What 9.3.0 changed is how the score is weighted, which makes the live number track an active morning more closely — so the gap against a stale stored row is wider and finally visible. Your read that Effort itself now behaves better is the same change.

    Both platforms have it. iOS is the clearer illustration: there is already a helper whose entire job is to be the one effective value, and whose own comment says it should feed "the hero ring AND every Effort read-out, so they stay consistent" — but the tile and the chart badge each reach past it to the stored column.

    Fixing it properly, on both platforms: resolve Effort once and give the tile and the badge the same value the ring gets, keeping the never-drop floor so a sparse-HR moment cannot make any of them fall. Will do that as its own PR.

  5. ryanbr commented on Aug 1, 2026

    @ryanbr
    Owner

    Fixed in #1006, on main now.

    Effort is resolved once and every read-out uses that figure — the hero ring, the Key Metrics tile and the chart's edge badge. The tile and the badge were reading the daily row, which only refreshes when the heavy daily pass runs, so on a morning like yours they trailed the ring by the whole morning's load.

    The screen-reader description on the heart-rate chart had the same wrong number and is fixed by the same change.

    Two things worth saying since you spotted this from the numbers rather than a crash: the 2.3 was the correct one, and your read that Effort itself now behaves better is a real change (#963) — it tracks an active morning more closely, which is what made the stale figure obvious.

    It will be in the next release. Thanks for the screenshot with both values in frame; that is what made it diagnosable without a log.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions