Split off from #58, where it came up as a follow-up.
The R100 answers neither the stress history query (2/47) nor the stress monitor-state read-back (2/45) — 22 sends, 0 replies, across 22 sync passes — while every other state query on that ring answered (2/6 heart rate, 2/7 HRV, 2/8 blood oxygen all returned 05, 2/21 temperature returned 06). On that ring stress is absent, not switched off.
The app still advertises STRESS for it, because CRPCoordinator.capabilities is a static per-family set rather than something an individual ring confirmed. So the user sees a stress card that can never fill.
Two things to decide, and they are separable:
- Don't advertise what a ring doesn't have. A capability list is not evidence about an individual ring. Some form of confirmed-capability tracking would stop an empty card looking like a sync bug. This is the smaller and safer half.
- Derive a stress figure from HRV app-side for those rings. HRV history decodes well on the R100 (30 frames with data out of 84). A derived number must be labelled as derived — it is not what the ring measured, and presenting it as one would be worse than an empty card.
Reported by @scufitarosie, whose diagnostics export is the evidence above.
Split off from #58, where it came up as a follow-up.
The R100 answers neither the stress history query (
2/47) nor the stress monitor-state read-back (2/45) — 22 sends, 0 replies, across 22 sync passes — while every other state query on that ring answered (2/6heart rate,2/7HRV,2/8blood oxygen all returned05,2/21temperature returned06). On that ring stress is absent, not switched off.The app still advertises
STRESSfor it, becauseCRPCoordinator.capabilitiesis a static per-family set rather than something an individual ring confirmed. So the user sees a stress card that can never fill.Two things to decide, and they are separable:
Reported by @scufitarosie, whose diagnostics export is the evidence above.