Feature Request: Ability to stop SMB

[jbr7rr]

The desire to be able to cancel running SMB's pops up often in Discord.

A few questions for discussion:

a) Why do we want this? b) How do we want this? c) Why don't we want this? d) Other consolidations

My personal answers:

a) Mistakes happen, I once forgot to disable loop during exercise, a fairly large SMB was delivering and I could not cancel other then ripping off the pod b) A solution where we can able to open the bolus progress screen (what we see when doing a normal bolus) where we can watch the progress and cancel the bolus c) It adds complexity, d) We need a very clear UI for this, I would prefer some good input on this before this gets implemented

[robertrub]

Seems that, while SMB is being injected, if you bolus manually and cancel it right away, the bolus AND the SMB are cancelled. And the icing on the cake, the correct amount injected is known (and shown in the treatments tab).

I have not tested this personally. This was explained by @Maximus1 in the AAPS Discord.

All we need would be where to put the STOP SMB button (I'd say on the button line where SMB information is shown).

The programming could just branch to the same place as the "cancel bolus" button points.

[painbrain81]

very good idea

[vanelsberg]

Can not see the logic or need for this and is confusing? 1) SMB runs every 5 mins - so user is to stop every 5 minutes? 2) A single SMB is (should be) small enough to not being a problem. Stop unwanted SMB's by setting a temp target or such should solve the problem?

[Philoul]

Hum, I agree with @vanelsberg , Stopping a SMB duting injection of SMB needs to have smartphone and AAPS in front of the eyes exactly when SMB is delivered in the body. With my insight pump delivering duration for SMB, due to very small quantity of insulin, is generally less than one or 2 seconds. If you don't want SMB and you can prevent them temporary with a high TT, but if you expect to be able to cancel a SMB during delivering it will just not be possible 99.9% of the time (either because you don't look at aaps screen exactly when needed, or when SMB is delivering, you will not have enough time to see, understand, and decide to cancel it that smb delivering will already be finished)...

When you drive a car and an accident occurs just in front of you, it takes 2s to decide that you should brake immediatly!

[robertrub]

Nobody wants to stop a small SMB, that is not the problem.

One might want to stop a big SMB due to an error. It is emergency stop that is needed.

User mixed up a profile % setting change or you got an erroneous high BG reading etc and that triggers a big SMB. THAT SMB is the one you want to stop. THAT SMB takes a long time to administer and you'll have time to stop it before full delivery (you'll get the ongoing insulin injection information by your watch or the noise of the pump).

This emergency stop exists for the bolus errors. The same should exist for SMBs.

[Philoul]

Big SMB 🤔 Remind me the acronyme behind SMB... Super Micro Bolus... A big bolus given by a loop algo is not a real SMB (with the spirit of this feature included with oref1), and probably not given by a standard version of AAPS. It uses SMB to provide a real bolus... It's probably a dangerous way of using side algorythms (for Full UAM trials, associated to wrong profile or wrong settings ???) and proposed solution doesn't seems to be the good one according to me (but I admit I can be wrong, I'm just surprised by this request...).

[vanelsberg]

Agree with @Philoul: SMB's by definition should be relatively small.

Have set SMB set to be fairly aggressive but I never see SMB's exceeding 0,5u due to limits set. I would not call this an emergency?

[vanelsberg]

@robertrub you'll get the ongoing insulin injection information by your watch or the noise of the pump) Agree that one does not want this. But in practice, 99,9% user would be too late to stop such SMB's. Apert form users reaction time, also note there is quite some delay between user pressing a "cancle" butten and the moment the command cancel command is received and executed on the pump.

[vanelsberg]

IMHO features like this only add to much unwanted UI and code complexity with really improving AAPS's usability for the general user.

In general, with latest versions I am seeing added loads of new features, plugins and algo additions to AAPS. I would hate to see AAPS changing to the "Swiss Knife" of Hybrid looping were UI has too much priority. My advice: stay with the basics, with proven to work? Quoting Elon Musk: the best part is no part!

[robertrub]

High after a pizza gives a lot of SMBs, some are .8U which by itself is not much but added to the others, it might be problematic.

The meal bolus is at the bottom, all the others are SMBs...

Can't understand why I can cancel a bolus but not an SMB...

At any given time, one needs the possibility of an emergency breaking. Users can will ! make errors and counter measures (even if never or very rarely used) need to be available.

[vanelsberg]

Hmmm....

Can't understand why I can cancel a bolus but not an SMB...

For the same reason you cannot cancel a temp basal rate?

The way I see it, due to safety limits set in AAPS, a single SMB can never create an unrecoverable problem. If it does user has a more urgent problem to solve in general. So, I really see no value in stopping this single SMB bolus (🤔 which by the time the user could stop it would most likely be almost done anyway).

If this would somehow be an emergency, I think the proper way to handle this would be to stop the loop or rip off the pump and then solve the actual cause of the problem?

[jbr7rr]

For the same reason you cannot cancel a temp basal rate?

You actually can do that

The way I see it, due to safety limits set in AAPS, a single SMB can never create an unrecoverable problem. If it does user has a more urgent problem to solve in general.

I don't agree. There are additional circumstances where a SMB is normally ok. But under that special circumstance it is not, see my original post, where I was doing sports and forgot to set a high TT and noticed the omnipod delivering a large bolus. At that point I ripped it off.

Also I know SMB was intented to be small. But more and more users are using FCL or a more hybrid approach. And under these regimes the SMBs become larger. Are we going to dismiss this under the guise that this is not the intented use case? Ppl are going to do it anyway so it would be safer to have a abort mechanism imo.

Or just a way to have the normal bolus popup shown and where you can stop it. E.g. by tapping on the progress bar

[vanelsberg]

@jbr7rr @robertrub Ok, even though I still do not see use for this feature, the fact that you guys do is valid enough for me. Agreed, I rest my case ;-)

Will build with current PR#3383. Do we need any special testing?

[vanelsberg]

Would be nice to have the "stop" button temporarily suspend SMB all together then. Is that feasible without changing/adding a lot of code?