Smart alarm: instrument + warn when the strap keeps refusing the alarm (#34)#75
Merged
Conversation
…m time (#34) When a strap's clock/alarm register is corrupted it silently rejects SET_ALARM_TIME — the readback keeps reporting an old time — and the firmware alarm never fires. Today that mismatch is detectable only in the debug export, and only as a one-shot. Instrumentation (#2 — observability only, no BLE command change): - FrameRouter: on each GET_ALARM_TIME readback, count CONSECUTIVE rejections (reported != last sent). A matching readback resets the streak, so a transient (first read stale, then correct) never trips it; only a persistent refusal climbs. - recordAlarmArm: persist the strap-clock skew AT ARM. Skew ~0 while the strap still rejects ⇒ a corrupted alarm register, not a clock problem — pins whether a re-clock could ever help. - Debug export Alarm block surfaces both (clock-at-arm on Last arm; "N in a row" on Strap reports). - disableStrapAlarm clears the streak (nothing armed to refuse once disarmed). User warning (#4): - SmartAlarmView shows a card, ONLY when the alarm is on and the strap has refused >=2 arms in a row, telling the user the strap isn't accepting the alarm and to reset it via the official WHOOP app / keep a phone Clock alarm. Driven by @AppStorage so it appears/clears live. Not a fix for a corrupted strap (that's firmware-side, #34) — it turns a silent, export-only failure into a persistent signal and actionable on-device guidance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The diagnosis path for #34 (alarm not buzzing). A strap whose clock/alarm register has reset silently rejects
SET_ALARM_TIME— theGET_ALARM_TIMEreadback keeps returning an old value (andresbernalc's stayed at a 2021 epoch across six writes) — so the firmware alarm never fires. Until now that mismatch was visible only in the debug export, and only as a one-shot. This makes it a persistent signal and surfaces it to the user.No BLE command changes — pure observability + one conditional UI card.
#2 — instrumentation
Last armline,N in a rowonStrap reports.#4 — user warning
SmartAlarmViewshows a card only when the alarm is on and the strap has refused ≥2 arms in a row: "Your strap isn't accepting the alarm… reset it in the official WHOOP app, keep your phone's Clock alarm meanwhile." Driven by@AppStorage("alarm.rejectStreak")so it appears and clears live.Scope / honesty
Not a fix for a corrupted strap — that's firmware-side, only a strap reset clears it. This turns a silent, export-only failure into on-device guidance the affected user can act on. SwiftUI/BLE can't build on WSL; verified by inspection + streak/skew reasoning — needs a device to confirm the card + export lines.
Files:
Strand/BLE/FrameRouter.swift,Strand/BLE/BLEManager.swift,Strand/System/DebugDataDiagnostics.swift,Strand/Screens/SmartAlarmView.swift.