Repository navigation
Smart alarm: phone backup follows the alarm, not the wrist-alerts master (#34) - #73
Merged
Merged
Conversation
…ter (#34) The smart-alarm phone backup notification was gated on the wrist-alerts master (notif.masterEnabled) — the same switch that governs HR/strain alerts — even though its only caller (applySmartAlarm) already runs solely when the alarm is enabled. So a user who set a smart alarm but never turned on the unrelated wrist alerts got NO backup scheduled: when the strap can't arm (e.g. a corrupted alarm register, #34), they were left with nothing. - Gate the backup on the alarm being enabled + notification permission, not the wrist-alerts master. - When permission is undetermined (nothing else prompted, since wrist alerts — which used to — may be off), request it here and schedule on grant so the first night is covered, not only after a later re-arm. Not a fix for #34's corrupted strap (that's firmware-side) — a general robustness fix so an unarmable strap still leaves a phone backup. Honest limitation unchanged: a sideloaded build has no critical-alert entitlement, so Focus/silent can still mute it; the phone Clock alarm remains the real backup (UI already says so).
DX23876
pushed a commit
to DX23876/noop
that referenced
this pull request
Jul 22, 2026
Smart alarm: phone backup follows the alarm, not the wrist-alerts master (#34)
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
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.
Adjacent to #34 (alarm not buzzing). Not a fix for that user's corrupted strap — the strap's alarm register is frozen firmware-side and NOOP can't force it over BLE. This closes a general robustness gap it exposed: when the strap can't arm, an affected user should at least get the phone backup — but many weren't.
The gap
scheduleSmartAlarmBackupNotificationis called from exactly one place —applySmartAlarm(), which already only runs whenbehavior.smartAlarmEnabled. Yet the backup was gated a second time onnotif.masterEnabled(the wrist-alerts master — the switch for HR/strain alerts, inactivity, illness). So a user who set a smart alarm but never turned on wrist alerts got no backup scheduled at all ("backup notification NOT scheduled (wrist-alerts master is off)"). The backup was riding the wrong switch.Change (iOS-only, one function, no BLE)
notif.masterEnabledguard.addRequests()so the already-authorized and just-granted paths schedule identically.Re-review notes (flagging, not bugs)
applySmartAlarmrather than at a tap. iOS dedupes it to once; a tap-triggered prompt would need a "user-initiated" flag (not minimal).Honesty (unchanged)
Even scheduled, the backup is a plain notification — a sideloaded build has no critical-alert entitlement, so Focus/silent can mute it. The phone Clock alarm remains the real backup (
SmartAlarmViewalready says so). WSL can't build SwiftUI; verified by inspection + the auth-state reasoning above — needs a device to confirm the prompt + fire.File:
Strand/App/AppModel.swift.