[Feature Request] Allow deleting individual readings from history

[Albabit]

What I'd like :

A way to open the history for a metric (heart rate, SpO2, etc.), see the individual readings, and delete one or several of them.

Most other apps I've used let you do this. In PulseLoop I couldn't find any way to remove a reading once it's recorded, so a bad measurement stays in the record permanently and drags the trend with it.

Why it matters right now :

It's partly prompted by #59. Every failed heart rate attempt leaves a bogus 46 bpm in my history, and there's no way to clean it up.
That particular cause will go away once #59 is fixed, but the general need won't : a ring worn loosely, a measurement started by mistake, or a reading taken while moving all produce values you'd rather not keep.

Scope :

Deletion only, not editing. Being able to change a recorded value seems like a bad idea for health data, and I'm not asking for it. Just removing an entry, ideally with a confirmation step.

Happy to test whenever.

[foureight84]

I'm going to create a pre-release build for you to test. It also covers the other ticket you opened.

[foureight84]

@Albabit — implemented in PR #62, in the same test build as #59: v2.8.0+41-rc1 (prerelease; the in-app updater won't serve it to anyone else).

Open any vital from the Vitals screen and there's a new READINGS section under the stats: the window's individual measurements, newest first, each with a delete button and a confirmation. Deletion only, as you asked — I agree that editing a recorded health value is a bad idea, and there's no path to it.

You were right that the need stands on its own, and there was a wrinkle that made it more than a DELETE. History readings are keyed history:<kind>:<timestamp> and written as an upsert, deliberately, so that re-syncing a day the ring still holds updates the same row instead of duplicating it. That same property would have undone every deletion: the row goes, then the next sync of that day writes it straight back, with nothing appearing to fail. So a deletion is now remembered — the reading stays gone across later syncs, and the confirmation dialog says so when it applies. Deletions survive a backup/restore round trip too, for the same reason.

Your diagnosis of the cause was also better than you knew. It wasn't one bogus 46 per failed attempt — every intermediate estimate the measurement settled from was being stored as its own reading, stamped with the moment it arrived. So a single failed measurement left a whole train of them. That's fixed independently of #59: a spot measurement's output is one reading now, and the samples it settles from aren't written at all. So even if the #59 fix doesn't fully land on your ring, the mess should stop accumulating.

The specific thing worth testing, beyond "does the button work": delete a reading that came from ring history, then let that same day sync again and check it doesn't come back.

One limit you should know about: if you have Health Connect export enabled, a reading already exported stays in Health Connect. The export doesn't retain the record ids it would need to delete against. Removing it from PulseLoop won't reach it — I'd rather say that plainly than have you discover it later.

[Albabit]

@foureight84 ,
Ran the test you asked for on #60.

With all-day HR back on at a 30 minute interval, the ring produced automatic readings through the afternoon. I picked the oldest one that clearly came from ring history (14:30, 48 bpm), deleted it, then disconnected and reconnected the ring and restarted the app so the day would re-sync.

It stayed gone. No sign of it in the list afterwards.

Everything else from rc1 still holds : spot HR gives plausible values, a deliberately bad attempt fails instead of recording something, and the measurement ends well before the countdown expires.

One observation, probably nothing : the 14:30 and 15:00 automatic readings came in at 48 and 50 bpm, well below anything I get from a spot measurement. Later automatic ones were normal (84, 86, 87), so it isn't systematic and I'm not treating it as a bug. Mentioning it only in case low outliers on automatic readings turn out to be a pattern on YCBT rings.

[foureight84]

@Albabit — that's the exact test I wanted, thank you: deleting a reading the ring had logged, then forcing a re-sync and confirming it stayed gone. That's the half of this that would have failed silently, so having it confirmed on hardware matters more than the button working.

rc2 extends the one-reading-per-measurement rule to SpO₂ as well. It didn't matter much before, because that leg answered after a single sample — but it now collects the whole run (see #59), and your capture streams twelve values over ~50 s. Every one of those would otherwise have landed in your history, which is precisely the pile this issue was about.

On your 48 and 50 bpm — I don't think that's nothing

You called it "probably nothing" and mentioned it anyway, which was the right call. 46–48 is exactly the plateau your original capture caught the ring's PPG sitting on before it converged:

t+14.1s   47 bpm
t+22.1s   46 bpm      <- the plateau
t+26.1s   84 bpm      <- convergence

Your automatic readings come from the ring's own all-day monitoring, which we don't control and can't see into. But if its firmware samples a shorter window than a spot measurement does, it would land on that same pre-converged value — and 48/50 against a real 84–87 is the same gap, in the same direction, on the same ring.

I can't fix the ring's firmware, and I'm not going to start filtering "implausible" readings out of ring history on one observation. But it's worth knowing, because resting heart rate is computed from exactly those low samples — so if the pattern holds, the ring's own lows may be dragging that estimate down. If you notice more automatic readings clustering in the 45–50 range while your spot measurements sit in the 75–85 range, that would be worth its own issue.

Which, incidentally, is now something you can do something about: those are ring-history readings, and deleting them sticks.

[foureight84]

@Albabit — rc3 closes the loop on the doubled readings you flagged from rc1, thanks to your read-back on #59 confirming the ring logs each spot measurement into its own history.

The rule now: our settled reading is stored, and when a later sync imports the ring's own copy of that measurement (same kind, within 90 s of ours), ours yields to it. The ring's row is the one that regenerates on every sync, so it's the one a deletion can hold down — which is why it wins rather than ours. Rings that don't log spot readings never produce such a neighbour, so nothing changes for them.

One more #60 fix underneath: the one-reading-per-measurement rule could be slipped by samples still queued for storage at the moment a measurement finished, if a big history sync was draining at the same time. That path is closed.

To confirm: run a spot HR and a spot SpO₂, then let the day sync (disconnect/reconnect is enough) and check the Readings list shows one row per measurement — and, if you're reading the ring's memory anyway, that the value is the ring's.

[foureight84]

@Albabit — a correction to the rc3 fix, in v2.8.0+45-rc5.

The rule your read-back established — the ring logs its own spot measurement, so our copy yields to the ring's when a sync brings it back — was right for your ring and wrong to apply everywhere. It was running for every family. Colmi and CRP rings record all-day readings on a five-minute grid, where no sample is a copy of a spot measurement, so a spot reading taken within 90 seconds of a grid point would have been deleted in favour of an unrelated one. On a five-minute grid that is most measurements.

It is now decided when the reading is stored, and only for a ring that reports its own measurement completion — which is exactly the property your captures established, since a ring that ends a measurement with 04 0e is one whose vendor app re-reads the value from history. Nothing changes on your ring. Your testing still applies, and the request is unchanged: a spot HR and a spot SpO₂, then a sync, and one row per measurement.

Worth saying plainly: the evidence you gathered was specific to your ring, and generalising it beyond that was mine to get right, not yours.

[foureight84]

@Albabit — rc7 is up (details on #63; it's a sleep-parser fix, nothing here changed).

Whenever you get to it, the app-side checks from rc5 are still open — they were overtaken by the sleep regression and never got a run:

• A spot HR and a spot SpO₂, then a sync, and one row per measurement in the Readings list rather than two.
• If you're reading the ring's memory anyway, that the row that survives is the ring's value.

No rush, and no need to redo the read-backs — those settled it. This is just the app-side half.