Skip to content

[master] Alarm not buzzing #34

New issue
New issue
Open
#340
Open
[master] Alarm not buzzing#34
#340
Labels
bugSomething isn't working

Description

@andresbernalc
andresbernalc
opened on Jul 7, 2026

NOOP version

8.3.1

Platform

iOS

OS version

Version 26.5.1 (Build 23F81)

WHOOP strap model

WHOOP 4.0

Where the data is coming from

Live Bluetooth (strap connected)

Test Centre profile

Notifications, Alarm & Wake

What happens

hi, thanks for keeping the project alive!

I found a bug where the smart alarm is not buzzing, I’m attaching the strap log for your reference.

noop-master-iOS-v8.3.1-260707-1220.zip

What you expected instead

Alarm to buzz at the set time

Steps to reproduce

Strap log

<details><summary>Strap log (last 40 lines, redacted)</summary>


sleep day=2026-07-06 totalSleepMin=442 matched=1 source=computed
[universal] dayOwner day=2026-07-06 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=193179 provenance=measured
sleep day=2026-07-05 totalSleepMin=433 matched=1 source=imported:apple
[universal] dayOwner day=2026-07-05 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=193694 provenance=imported:apple
sleep day=2026-07-04 totalSleepMin=506 matched=1 source=imported:apple
[universal] dayOwner day=2026-07-04 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192401 provenance=imported:apple
sleep day=2026-07-03 totalSleepMin=359 matched=1 source=imported:apple
[universal] dayOwner day=2026-07-03 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192717 provenance=imported:apple
sleep day=2026-07-02 totalSleepMin=487 matched=1 source=imported:apple
[universal] dayOwner day=2026-07-02 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192917 provenance=imported:apple
sleep day=2026-07-01 totalSleepMin=344 matched=1 source=imported:apple
[universal] dayOwner day=2026-07-01 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192318 provenance=imported:apple
sleep day=2026-06-30 totalSleepMin=520 matched=2 source=imported:apple
[universal] dayOwner day=2026-06-30 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192653 provenance=imported:apple
sleep day=2026-06-29 totalSleepMin=384 matched=2 source=imported:apple
[universal] dayOwner day=2026-06-29 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=193492 provenance=imported:apple
sleep day=2026-06-28 totalSleepMin=404 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-28 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192789 provenance=imported:apple
sleep day=2026-06-27 totalSleepMin=526 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-27 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=192974 provenance=imported:apple
sleep day=2026-06-26 totalSleepMin=458 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-26 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=136485 provenance=imported:apple
sleep day=2026-06-25 totalSleepMin=30 matched=0 source=imported:apple
[universal] dayOwner day=2026-06-25 readId=whoop-<device> writeActiveId=whoop-<device> hrRows=51107 provenance=imported:apple
sleep day=2026-06-24 totalSleepMin=426 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-24 readId=my-whoop writeActiveId=whoop-<device> hrRows=187483 provenance=imported:apple
sleep day=2026-06-23 totalSleepMin=448 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-23 readId=my-whoop writeActiveId=whoop-<device> hrRows=187333 provenance=imported:apple
sleep day=2026-06-22 totalSleepMin=418 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-22 readId=my-whoop writeActiveId=whoop-<device> hrRows=190974 provenance=imported:apple
sleep day=2026-06-21 totalSleepMin=453 matched=1 source=imported:apple
[universal] dayOwner day=2026-06-21 readId=my-whoop writeActiveId=whoop-<device> hrRows=117585 provenance=imported:apple
sleep day=2026-06-20 totalSleepMin=30 matched=0 source=imported:apple
[universal] dayOwner day=2026-06-20 readId=my-whoop writeActiveId=whoop-<device> hrRows=33871 provenance=imported:apple
[universal] strapClock newest=2025-04-16 20:33:03 wall=2026-07-07 11:19:31 newestVsWall=-38587588s firmware=v24 CLOCK-WARNING (newest banked record 446d behind wall; strap clock reset or history stale)

----------------------------------------
Capture check
  [OK] display: 1 trace line (dataVolume / frameSummary)
  [OK] universal: 55 trace lines (dayOwner  / strapClock )

</details>

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. andresbernalc
    added
    bugSomething isn't working
    on Jul 7, 2026
  2. ryanbr
    added 2 commits that reference this issue on Jul 7, 2026

    Alarm debug block: add last-fired, model/experimental gate, strap-clo…

    a0cf9c5

    Merge pull request #37 from ryanbr/alarm-debug-and-armed-log

    21d4550

  3. ryanbr commented on Jul 7, 2026

    @ryanbr
    ryanbr
    on Jul 7, 2026
    Owner

    Thanks for the log — it makes the cause clear, and it's on the strap side rather than in the alarm command itself.

    The app is doing the right thing: it sends Set Clock (the current time) and Set Alarm Time for your wake (e.g. epoch 1783455840 = Tue 21:24 BST). But every read-back the strap gives comes back as the same old value:

    Alarm: strap reports armed for Sun 05:07 BST (epoch 1616904449)

    1616904449 is 28 March 2021 — and it stays that no matter what we set. The strap is rejecting the new alarm time and its internal clock is stuck years in the past. The same log shows why:

    Backfill: strap reported no flash cursor … This is a clock/charge state on the strap, not a decode problem; fully charge it and reconnect.

    The firmware alarm fires off the strap's own clock. With that clock stuck in 2021 and the alarm time not updating, it can't buzz at your real wake time — the same clock/charge state that's also stopping it from banking history.

    What to try: charge the strap to 100%, then reconnect and leave it connected for a few minutes so the firmware re-establishes its clock and starts banking again. Keep a phone backup alarm in the meantime. If, once it's charged, the "strap reports armed for…" line starts matching the time you set, the alarm should fire.

    On our end (shipping in v8.3.3):

    • The alarm log no longer claims "armed" when the strap is disconnected — your log has a few Set Alarm Time ignored — not connected lines immediately followed by "armed", which was misleading. It now says "queued, will send on next connect" until the command actually goes out.
    • The shared debug export now carries an Alarm block that flags exactly this: it compares the time we sent against what the strap reports back (so the 2021 mismatch shows up as a warning) and flags a reset/stale strap clock.

    Update to v8.3.3, try the charge-and-reconnect, and if it still won't take the new time, re-share a log — the Alarm block will show at a glance whether the clock re-synced.

  4. andresbernalc commented on Jul 7, 2026

    @andresbernalc
    andresbernalc
    on Jul 7, 2026
    Author

    I charged the strap to 100% and follow the steps to reconnect but the alarm is still not buzzing. It seems the clock is still set in the past. I just extracted a fresh log, attached here. Thanks for all your help with this.

    noop-master-iOS-v8.3.4-260707-1635.zip

  5. tanarchytan
    added a commit that references this issue on Jul 7, 2026

    Debug export: Alarm block + don't log 'armed' when disconnected (ryan…

    0ec7545
  6. ryanbr
    added 2 commits that reference this issue on Jul 8, 2026

    Merge pull request #75 from ryanbr/alarm-reject-warn

    f4ee7f8

    Merge pull request #73 from ryanbr/fix-alarm-backup-decouple

    01bf451

  7. ryanbr commented on Jul 8, 2026

    @ryanbr
    ryanbr
    on Jul 8, 2026
    Owner

    The fresh log tells the story: the charge fixed the strap's clock (it now reads the correct time), but its alarm register is stuck — it keeps reporting an alarm time from March 2021 no matter what NOOP sends, across six attempts. That's the strap's firmware refusing the alarm write (a corrupted alarm register), which NOOP can't override from the app.

    What'll actually clear it: reset the strap through the official WHOOP app (or, if you can, let it fully drain and recharge), then reconnect — that rebuilds the strap's clock/alarm state. Keep your phone's built-in Clock alarm as your wake in the meantime.

    On our side, 8.4.0 now (1) schedules the phone backup notification for your smart alarm even if you never turned on wrist alerts, and (2) shows an on-screen warning when the strap keeps refusing the alarm — so this stops being a silent failure. Neither fixes a corrupted strap, but they mean you're not left with nothing. If a reset gets the strap accepting the time again and it still won't buzz, send a fresh log and I'll dig further.

  8. andresbernalc commented on Jul 8, 2026

    @andresbernalc
    andresbernalc
    on Jul 8, 2026
    Author

    hi, thanks for your response. I reset the band on the whoop app and tested the alarm on that app and it worked correctly.

    Upgraded to 8.4 and tested the alarm on noop and it’s still not buzzing. The alarm used to work before upgrading to 8.0 or around that time so I’m assuming something must have changed in the latest releases.

    I’m attaching the latest log for your reference. Thank you so much for all your help with this.

    noop-master-iOS-v8.4.0-260708-0816.zip

  9. tanarchytan
    added 2 commits that reference this issue on Jul 8, 2026

    Smart alarm: phone backup follows the alarm, not the wrist-alerts mas…

    304c3fd

    Smart alarm: instrument + warn when the strap keeps refusing the alar…

    cee89ee
  10. TheBoroer
    added a commit that references this issue on Jul 10, 2026

    fix: rename Today feed header "Last Workouts" -> "Latest Workouts"

    af547ef

  11. digitalerdude commented on Jul 10, 2026

    @digitalerdude
    digitalerdude
    on Jul 10, 2026

    Went through the attached strap log (report.txt). The alarm frames look correct — the problem is on the strap clock / alarm-register side. Evidence, then the likely mechanisms.

    What the log shows

    • SET_CLOCK and SET_ALARM_TIME are both sent and well-formed right after reconnect:
      • → Set Clock payload=c1df4c6a… (LE 0x6a4cdfc1 ≈ 2026-07-07 12:15 UTC — correct current time)
      • → Set Alarm Time payload=0160604d6a00000000 = [0x01] + LE 0x6a4d6060 (=1783455840, the intended wake) + 0000 + 0000 — the exact 9-byte frame verified on a real 4.0 in ci(i18n): audit main pushes, not just PRs into it #535.
    • The GET_ALARM_TIME readback is constant and stale: every Get Alarm Time reply decodes to epoch 1616904449 = 2021-03-28, and it never matches what was just sent, across the whole session.
    • The strap clock itself is badly off ([universal] strapClock …):

      strapClock newest=2025-04-16 20:33:03 wall=2026-07-07 11:19:31 newestVsWall=-38587588s firmware=v24 CLOCK-WARNING (newest banked record 446d behind wall; strap clock reset or history stale)

    Likely mechanism (two, both strap-side)

    1. Corrupted / stuck firmware alarm register. The readback returning a fixed 2021 epoch regardless of what's armed is exactly the "corrupted strap alarm register" signature the #34 reject-streak diagnostic was built to catch — and it is firing here (reported ≠ sent, persistently).
    2. RTC not holding the set. The alarm fires against the strap's own RTC, and the log shows that RTC ~446 days behind wall with a CLOCK-WARNING (strap clock reset). If SET_CLOCK isn't sticking, an alarm armed for a 2026 epoch sits far in the strap's future and never reaches its trigger time — so it never buzzes even if "armed".

    Either way this is a device/firmware-state problem on this strap (firmware v24), not an app encoding bug: the SET frames match the on-device-verified capture, and the app is correctly detecting the refusal. Likely remedies are strap-side — a full charge + reboot/re-pair, or a strap reset (relates to #166, Device Restart/Reset).

    One app-side improvement that would nail it

    Right now the raw GET_ALARM_TIME response bytes are only logged when the decode fails; on a successful-but-mismatched decode (like here) we log the interpreted epoch but not the raw frame — so we can't tell a genuinely-stored stale alarm from a misdecode of a fixed response field. Two cheap, log-only additions would make the next report conclusive:

    Happy to open that small log-only PR if useful — it's CoreBluetooth-free plumbing and wouldn't change any arm behaviour. Fixing the buzz itself needs on-strap validation, which I can't do here.

  12. ryanbr
    added a commit that references this issue on Jul 10, 2026

    #34: log the raw GET_ALARM_TIME response bytes on a successful readba…

    69de501

  13. 31 remaining items

  14. DX23876
    added a commit that references this issue on Jul 22, 2026

    Merge pull request ryanbr#707 from digitalerdude/fix/34-alarm-hr-diag…

    94a10ed
  15. tanarchytan
    added a commit that references this issue on Jul 24, 2026

    feat(round3): log live HR at alarm arm time for haptic-timing diagnos…

    d12b945
  16. simoncad7
    added 8 commits that reference this issue on Aug 17, 2026

    ryanbr#34: log the raw GET_ALARM_TIME response bytes on a successful …

    3a5168a

    ble: surface unauthorized/off/unsupported Bluetooth instead of a sile…

    d8f026e

    Alarm: defer the re-arm-on-bond call so it doesn't race the connect h…

    a75b08b

    Changelog: 8.7.0 — sync chip, strap-clock warnings, alarm reliability…

    d5b27fb

    Alarm: name the "no alarm stored" readback plainly + log SET_ALARM_TI…

    88cb1d6

    BLE: fix CoreBluetooth state-restoration leaving the link half-initia…

    e160d82

    Alarm: log live HR at arm time, to test a morning/evening hypothesis (r…

    bf786da

    Merge pull request ryanbr#707 from digitalerdude/fix/34-alarm-hr-diag…

    9622950
  17. ryanbr
    added a commit that references this issue on Aug 28, 2026

    alarm: decode the 4.0 GET_ALARM_TIME readback at the offset the firmw…

    eccf107
  18. denismanulov
    added a commit that references this issue on Sep 30, 2026

    ui: Alarms become Health's Full Schedule, opened from the Sleep tab

    4dfc2b6
  19. TrapstarKS
    added 2 commits that reference this issue on Oct 4, 2026

    Add local sleep planner and haptic alarm controls

    57206c6

    Keep alarm skips and shared wake schedules consistent

    cd0e8ad
  20. JohanStefanes
    added a commit that references this issue on Oct 15, 2026

    feat(ble): read back the WHOOP 5/MG strap alarm after arming it

    b6a937d
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