nightscout / Trio

MIT License
64 stars 259 forks source link

Add shortcuts implementation #129

Closed avouspierre closed 3 months ago

avouspierre commented 3 months ago

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 :

Select a carb preset, add carbs associated and define a override preset List of shortcuts available Cancel temporary preset and/or override preset and adds carbs in the past
IMG_93A644ADB473-1 IMG_E62CF95824EE-1 IMG_F4A8EE137CD2-1
temporary preset with a date in 60 minutes When I start a fitness activity, start sport override except if my BG > 180, wait 30 min and notify me Cell
IMG_16251E5F9A67-1 RPReplay_Final1714157264 -
bjornoleh commented 3 months ago

I wonder if “Temporary Preset” should be renamed as “Temporary Target”? There was a PR to fix this recently, perhaps it was @kylmcw who did that?

kylmcw commented 3 months ago

I fixed the time display for the temp targets, changing only the shortcut banner text, and the shortcut box text to "temporary target"

bjornoleh commented 3 months ago

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?

avouspierre commented 3 months ago

Updated with :

aug0211 commented 3 months ago

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.

avouspierre commented 3 months ago

@aug0211 I'd like to add a few barriers to prevent dangerous boluses.

What do you think ? 1️⃣ the bolus must be less than the max bolus 2️⃣ allow to send a bolus using shortcuts only if a parameter in settings is defined to true (false by default like remote NightScout) 3️⃣ the bolus must be less than the bolus recommended by oref ❓other

aug0211 commented 3 months ago

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. image

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.

dsnallfot commented 3 months ago

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

aug0211 commented 3 months ago

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.

dsnallfot commented 3 months ago

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)

avouspierre commented 3 months ago

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 :

config config
Simulator Screenshot - iPhone 15 - 2024-05-01 at 18 23 50 Simulator Screenshot - iPhone 15 - 2024-05-01 at 18 24 00
avouspierre commented 3 months ago

I close this PR. New PR related with dev branch #144