Only one sleep session per night is shown when the ring records several

[Albabit]

On a YCBT ring (Ale-Hop2211 E1C7, ColmiSmartHealthCoordinator), PulseLoop showed 4 h 06 of sleep for last night, 03:21 to 07:27. I went to bed around 23:30, so I read the ring's history directly with my Python client to see what it actually holds.

The ring recorded two sessions for that night :

SESSION 09-04 00:12 -> 03:18   declared 172 min
   light 2h04   deep 0h12   REM 0h46   awake 0h01
SESSION 09-04 03:21 -> 07:24   declared 196 min
   light 1h59   deep 1h05   REM 0h47

PulseLoop displayed only the second one. The first, three hours of it, isn't shown anywhere in the app. Combined they come to 368 minutes, so the night was about 6 h 08, not 4 h 06.

Why the ring splits a night :

I got up briefly during the night. The gap between the two sessions is three minutes (03:18 to 03:21), which fits. So this isn't a malfunction, it's the ring closing a session when it detects you're up and opening a new one when you settle again.

It isn't systematic either. Two nights earlier the same ring recorded a single unbroken session :

SESSION 09-02 23:57 -> 07:31   declared 356 min

So whatever picks a session works fine on nights with one, and silently drops the rest on nights with more.

Record layout, in case it's useful :

Sleep comes back as 05 13. Each session starts with an af fa header carrying declared minutes and the start and end timestamps, followed by 8-byte entries :

[stage(1)] [start(4)] [duration_seconds(3)]

Stages are 0xF1 deep, 0xF2 light, 0xF3 REM, 0xF4 awake. I validated that mapping against the vendor app's own display on an earlier night : it reported 1 h 27 deep, 4 h 18 light, 1 h 23 REM, matching my decode of the same night to the minute.

Worth noting the vendor app handles the multi-session case : it lists each session separately under "history record" and shows a combined total for the night.

What I'd expect :

All sessions for a night aggregated, with the total reflecting time actually asleep. Showing them separately as well would be a bonus, since a nocturnal wake is itself information, but the total is the part that's wrong today.

Happy to pull raw dumps of any night you'd like to see, or to test a build.

[foureight84]

@Albabit — found it, and it's in v2.8.0+44-rc4 (prerelease, same branch as rc3; install over it).

Your read of the ring was right on every count: two af fa records, and the parser here does already handle several in one reply. The sessions were both decoded and both stored. What went wrong was one step later.

What actually happened to your first three hours

Sleep from one night is merged into a single stored session when the gap between records is short (three minutes is well inside the threshold), so after the first sync you had one 00:12–07:24 row built from both records. That part was fine. The bug was the rule for what a complete ring record is allowed to replace: it treated the record as authoritative for every block of every stored row it overlapped. On the next sync the ring re-sent both records, the second one overlapped the merged row, and so it wiped the whole row's blocks — your first session included — and rebuilt from itself alone. Hence exactly 03:21–07:24 = 4 h 06, and a night with one record was never affected.

A complete record is now authoritative only for the contiguous stretch of stored sleep its own interval sits in. A shortened re-send of the same session still retires its stale tail, because that abuts the new interval; a neighbouring session on the far side of any gap, even a minute, is untouched. That matches the vendor app, which keeps each af fa record as its own row and never lets one displace another. The parser also resynchronises on each record's af fa header now, so a wrong declared length can't silently swallow the sessions after it.

What you'll see: one session for the night, spanning both records, with the total at the combined figure. The nocturnal wake shows up as the awake stretch inside it rather than as a second row. Showing the two records separately as well is a fair ask and I'd take it as its own issue.

What would confirm it

After a night where you get up once: the total after the morning sync, then again after a later sync the same day — it should hold rather than drop to the last session. Your ring read-back is the ground truth; if the app's total and the sum of the ring's declared minutes disagree by more than the wake gap, that's worth a dump.

[Albabit]

@foureight84 ,
rc5 tested. The sleep merge holds, dedup holds, and both legs stop when the ring says so.

Sleep : the ring split last night into two sessions again, 23:51 to 05:02 and 05:11 to 08:02, nine minutes apart. The app shows one session, 11:51 PM to 8:02 AM. I re-synced three hours later and nothing changed. The original failure is gone.

Dedup : six HR rows today for six measurements, two spot and four hourly. No pairs.

Timing : the countdown starts at 123 s. HR appeared with 85 s left, so 38 s into a 48 s leg. SpO2 appeared just before the end, consistent with 04 0e at about 63 s into the 75 s leg. Neither runs out its window.

One number I can't judge : the app reports 8 h 10, which is the span from the start of the first record to the end of the second. The ring's session headers declare 268 and 140 minutes, so 6 h 48. That's 83 minutes apart, well over the nine minute gap.

I'm not going to argue for either. My own stage parser is incomplete, it sums to less than both figures, so it's clearly dropping entries. The declared minutes in the headers are the part I read reliably. For what it's worth, on Aug 30 the vendor app showed 7 h 08 for a night spanning 7 h 21, so it looks closer to the declared sum than the span. One night, and I haven't read its code for this, so take it as a hint.

Happy to dump a night's raw 05 13 records if you'd rather work from those than from my parse.

On #59 : SpO2 matched the ring exactly, 98 both sides. HR didn't, app 94 against the ring's 93, which is what you'd expect while HR still settles on the tail.

One last thing. I've been sending you findings for a couple of weeks now and you've done all the work of turning them into code.
If any of this would be easier as a PR from me, say the word and I'll take one. I have the hardware to test on. Equally happy to keep doing it this way if that's less friction for you, since you know the codebase and I don't.

[Albabit]

@foureight84 ,
Went and read the vendor app's code rather than leave that number hanging. It answers it.

SleepActivity builds each history entry as :

new SleepHisListBean(sleep.getStartTime(), sleep.getEndTime(),
    sleep.getDeepSleepTotal() + sleep.getLightSleepTotal() + sleep.getRemTotal(),
    ...)

So the duration is deep + light + REM, with awake excluded. Not the span.

When a day holds several sessions it accumulates each stage across all of them, and separately takes startTime from the first record and endTime from the last :

int i13 = i2 + deepSleepTotal;
int i14 = i3 + lightSleepTotal;
int i15 = i4 + remTotal;
...
if (i12 == 0 || startTime == 0) startTime = sleep.getStartTime();
if (i12 == this.mSleepDb.size() - 1 || endTime == 0) endTime = sleep.getEndTime();

So it shows the span as a range and the summed stages as the duration, and never conflates the two. That fits the Aug 30 night I mentioned : 7 h 08 displayed against a 7 h 21 span.

Which means my 8 h 10 is the span rather than time asleep. The nine minute gap between my two sessions plus whatever awake time sits inside them should come off it.

Two other things in that loop you may want :

• Sessions are skipped once the running total passes 57600 seconds, so 16 hours acts as a sanity ceiling.
• There's a start-hour filter that drops records depending on whether they begin before noon or after 20:00, which looks like how it decides which day a night belongs to.

I'm not attached to matching the vendor here, it's your call whether span or time-asleep is the better headline. Just seemed worth having the answer rather than my guess.

[foureight84]

@Albabit — yes, please feel free to open a PR. You have the hardware and you've been reading both the ring and the vendor code more carefully than anyone; the codebase side is the easy half to pick up. Branch off main, and AGENTS.md at the repo root carries most of what you'd need to know about the measure and sleep paths. I'll review promptly.

Both of your findings from the rc5 pass are now on the branch (fix/issues-58-59-60, to ship as rc6):

• Sleep duration is time asleep. totalMinutes is now every stage except awake, and the start-to-end range stays as the separate line under it — exactly the split you found in SleepActivity:695, which I confirmed against the decompile. On your night that makes the headline the 6 h 48 the records declared rather than the 8 h 10 span. Stored nights get restated once from their own blocks on first launch, since a re-sync only reaches back a week.
• HR settles on the last plausible sample on your family, vendor band 40–220, so it should now match the ring's stored value the way SpO₂ does. Your three read-backs are the regression tests. The tail rule stays for rings that never signal completion, since nothing chose their last sample.

Your point that the ring stops mid-climb is noted in the code and in AGENTS.md as not ours to correct. Showing the two records of a split night separately is #68.

[foureight84]

@Albabit — v2.8.0+46-rc6 (prerelease; install the universal APK over rc5). Both of your findings are in it:

• Sleep duration is time asleep, awake excluded, with the start-to-end range as the separate line under it. Your night should read the 6 h 48 the records declared rather than the 8 h 10 span, and stored nights are restated once on first launch. The hypnogram axis still runs on the clock.
• HR settles on the last plausible sample on your family, so it should now match the ring's stored value the way SpO₂ does.

What would confirm it: the sleep headline against the sum of the ring's declared minutes, after the morning sync and again after a later one; and a spot HR read back against the ring's memory, as you did for the three captures. One row per measurement after a sync still applies.

A review pass on the branch also fixed something your setup can reach: a run that hit the app's ceiling without the ring's 04 0e was being stored as the ring's own and could be deleted by the next sync. If a measurement ever times out rather than ending on the ring's signal, it should now survive a sync.

[Albabit]

@foureight84 ,

rc6 installed. Sleep merge broke on last night, but not on the older ones, so it looks narrow.

Last night the ring holds two sessions :

09-09 00:35 -> 05:57   declared 244 min
09-09 05:58 -> 08:29   declared 164 min

The app shows only the second : 2 h 32, 5:58 AM to 8:30 AM. The first one isn't anywhere.

Older nights still merge correctly. Sept 8 shows one session 11:51 PM to 8:02 AM against two records nine minutes apart. Sept 6 shows 2:51 AM to 9:03 AM at 5 h 51, and the ring holds three records there with gaps of 20 and 3 minutes. So merging still works, including three-way.

The only structural difference I can see on last night is the gap : one minute between 05:57 and 05:58, against 9 minutes on Sept 8 and 20 and 3 on Sept 6. If something now treats near-adjacent records differently, that would fit.

Separately, on the duration change. You said my night should read the 6 h 48 the records declared. Sept 8 now reads 8 h 03, down from 8 h 10 in rc5, so it moved but not to 6 h 48. The declared minutes in that night's two session headers are 268 and 140, so 408 minutes. 8 h 03 is 483.

So the per-session declared minutes in the af fa header and the sum of the stage entries aren't the same number on this ring, and it looks like you're summing stages while I was quoting the header. I don't know which one the vendor's deepSleepTotal and friends are built from, and my own stage parser is the unreliable one here, so I'd rather flag the discrepancy than tell you which is right. Sept 6 is a cleaner case if it helps : declared minutes sum to 372, the span is also 372, and the app shows 351.

Happy to dump the raw 05 13 blocks for any of these nights if you want to work from the bytes rather than from either of our parses.

[foureight84]

@Albabit — yes please to the raw 05 13 blocks, and thank you for flagging the discrepancy rather than picking a side. Reading the two things you reported together, I think they're one bug and it's in our parser, not in the merge rule.

Where the night went. Our sleep parser concatenates a record's stage segments from the session start — it reads each segment's own start timestamp only to de-duplicate, then appends round(seconds / 60) minutes of that stage, floored at one minute, and lets the next segment follow immediately. So the run we store ends at start + total stage minutes, which is only the record's real end if the segments happen to tile it perfectly. Where they don't, our end drifts later than the ring's.

The retirement rule added in rc4 grows its run across blocks that abut end-to-start exactly. So a first record whose stored end drifts from 05:57 to 05:58 stops being "a session on the far side of a one-minute gap" and becomes "the block immediately before this one" — the run swallows it, and the interval replace puts back only the second record. Five hours and twenty-two minutes, gone. Your Sept 8 and Sept 6 nights have nine and twenty minutes of slack to absorb the same drift, which is why they still merge.

And the duration. I think this is the same drift rather than a header-versus-stages definition dispute. Sept 8 reads 483 minutes asleep inside a 491-minute span — eight minutes awake across a whole night isn't credible, and 483 against the headers' 268 + 140 is about 75 minutes of overshoot. That's the concatenation running long, not a disagreement about whether the declared minutes include REM.

Sept 6 is the case that fits my explanation least well: declared minutes sum to 372, the span is 372, and we show 351. It should be the clean one and it isn't quite, which is exactly why I'd rather work from the bytes than from either of our parses.

What would help, in order of usefulness:

1. The raw 05 13 payloads for the night of Sept 9 — both records. This is the one that broke, so it's the one that proves or kills the drift theory outright: if the first record's segment durations sum past 05:57, that's the whole bug.
2. Sept 6, both or all three records — the case my explanation doesn't cover.
3. Sept 8 if it's no extra trouble.

Whole payloads as hex, please, af fa header included and nothing stripped — the per-segment start timestamps are the part I need and they're what both of our parsers are currently discarding or assuming. If your capture tooling gives them to you already framed per record, that framing is worth keeping; if it's one undifferentiated stream for the night, that's fine too, the magic is findable.

No need to re-run anything or reproduce it — whatever you already have from those nights is enough. If Sept 9's records have already been overwritten by a later sync, say so and I'll work from Sept 6 and 8.

One thing I'm not asking you to do: don't try to reconcile it against your own stage parser first. You've been clear that it's the unreliable one here, and the bytes are the thing both of us can check against.

[foureight84]

@Albabit — v2.8.0+47-rc7 (prerelease, install the universal APK over rc6). Your one-minute-gap observation was the right thread to pull, and it led somewhere I didn't expect: the gap isn't what broke, our parser is, and it's been wrong since long before rc6.

What I found. A sleep record carries its own bounds in its 20-byte header — the vendor SDK reads startTime at +4 and endTime at +8 — and every stage segment carries its own start time. We read neither. Segment timestamps were used to de-duplicate and then thrown away, and the timeline was built by concatenating round(seconds / 60) minutes per segment from the first segment's start.

That drifts, and I could measure it without your bytes because there's a real captured night in our test fixtures:

	minutes
header span (endTime − startTime)	474
header totals (deep 5627 s + light 14963 s + rem 7831 s)	473.7
what we actually stored	470

Four minutes off on a night with no wake at all. Two causes, both visible in the bytes: the ring leaves a one-second gap between every consecutive segment — 49 of them in that record — and each segment rounds to whole minutes independently against a one-minute floor. Which way the total lands is just arithmetic on that night's segments. Short there. Long on yours.

Why one minute of that costs five hours. The rc4 merge rule grows its retirement run across blocks that abut end-to-start exactly. A first record whose stored end drifts from 05:57 to 05:58 stops being a session on the far side of a one-minute gap and becomes the block immediately before the second — the run swallows it, and the replace puts back only the second record. Your Sept 8 and Sept 6 nights had nine and twenty minutes of slack to absorb the same drift, which is exactly why they still merged. So: narrow symptom, but not a narrow bug, and you were right that the gap was the discriminating variable.

The fix places each segment at its own start time for its own declared length, across a run spanning exactly the header's bounds. Minutes no segment claims read as awake, which is honest — the ring reports wake as its own segment type. On that captured night it now decodes to 94/251/129 deep/light/rem against the 93/249/130 the vendor app shows: the timeline itself is unchanged, only its endpoints are now the ring's rather than our arithmetic's.

I left the merge rule alone. It's defensible once its input is accurate, and loosening it would have hidden this instead of fixing it.

What would confirm it

• Last night's split — both sessions present, the 00:35 one back.
• Sept 8 and Sept 6 — that they still merge as they did, one session each. This change touches every sleep record, not just split ones, so the nights that were already right are the ones I most want to hear about.
• Any night where the sleep card now looks different from rc6, even if it looks more plausible. Different is the signal here.

On the duration, still unresolved

The header carries deepSleepTotal, lightSleepTotal, rapidEyeMovementTotal and wakeDuration as separate fields — and when the deep-sleep count reads 0xffff those totals are in seconds rather than minutes, which is the kind of thing that produces exactly the sort of mismatch you flagged. So there's a declared time-asleep in the record that we currently ignore in favour of counting our own stage array.

rc7 should narrow the gap, because the stage array is now accurate. I don't expect it to close it on Sept 8. Rather than guess which field your "declared 268 and 140" came from, I'd still like the raw 05 13 payloads — the ask on that is unchanged and it's the last open question on this issue.