Smart alarm never fires (strap never buzzes at wake time)

[dannymcc]

Summary

The smart / cycle-aligned wake alarm never actually fires — the band does not buzz at the scheduled wake time, even when an alarm is legitimately set.

Steps to reproduce

1. Set a band alarm via the Sleep coach ("Set band alarm for HH:MM").
2. Wait until the scheduled wake time.

Observed

The strap never buzzes; no wake alarm fires.

Expected

The band vibrates at the scheduled wake time.

Notes

Likely in the BLE set-alarm delivery/trigger path (command build → BLE write → strap arming, and time encoding). May be related to the strap confirmation never returning — see #118. Root cause under investigation; opcode/payload to be cross-checked against the OpenStrap protocol library's alarm support.

Screenshots

The Sleep page "Set band alarm" UI is shown in #118; this issue concerns the delivery behaviour rather than the UI.

[dannymcc]

On-device disambiguation on a real band:

• Test buzz (RUN_ALARM) fires, and the Tasker immediate-buzz fires → the BLE write path, connection and haptics are all healthy; the strap can be told to buzz.
• A scheduled alarm set ~2 minutes out never fired.

So delivery is fine; the break is specifically in scheduled arming/firing — the one path that depends on the strap's clock. Top suspect, from two independent end-to-end code traces (arm bytes are byte-identical to the protocol reference; wake-time, lifecycle-clobber, opcode and confirmation-gating all refuted at code level):

The alarm is armed with the raw wall-clock epoch, and the app holds the strap-RTC↔wall offset (_clockRef, ble_engine.dart:1827) but doesn't apply it. If the strap RTC isn't latched (setClock gives up after 3 tries; history sync is immune because records carry their own timestamps), a scheduled alarm fires against the strap's wrong clock → wrong time, or never — while immediate buzz and sync (both clock-independent) work. That matches every observation above.

Fix incoming: arm in the strap's RTC frame using _clockRef (fall back to raw epoch when uncorrelated), plus write-path hardening (allowLongWrite, surface silent write failures) and diagnostic logging (negotiated MTU, ALARM_SET/event-56 arrival, clock drift) so the next on-device test is conclusive.