Add shortcuts implementation #129
Conversation
Co-authored-by: dnzxy <d.c.cengiz@googlemail.com>
Co-Authored-By: Deniz Cengiz <48965855+dnzxy@users.noreply.github.com>
Co-Authored-By: Deniz Cengiz <48965855+dnzxy@users.noreply.github.com>
Co-Authored-By: Deniz Cengiz <48965855+dnzxy@users.noreply.github.com>
NightscoutTreatment should be agnostic, so moving the init extension into PumpHistoryStorage allows for better sepearation of concerns.
Update tidepool to add external insulin Update tidepool after removing externalInsulin Update tidepool after removing externalInsulin event type by @BrianWieder update tidePool to integrate iSMB attribue
Refactoring the shortcuts with adding : - same organisation of files - remove junk code - add internationalization of shortcuts - add AddCarbs shortcuts - add createAndApply temp target
Shortcuts : - Add override preset selection, application and cancelation
Shortcuts : - Add Carbs preset list and display all carbs, fat and proteins associated
|
I wonder if “Temporary Preset” should be renamed as “Temporary Target”? There was a PR to fix this recently, perhaps it was @kylmcw |
|
I fixed the time display for the temp targets, changing only the shortcut banner text, and the shortcut box text to "temporary target" |
|
There is a Cancel Temporary Preset in the screenshots above. And perhaps all instances of “temp preset” could be replaced, if they are misleading/confusing now? |
- fix carb list shortcut issue - fix carb added with fat/protein shortcut - harmonise temporary target labels - translation added
|
Updated with :
|
|
This is great. Would love to see boluses as well. From a remote caregiver perspective, not being able to bolus remotely is a deal breaker. All caregivers who I know who are using iAPS currently rely on shortcuts for this. |
|
@aug0211 I'd like to add a few barriers to prevent dangerous boluses. What do you think ? |
|
I like 1 and 2 but not 3. Almost 100% of the time we use this would be blocked by 3. I just sent a remote bolus of 1u to my son at school. He has an override running because he is right between two recesses but has lunch right before recess 1. Oref did not recommend any insulin at this time. It had even cut basal, actually. The override does not adjust settings other than stopping SMB - and still it recommended 0.0u at this time. I do this 5 days a week, without fail. This is a nightmare situation as a parent of course, but it has proven to be our best way of managing a child at school who has lunch immediately followed by recess, then a short break, then another recess. We've been improving over 3 years and are constantly learning, and this is the best we've found so far. We send an override that stops SMBs during this period and then manually push a large bolus as soon as the drop from exercise round 1 starts, such that the peak activity of the insulin hits as soon as possible and preferably not at the end of exercise 2, where we can expect to see big drops. Our total IOB will make some sense in relation to COB and our ratios and such, but oref will not recommend any insulin because we're on a drop down (but we know we're dropping from exercise which ended at 1:45 PM and the drop is slowing, and we're headed for 200 if we don't flow insulin soon - and also we MUST send it all now because if we don't, it'll cause a severe hypo at the end of recess 2 at 2:45 PM. All kinds of detail in there, hopefully not too much, but there are so many examples like this that come up on a regular basis that I wanted to give a real one to consider. Image attached showing what bolusing leading up to lunch looks like, and what the big bolus after recess 1 looks like before heading to recess 2. Every bolus there is done by hand via shortcuts and would have been impossible with guard #3. look closely as that 1u bolus I manually sent remotely via a shortcut. Yes, I sent a full unit of insulin remotely on a -17 point drop! iAPS would never come close to doing this with our settings (which may not be perfect but are, if anything, perhaps a bit aggressive for an 8 year old). I pushed this because I'm the caregiver, I've been doing this thing for 3 years with him, and I know the environment and confounding variables better than iAPS does (unfortunately). We can see that I was right, right after that -17 drop where I sent the 1u is a +4, +3, +5. I wish I could get any system to do this better and understand these complex situations better so I don't have to, but this is where we are today and what caregivers must account for. Another simple one is the kiddo just ate 20g of carbs as a surprise snack at a friend's house. We found out late. Because he's 8. We really don't want to be spoon feeding boluses limited by oref's recommendation (why not just let oref do it then...). We need to push all of that insulin ASAP to head off the otherwise inevitable spike that's coming. Another every day example is a meal. It might be 5:45 PM and we know we're eating at 6:00. We're in the kitchen cooking and our son is in his room reading. Sure, we could go interrupt him and have him get his phone out for us to bolus and so on. Or we can just send the carbs remotely, and bolus remotely. Unfortunately, iAPS will take a very long time to automatically bolus, or generate a strong enough recommendation to allow us to send the insulin needed if we want to eat in 15m. If it's a 40g meal and he needs 4 units, we'd like to send the 4u now remotely so we can eat in 15m. iAPS won't recommend that 4u even if his settings make sense for it because of all of the other predictions at play. Part of what's nice about using technology like this is not having to create small moments of inconvenience for a child (and parent). Of course, every time he eats situations like this arise so it's not a corner case and happens every day multiple times. I think the device should always recognize its max bolus as configured and not allow more (whether via SMB, manual, or manual from shortcut) - this is guard number 1 that I agree with. I also think explicitly turning this functionality on via a toggle in settings on the looping device is a good safety measure. Beyond that, we need to consider the remote capabilities as a first class citizen in the ecosystem. After all, most children do not make decisions about their care, it turns out in these situations that it is the caregivers making decisions - often executing these from a distance (school, friend's house, sports event, or even just across the home in bed at 2 AM when stuck high). One last reason to avoid number 3: people are clever. They'll inevitably end up trying to get more access to insulin when needed and send a 200% override and 80 target so iAPS makes higher recommendations. This is a gross hack to encourage, and creates a safety concern in itself. Someone will forget to turn that 200% off and something bad will happen. |
|
My two cents is that 3️⃣ also could be an opt-out toggle for the user to decide if he/she don’t want that extra guardrail. Defaults to guard bolus<max insulinreq enabled |
|
I think 3 will be so restrictive that people using shortcuts for boluses will find that they can't send enough (or even just can't send any insulin) to make the feature useful. I suspect almost everyone would turn that option off, anyway, if offered - making the effort to implement not great use of time. Maybe those of us who will use this a lot should keep an eye on all remote boluses we send over the next day or so, and jot down a quick note each time to log "recommended bolus" and "sent bolus". Maybe I'm wrong and it turns out that what is sent manually often ends up being close to the recommended bolus. Another way to do this is to go back through NS history of course, if we remember which boluses were sent via shortcuts. I'll jot down a lot for the day today and report back with data. |
|
Yeah, and maybe the most obvious problem with a insulinReq limit would be if you want to send a remote meal and a bolus enacting at the same time or quickly back to back (When doing remote commands I usually like to enact the meal bolus before registering the meal carbs to avoid potential collisions when a loop and SMB:s happens right after the carbs been registered but before the manual remote bolus has had time to get enacted. In this use case (bolus first, then carbs) an incoming bolus would always be rejected since iAPS don't know about the carbs yet (not included in InsulinReq calculation) |
|
Thanks for your response. I created a config for shortcuts where you could choose the method to limit the bolus amount. If not useful, I will remove it :
|
- add bolus shortcuts with guardrails - add in OIAPS a shortcut config allowing to authorize bolus enact and guardrails.
|
I close this PR. New PR related with dev branch #144 |
Shortcuts open IAPS
this PR refactors the shortcuts and adds new shorcuts for open-IAPS.
Refactoring
List of shortcuts available
Some examples described in the picture :