_entries_since/_treatments_since requested a single page via `count`,
but Nightscout's /api/v1/entries and /api/v1/treatments ignore a large
`count` and cap the response around ~1150/~700 documents regardless of
how far back the requested period goes. Every report page relying on
fetch_entries_range/fetch_treatments_range (7/14/30/90-day selectors)
was silently only getting the most recent ~3-4 days, no matter the
selected period.
Fixed by paginating with `find[date][$lte]` cursors in a new
_paginated_get(), walking back until the requested `since` boundary is
reached or the server returns a short/empty page (= genuinely no more
data, confirmed by manually paginating against the real instance:
entries go back 50+ days, treatments only ~4 days on this install).
Also added reporting.completeness_warning(), shared by the interactive
pages (via ui_common.render_completeness_warning) and the PDF export,
that distinguishes "a structural gap at the start of the period" (data
wasn't fetched/available) from "scattered gaps below the clinical AGP
coverage threshold" (Danne et al. 2017) — the previous single generic
"X% sensor coverage" message read as a CGM/sensor problem even when
the real cause was this fetch bug.
pdf_export.py builds a PDF report (summary stats, AGP chart, hypo/hyper
event summaries) via fpdf2 + matplotlib rather than plotly's kaleido, to
avoid bundling a Chromium build into the image just for this. The Export
page lets the user pick which sections to include and a date range, then
download the result to send to the hospital team.
This completes all ten functional requirements in
docs/requirements-reporting.md.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
reporting.py gains overnight_daytime_split, day_of_week_pattern,
bolus_stats, and site_interval_stats. The last two are explicitly scoped
to bolus-only insulin (no basal reconstruction) since that needs the
Nightscout profile, which is the separate profile-tuning feature's
territory — documented as a caveat in both the UI and the design doc.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Dagoverzicht stacks one glucose trace per calendar day (small multiples
via a shared 0-24h x-axis). The two event pages share a new
render_event_level() helper in ui_common.py so Level 1/Level 2 hypo and
hyper are rendered identically: count/avg/longest/events-per-week
metrics, a time-of-day histogram, and a table of individual events.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Wires reporting.py's stats into two new pages: a summary panel (data
completeness, GMI, %CV, 5-band time-in-range vs. consensus targets) and
the standard AGP percentile chart (5th-95th and 25th-75th bands plus
median, aggregated by time-of-day across the selected period).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
First increment of the clinical reporting feature (see
docs/requirements-reporting.md and docs/design-reporting.md): moves the
existing live view to pages/1_Live.py, adds a password gate since the
dashboard URL will be shared with the diabetes team, adds
fetch_entries_range/fetch_treatments_range for multi-day report queries,
and adds reporting.py with the core clinical calculations (GMI, %CV,
5-band time-in-range, hypo/hyper event detection per the Battelino et al.
2019 persistence rule). No report pages wired up yet — that's next.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
willemjan
