[Part 2 of 3] fix: disable redundant glucose smoothing - #43
Conversation
There was a problem hiding this comment.
Pull request overview
Removes the plugin’s redundant 5-point moving-average smoothing on trend glucose values (to avoid extra lag when the host app already smooths), and continues the ongoing migration away from legacy in-plugin notification/alarm UI toward LoopKit-native sensor lifecycle status + alerting.
Changes:
- Remove trend glucose smoothing (
CalculateSmothedData5Points) and delete the smoothing implementation file. - Delete legacy notification + alarm settings/snooze UI (and
NotificationHelper), shifting lifecycle alerting to LoopKit’sAlertframework. - Add a unified
LibreSensorLifecyclemodel and surface lifecycle status viaCGMManagerUI(highlight/badge/progress), plus lifecycle alert diffing/issuance.
Reviewed changes
Copilot reviewed 28 out of 29 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| readme.md | Removes documentation claim that glucose values are smoothed. |
| LibreTransmitterUI/Views/Setup/Libre2DirectSetup.swift | Removes calibration/setup notifications. |
| LibreTransmitterUI/Views/Setup/BluetoothSelection.swift | Stops requesting notification permissions during Bluetooth selection init. |
| LibreTransmitterUI/Views/Settings/SnoozeView.swift | Deletes snooze UI view. |
| LibreTransmitterUI/Views/Settings/SettingsView.swift | Removes alarm/snooze/notification settings navigation and related state. |
| LibreTransmitterUI/Views/Settings/NotificationSettingsView.swift | Deletes legacy notification settings UI. |
| LibreTransmitterUI/Views/Settings/AlarmSettings/CustomDataPickerView.swift | Deletes alarm schedule time-range picker UI. |
| LibreTransmitterUI/Views/Settings/AlarmSettings/CriticalAlarmsVolumeView.swift | Deletes critical alarm volume UI. |
| LibreTransmitterUI/Views/Settings/AlarmSettings/AlarmSettingsView.swift | Deletes alarm schedule settings UI. |
| LibreTransmitterUI/LibreTransmitterManager+UI.swift | Adds LoopKit CGMManagerUI lifecycle badge/highlight/progress mapping. |
| LibreTransmitter/Observables/AlarmStatus.swift | Deletes observable used by legacy glucose alarm UI. |
| LibreTransmitter/NotificationHelperOverride.swift | Deletes critical-alert override toggle file. |
| LibreTransmitter/NotificationHelper.swift | Deletes legacy local-notification implementation. |
| LibreTransmitter/LibreTransmitterManagerV3.swift | Tracks latest reading timestamp/faults, reports lastCommunicationDate, and evaluates lifecycle alerts. |
| LibreTransmitter/LibreTransmitterManager+Transmitters.swift | Removes notification side-effects; records lifecycle faults and sensor state instead. |
| LibreTransmitter/LibreTransmitterManager+Libre2EU.swift | Removes sensor-expiry notifications for direct Libre2 BLE path. |
| LibreTransmitter/LibreGlucose.swift | Removes 5-point smoothing and uses calibrated value directly as glucoseDouble. |
| LibreTransmitter/Alerting/LibreTransmitterManagerV3+Alerts.swift | Adds LoopKit Alert diff/issue/retract logic for lifecycle conditions. |
| LibreTransmitter/Alerting/LibreSensorLifecycle.swift | Introduces unified lifecycle state computation across data paths. |
| LibreTransmitter/Alerting/LibreAlertCondition.swift | Defines lifecycle alert conditions and maps them to LoopKit Alerts. |
| LibreTransmitter/.gitignore | Removes ignore of NotificationHelperOverride.swift (file removed). |
| LibreTransmitter.xcodeproj/project.pbxproj | Removes deleted sources and adds new Alerting sources/groups. |
| LibreSensor/GlucoseAlgorithm/GlucoseSmoothing.swift | Deletes the 5-point smoothing implementation. |
| Features.swift | Removes vibration feature flag tied to legacy glucose alarm behavior. |
| Common/Settings/UserDefaults+Bluetooth.swift | Adds dangerModeActivated and a shared optionalBool(forKey:) helper. |
| Common/Settings/UserDefaults+Alarmsettings.swift | Deletes legacy alarm/notification UserDefaults and schedules persistence. |
| Common/Settings/GlucoseSchedules.swift | Deletes legacy glucose schedule model/validation and snooze logic. |
| build.md | Removes legacy build instructions for vibration + critical alerts; keeps core build steps. |
| .gitignore | Removes ignore entry for NotificationHelperOverride.swift. |
Suppressed comments (1)
LibreTransmitterUI/LibreTransmitterManager+UI.swift:132
- The
.expiredstatus highlight is returned with state.normalCGM, but the same condition is treated as.criticalincgmStatusBadgeandcgmLifecycleProgress. This inconsistency will likely under-emphasize an expired sensor in the UI.
case .expired:
return LibreStatusHighlight(localizedMessage: LocalizedString("Sensor\nExpired", comment: "Status highlight message for expired sensor"), imageName: "clock", state: .normalCGM)
case .signalLost:
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
b9d6929 to
3e22e16
Compare
Trio already applies its own smoothing to incoming glucose values, so the 5-point boxcar moving-average filter (CalculateSmothedData5Points) previously run on every trend reading here only added extra lag on top of Trio's own smoothing, with no benefit. Remove the filter and the now-dead GlucoseSmoothing.swift entirely.
3e22e16 to
7fb1f84
Compare
|
glucosesmoothing should per default be left intact for Loop. There is a new option to turn it off in the gui settings now in next-dev. Conditionally disabling this gui setting (and setting to false) based on a build flag is how this should be overridden |
The responsibility of smoothing readings should be up to the caller. In the case of Trio, for example, the app already handles this itself. The 5-point boxcar moving-average filter (
CalculateSmothedData5Points) previously run on every trend reading here only added extra lag on top of Trio's own smoothing, with no benefit.This PR removes the filter and the now-dead
GlucoseSmoothing.swiftentirely.Part 2 of 3 related PRs. Built on top of #42 in my fork, so this diff will include #42's changes until that one merges and this gets rebased.