Afrezza patch for logging external afrezza in real time #324
Comments
|
This is a tough one because oref is only designed to use a single insulin model. I think Loop 3 rewrote a lot of code so an insulin model is attached to every insulin dose. Since I think it’ll take a long while before that’s implemented, to keep TDD accurate, I think an easier (but not as good) solution might be automating it so entering a dose of Afrezza into Trio would wait your DIA time before entering the equivalent dose at the time it was taken. |
|
@cwrussellgithub , I think just predating the dose as you did is probably a quite good way to handle it for now. We will soon have support for iOS shortcuts in Trio, so then you could easily create a specific shortcut for afreezza that sets the time 30 minutes or so before the time of entry. Wel, there is no specific shortcut or adding external insulin planned just yet, but it should be possible to add this. Perhaps you will remember to write a specific feature request for that when shortcuts are available? Tagging @avouspierre for a hint about this 😊 |
|
I don't think pre-dating the Afrezza dose by 30 mins works well. I put together a graph using Rapid-acting (360 DIA, 75 peak). Red is normal and blue is pre-dating by 30 minutes. I think this makes way too much IOB remain around for far too long which could cause Trio to under dose after the Afrezza has actually cleared your system in an hour or two. 
For reference, Loop uses 300 DIA and 29 peak for Afrezza: |
|
Yes I imagine it is not ideal, but perhaps it would work better with a much longer predate? I guess there are not too many other options right now. |
|
Thank you both for your input and feedback. Can you dispel my ignorance: If I put in a longer/larger predate, such as 1 hour before I inhale, would there be any risk/complications from the algorithm not “detecting” any insulin (BG impact) for another 15-30 min, thus “1hr 15-30min ‘after bolus’”? -Or would the nature of the oref algorithm nullify such concerns? @MikePlante1, Am I interpreting the the idea of “automating it so entering a dose of Afrezza into Trio would wait your DIA time before entering the equivalent dose at the time it was taken.” as a potential programming/patch development idea for the possible, distant future, or is that something that I could try to do now? |
|
I don't think there is much risk in predating something like an hour. The COB/meal history might be impacted, but not so much IOB. With one hour predate, the algorithm would expect the peak effect right now, but the tail of the insulin model would still be longer than the actual Afrezza effect. I think Mike just suggested that you simply don't enter anything until DIA hours later (6 or more hours), so that there is no insuling effect from the model when you enter it. You could probably make a shortcut for this once there is a possibility of entering external insulin this way. |
…ghtscout#324) * Update bundle with various improvements and new functionality including Silence Pod mode & Diagnostics support from freeaps_dev to SwiftUI Various fault event code updates + Add missing 0x4E code and description for SAW Trim Error + Fix typo in rtcInterruptHandlerInconsistentState string + Improved description string for the testInProgress fault + Use more generic name for the values do not match case + Add codes for the 0xD6 & 0xD7 reset faults of unknown origin + Add codes for the mystery 0xCB, 0xD4, 0xD5, 0xD8 & 0xD9 faults Various Omnipod message decode improvements + Round RateEntry rate calculation to 2 digits + Round RateEntry duration calculation to nearest second + Add missing comma to RateEntry debugDescription + New timeIntervalStr TimeInterval var for pod interval debug info + Update some command commenting to be more consistent and useful + Add debugDescription for CancelDeliveryCommand DeliveryType + Add additional PodInfoTest checking and comments + Whitespace tweaks for OmniKit & OmniBLE consistency Remove some overly verbose OmniBLE Bluetooth logging messages + Add {public} specifier to some non-debug logging messages New operation mode that suppresses all pod alerts & beeping + New CustomDebugStringConvertible extension for AlertTrigger + Add new optional silent Bool parameter to AlertConfiguration struct + Updated CustomDebugStringConvertible extension for AlertConfiguration + Add new optional silent Bool associated value for most PodAlert enum values + Add new offset TimeInterval associated value for time based PodAlert enum values + Updated AlertSlot naming to make slot to alert mappings consistent + Use consistent ascending alert ordering for all switch statements + New alertSetString func to return suitable String for a given AlertSet + New func to create corresponding PodAlerts for current pod time and silent values + Add new silent Bool to ConfigureAlertsCommand struct + Sort alert configurations in ConfigureAlertsCommand for easier analysis + Have ConfigureAlertsCommand enforce the max alert duration value + Rework pump manager code to use new silencePod var + Use { } instead of ({ }) for {set,modify}State for consistency & clarity + Add timeActive var to pump manager for more accurate pod active time + Have acknowlegePodAlerts() use AlertSet instead of [AlertSlot: PodAlert] + New setSilencePod pump manager func to change the pod's silence state + Add some additional pump manager error logging statements + Add new silencePod var to the pump manager state + Rework PodAlerts creation for new podActive time offset and silence values + New PodState var's to manage pod time active state + Remove no longer needed activeAlerts PodState var func + Update updatePodTimes func to manages new time active var's + Update all unit tests as needed for new names & members + Rework UI to use updated simplied interfaces for alertStrings from AlertSlots + Add new Pod Settings button for Silence Pod and Unsilence Pod + Update UI to use new new pod active pod state + Have Pod Settings UI set the pod's expiration reminder alert + Various commenting additions/updates/improvements/corrections Read Pod Status display and consistency updates + Add new faultDescription var for FaultEventCode + Display errorEventInfo details for Pod fault details + Various AlertSlot comment updates for consistency + Make PumpManager silencePod and confirmationBeeps vars read-only + Consistency updates for setTempBasal result handling + Improved OmniBLE PodCommsError recoverySuggestion for noResponse and podNotConnected + Change OmniKit acknowledgeAlerts() to acknowledgePodAlerts() for consistency + New Silence Pod option and View + Update pulseLogString newlines for SwiftUI output + Replace pumpmanager mutateState() with discardableResult with setState() + Restore getDetailedStatus() pumpmanager funcs + enactTempBasal() func skips unneeded pod cancel if running scheduled basal + Restore deliveryStatus PodState variable to verify pod delivery state + Restore lastCommsOK PodState variable for additional comms verification + Add bulletproofing for all insulin commands to prevent 0x31 faults + Updated Notification Settings & Confidence Reminders text for silent pod + New Diagnostics command section at end of Pump Settings > Restore Loop 2.x/FreeAPS Read Pod Status diagnostic command > Restore Loop 2.x/FreeAPS Read Pulse Log diagnostic command > Restore Loop 2.x/FreeAPS Play Test Beeps diagnostic command > New Pump Manager Details diagnostic command + Fix some mismatched comments for some copied LocalizedString's + Update a couple of messages to avoid using the word "Loop" + Add missing LocalizedString funcs for various buttons + Print Pod Details View Sequence # as a zero padded 7-digit value + Fix typo in Pod Details View LocalizedString comment + Updated Pod Fault display with decimal & hex values & separate description line + Prevent immediate low reservoir pod alerts if setting a value higher than current + Improved debugDescription formatting for various PumpManager related state + Allow expiration reminder to be triggered more than once + Acknowledge all pod alerts when toggling silence pod state for safety + Fix to prevent podState expiresAt jumping after a reset pod fault + New PumpManagerAlert to post and clear any unexpected pod alerts + Cleaned up some uneeded PumpManagerAlert related cruft + Improved SwiftUI previews for many views + Fixed various comment typos and errors + Convert some inconsistent uses of NSLocalizedString to LocalizedString + Remove some uneeded and inconsistent semicolons in OmnipodSettingsView + White space cleanup to minimize OmniKit & OmniBLE source file differences + New configuredAlertsString func for detailed info on configured alerts + Renamed alertString func to alertSetString func for better clarity + Clearer PumpManager debug strings for optional current & previous PodState + Clearer PodState debug strings for optional Fault and pdmRef + Add additional bulletproofing for suspend time expired alert clearing Reworked and improved pump manager settings layout + Device Details -> Pod Details + Previous Pod Information -> Previous Pod Details + Remove Pod -> Deactivate Pod Improved alert handling when toggling pod silence state during suspend + reset suspendTimeExpired alert if active and alert not acknowledged + fix logic error which caused podSuspendedReminder alert not to be reset Pod suspend alert handling improvements + Don't clear suspend time expired pod alert to continue beeping until resume + Keep suspend time expired pod beeps on 15m intervals when toggling Silence Pod Make pod fault code, description and ref string info more available + Added the decimal fault # to the reservoir display for a faulted pod + Deactivate pod view includes notification string for common faults + Deactivate pod includes fault # & Ref string for unexpected pod faults Disable selective pod settings commands based on pod state + Disable Set Temporary Basal Rate when pod is faulted or not active + Disable Play Test Beeps Diagnostic when pod is faulted or not active + Disable Read Pod Status and Read Pulse Log Diagnostics with no pod Add missing OmniKitUI.xcassets for Cannula Inserted & reservoir masks * Fix logic error for fault display text during Pod Deactvation Improve OmniBLE/PumpManagerUI directory Xcode sorting
|
hey 👋 - no triage is done for 30 days 🤐 ... anybody? triage is required! |
Could a Trio “patch” or “update” be developed, that would allow logging Afrezza (inhaled ultra rapid insulin) in real time?
I really like a previous Loop Dev version wherein I could easily note 4 units Afrezza, and the prediction line was relatively accurate as was the duration of Afrezza in my system.
But I LOVE, how forgiving iAPS/Trio is of missed carb entries and generally just relaxing management a bit more… Surely the technology could combine these two things? 🤞😅
Afrezza goes into and out of one’s system a lot more rapidly than any injectables, so I find it extremely helpful for high carb and high glycemic index meals or frustrating highs. But this means that it would need a different insulin model (DIA, insulin activity curve, decay rate, etc.) -but it is such a valuable tool in the diabetes arsenal.
My current technique for attempting to log Afrezza insulin is to log it immediately when I inhale, but change the time stamp to about 30min in the past. This rough approach seems to help iaps anticipate/understand what’s happening… I’ve also read on Facebook that others just don’t log Afrezza doses if they’re for covering meals, but that that could throw off TDD calculations.
I think that adding such a feature would have a drastically beneficial impact for users of Afrezza while being negligible for those who don’t use Afrezza.
The text was updated successfully, but these errors were encountered: