WIP: CareLevo driver - #4742
Open
MilosKozak wants to merge 72 commits into
Open
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## dev #4742 +/- ##
============================================
+ Coverage 53.61% 55.49% +1.88%
- Complexity 18763 20496 +1733
============================================
Files 3371 3535 +164
Lines 195765 205531 +9766
Branches 23008 24191 +1183
============================================
+ Hits 104950 114059 +9109
- Misses 83277 83553 +276
- Partials 7538 7919 +381 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
# Conflicts: # app/build.gradle.kts
CareLevo: prioritize Android 13 BLE handling and scan selection
Carelevo Retry additional priming via dedicated BLE session timeout path
|
Match key for upsertAlarm changes from exact (alarmType, cause) to cause.canonicalKey() only, so WARNING/ALERT/NOTICE tiers of the same underlying condition merge into one record instead of appending duplicates, keeping the higher-priority occurrence.
On BLE reconnect, poll the patch's active-alarm snapshot tiers (CRITICAL/ADVISORY/NOTIFICATION via command 0x43) and reconcile them against the locally persisted alarm set. This is a level-triggered poll — unlike the push-alarm path it reports current state each time rather than edges — so the app diffs against a persisted 'previously seen' baseline (via cause) to raise newly-active alarms and clear resolved ones without resurrecting anything the user already acknowledged. readActiveAlarmSnapshots is internally bounded: on timeout it returns an empty list rather than throwing, so an older patch that never answers this (newer-firmware-only) command cannot tear down the held BLE link or disrupt whatever the queue runs next.
…stom dialog Escalate a critical alarm through both the shared AAPS full-screen alarm (uiInteraction.runAlarm) and the persistent notification card, mirroring EOPatch's AlarmManager.showNotification dual-escalation pattern. handleAlarms now posts the top notification for every alarm set (not only non-critical ones), and its 'confirm' action clears the same alarm via AlarmEvent.ClearAlarm regardless of which surface rang. This replaces the previous mutually-exclusive design (custom in-app CarelevoAlarmScreen showing the full-screen alarm only while mounted, global runAlarm only otherwise, gated by alarmHostActive) — that mount-timing race had previously caused a real double-dialog bug. Dropping the custom dialog removes one of the two competing full-screen mechanisms instead of trying to perfectly synchronize them. Dead code cleanup that falls out of this: CarelevoAlarmScreen and its tests, alarmHostActive, CarelevoAlarmHost's buildAlarmUiModel/ buildDescArgsFor helpers, and the now-unused AlarmEvent.Mute/ Mute5min/StartAlarm variants. CarelevoAlarmViewModel is now a thin pass-through of CarelevoAlarmActionHandler's UI-request stream.
PREF_KEY_LAST_SNAPSHOT_ALARM_CAUSES tracks which alarm causes the last active-alarm snapshot reported, globally rather than per patch address. Left untouched on discard, it kept marking a cause the *previous* (now-abandoned) patch already reported as 'already seen', so a freshly re-paired patch reporting that same cause for the first time was silently suppressed by applyActiveAlarmSnapshots's edge-triggered reconciliation. flushPatchInformation() now clears this baseline alongside the cached patch/infusion info it already resets on discard.
…arm mute showTopNotification posted critical alarms at NotificationLevel.URGENT with soundRes set — NotificationManagerImpl's own alarm/sound tier. The shared full-screen alarm's OK button (UiInteraction.stopAlarm -> muteAllAlarms) silences every URGENT+sound notification app-wide on confirm, which wiped the CareLevo card off the screen without the underlying alarm ever being acknowledged or cleared — an unhandled critical alarm could end up invisible with no reliable way back short of backgrounding and re-foregrounding the whole app. Post critical alarms at IMPORTANT with no sound instead, matching eopatch's AlarmManager.showNotification pattern: sound/full-screen escalation stays runAlarm's job alone, so the card itself falls outside muteAllAlarms's filter and survives that confirm until the user genuinely clears the alarm through it.
- CarelevoEmulatorBleTransport: emit a real RSSI on scan results (EMULATED_RSSI=-30) instead of leaving it at Int.MIN_VALUE, which was silently failing CarelevoPatchConnectViewModel's RSSI filter. - CarelevoPumpEmulator: implement the 0x43 active-alarm-snapshot responder (critical/advisory/notification tiers) and wire alarmClear() to actually clear the matching tier's flag instead of no-op'ing. - CarelevoPumpState: track per-tier alarm flags (critical/advisory/ notification) instead of a single shared set. - Config/CarelevoModules: four new debug-only ExternalOptions marker files (emulate_carelevo_low_battery[_alert], _occlusion, _invalid_temperature) that seed the emulator's alarm flags on launch, so each alarm scenario can be reproduced on demand without real hardware. - Emulator tests updated to cover the new snapshot/clear behavior.
|
One request now fires three priming pulses, since only the user can see whether a droplet appeared. The next request raises the self-diagnosis alarm, which discards the patch.
Carelevo: activation flow usability and fixes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.