potential enhancement - negative iob multiplier

[kenstack]

as discussed on Zulip, attached are the modifications I have been using to add a negative iob multiplier to try to avoid issues with the buildup of negative iob sending a user low. These changes are based on Loop 2.2.4. Modifications are needed in two areas in insulinmath.swift (within insulinkit within Loopkit) and a settings.bundle file needs to be added to Loop in order for this to function.

These were added for personal use only hence the reason for adding the negative iob multiplier slider to "app settings" versus the Loop UI. I tend to do this for personal changes so that as Loop's UI is modified over different versions, it is far easier to port my changes from version to version as the UI changes and Loop evolves to new versions. Obviously if there is interest in adding this as a general feature I could do this properly (or at least attempt too) :).

within insulinmath.swift, changes are required in func insulinOnBoard and func glucoseEffect

I cannot seem to attach the actual swift file, so here is the code for each of those functions with the changes commented

func insulinOnBoard(at date: Date, model: InsulinModel, delta: TimeInterval) -> Double { let time = date.timeIntervalSince(startDate) guard time >= 0 else { return 0 }

    // Consider doses within the delta time window as momentary

    //ken changes
    //implement user set negative basal multiplier
    let negativeBasalMultiplier = UserDefaults.standard.double(forKey: "negativeBasalMultiplier")
    var modifiednetBasalUnits = netBasalUnits
    if netBasalUnits < 0.0 {
        modifiednetBasalUnits = netBasalUnits * negativeBasalMultiplier
    }
    //used netBasalUnits as multiplier originally
    if endDate.timeIntervalSince(startDate) <= 1.05 * delta {
        return modifiednetBasalUnits * model.percentEffectRemaining(at: time)
    } else {
        return modifiednetBasalUnits * continuousDeliveryInsulinOnBoard(at: date, model: model, delta: delta)
    }
}

func glucoseEffect(at date: Date, model: InsulinModel, insulinSensitivity: Double, delta: TimeInterval) -> Double { let time = date.timeIntervalSince(startDate)

    guard time >= 0 else {
        return 0
    }

    // Consider doses within the delta time window as momentary

    //ken changes
    //if net basal is negative use a mulitplier (0-1)
    //modified in user settings

    let negativeBasalMultiplier = UserDefaults.standard.double(forKey: "negativeBasalMultiplier")
    var modifiednetBasalUnits = netBasalUnits
    if netBasalUnits < 0.0 {
        modifiednetBasalUnits = netBasalUnits * negativeBasalMultiplier
    }
    //originally used netBasalUnits 
    if endDate.timeIntervalSince(startDate) <= 1.05 * delta {
        return modifiednetBasalUnits * -insulinSensitivity * (1.0 - model.percentEffectRemaining(at: time))
    } else {
        return modifiednetBasalUnits * -insulinSensitivity * continuousDeliveryGlucoseEffect(at: date, model: model, delta: delta)
    }
}

these functions read UserDefaults for the multiplier. Hence you also have to add a settings.bundle file to Loop to add this variable and create the slider itself. Create a new Settings.bundle file with the settings shown below and place it in Loop.

If there is an easier way to share the actual Settings.bundle file, Id be happy too.

It should appear like the image below if you were successful. make sure the name of the identifier matches exactly to what is in the code mods.

reach out to me on Zulip or here if there are questions. Im not 100% sold this is the best way to handle negative iob but this has been working for us for some time.

Describe the bug A clear and concise description of what the bug is. I.e. what you see vs what you expect to see.

Attach an Issue Report Tap the Loop settings icon on the bottom of the screen, then tap Issue Report and attach it to this ticket.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Phone

• Hardware: [e.g. iPhone XS]
• OS Version: [e.g. iOS 12.0.1]

Loop Version

• Version Number: [e.g. 1.9.2]
• Repo: [LoopKit/Loop, Katie, etc]

CGM

• Device: [e.g. Dexcom G6]
• Manager app: [e.g. Dexcom App, Spike]

Pump

• Manufacturer: [e.g. Medtronic]
• Model: [e.g. 723]
• Firmware version: [e.g. 2.3A 1.1 0B 0B]

Additional context Add any other context about the problem here.

[PavloBasiuk]

Thanks for doing this and sharing your code. I was trying to do something similar. Like: set minimal negative IOB and don't let it get lower than that: e.g:

if IOB <-0.5U then IOB=-0.5U

Your approach makes sense to me. I know that accumulated negative IOB is a symptom that settings are not correct, but if there is unexpected activity, this seems to be a good way to handle it. I'll give it a try over weekend (lots of unexpected activity might happen over Labor Day weekend) and let you know how it went :)

[Willbumster]

This is a great idea! Please try and get it into a production build as I would never attempt to implement this myself. R

Sent from my iPhone

On Aug 31, 2021, at 5:39 PM, kenstack @.***> wrote:

 as discussed on Zulip, attached are the modifications I have been using to add a negative iob multiplier to try to avoid issues with the buildup of negative iob sending a user low. These changes are based on Loop 2.2.4. Modifications are needed in two areas in insulinmath.swift (within insulinkit within Loopkit) and a settings.bundle file needs to be added to Loop in order for this to function.

These were added for personal use only hence the reason for adding the negative iob multiplier slider to "app settings" versus the Loop UI. I tend to do this for personal changes so that as Loop's UI is modified over different versions, it is far easier to port my changes from version to version as the UI changes and Loop evolves to new versions. Obviously if there is interest in adding this as a general feature I could do this properly (or at least attempt too) :).

within insulinmath.swift, changes are required in func insulinOnBoard and func glucoseEffect

I cannot seem to attach the actual swift file, so here is the code for each of those functions with the changes commented

func insulinOnBoard(at date: Date, model: InsulinModel, delta: TimeInterval) -> Double { let time = date.timeIntervalSince(startDate) guard time >= 0 else { return 0 }

// Consider doses within the delta time window as momentary

//ken changes
//implement user set negative basal multiplier
let negativeBasalMultiplier = UserDefaults.standard.double(forKey: "negativeBasalMultiplier")
var modifiednetBasalUnits = netBasalUnits
if netBasalUnits < 0.0 {
    modifiednetBasalUnits = netBasalUnits * negativeBasalMultiplier
}
//used netBasalUnits as multiplier originally
if endDate.timeIntervalSince(startDate) <= 1.05 * delta {
    return modifiednetBasalUnits * model.percentEffectRemaining(at: time)
} else {
    return modifiednetBasalUnits * continuousDeliveryInsulinOnBoard(at: date, model: model, delta: delta)
}

} func glucoseEffect(at date: Date, model: InsulinModel, insulinSensitivity: Double, delta: TimeInterval) -> Double { let time = date.timeIntervalSince(startDate)

guard time >= 0 else {
    return 0
}

// Consider doses within the delta time window as momentary

//ken changes
//if net basal is negative use a mulitplier (0-1)
//modified in user settings

let negativeBasalMultiplier = UserDefaults.standard.double(forKey: "negativeBasalMultiplier")
var modifiednetBasalUnits = netBasalUnits
if netBasalUnits < 0.0 {
    modifiednetBasalUnits = netBasalUnits * negativeBasalMultiplier
}
//originally used netBasalUnits 
if endDate.timeIntervalSince(startDate) <= 1.05 * delta {
    return modifiednetBasalUnits * -insulinSensitivity * (1.0 - model.percentEffectRemaining(at: time))
} else {
    return modifiednetBasalUnits * -insulinSensitivity * continuousDeliveryGlucoseEffect(at: date, model: model, delta: delta)
}

} these functions read UserDefaults for the multiplier. Hence you also have to add a settings.bundle file to Loop to add this variable and create the slider itself. Create a new Settings.bundle file with the settings shown below and place it in Loop.

If there is an easier way to share the actual Settings.bundle file, Id be happy too.

It should appear like the image below if you were successful. make sure the name of the identifier matches exactly to what is in the code mods.

reach out to me on Zulip or here if there are questions. Im not 100% sold this is the best way to handle negative iob but this has been working for us for some time.

Describe the bug A clear and concise description of what the bug is. I.e. what you see vs what you expect to see.

Attach an Issue Report Tap the Loop settings icon on the bottom of the screen, then tap Issue Report and attach it to this ticket.

To Reproduce Steps to reproduce the behavior:

Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Phone

Hardware: [e.g. iPhone XS] OS Version: [e.g. iOS 12.0.1] Loop Version

Version Number: [e.g. 1.9.2] Repo: [LoopKit/Loop, Katie, etc] CGM

Device: [e.g. Dexcom G6] Manager app: [e.g. Dexcom App, Spike] Pump

Manufacturer: [e.g. Medtronic] Model: [e.g. 723] Firmware version: [e.g. 2.3A 1.1 0B 0B] Additional context Add any other context about the problem here.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Trpl7ca]

Made the code change and trying to figure out how to add the settings bundle. Working on that. Like the idea for me especially after exercise

[kenstack]

@Trpl7ca highlight the loop folder with your mouse and right click, and go to new file. If you scroll down to resources you can create a settings bundle in Loop. Youll have to add each of the settings I put above. When you compile the app you should see the slider in the app settings (not in loop but settings->Loop

[Willbumster]

Paclo My son often has negative Iob in the early am. Is that a symptom of an incorrect insulin sensitivity setting? I appreciate your comments. Ron

Sent from my iPhone

On Aug 31, 2021, at 5:52 PM, Pavlo Basiuk @.***> wrote:

 Thanks for doing this and sharing your code. I was trying to do something similar. Like: set minimal negative IOB and don't let it get lower than that: e.g:

if IOB <-0.5U then IOB=-0.5U

Your approach makes sense to me. I know that accumulated negative IOB is a symptom that settings are not correct, but if there is unexpected activity, this seems to be a good way to handle it. I'll give it a try over weekend (lots of unexpected activity might happen over Labor Day weekend) and let you know how it went :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[bjornoleh]

Paclo My son often has negative Iob in the early am. Is that a symptom of an incorrect insulin sensitivity setting? I appreciate your comments. Ron …

Hi @willbumster, that is typically a symptom of basal being too high.

[Willbumster]

Ok, I will tune it down a bit then. Thanks for the tip R

Sent from my iPhone

On Sep 1, 2021, at 7:46 AM, bjornoleh @.***> wrote:

 Paclo My son often has negative Iob in the early am. Is that a symptom of an incorrect insulin sensitivity setting? I appreciate your comments. Ron … Hi, that is typically a symptom of basal being too high.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[bjornoleh]

Thanks @kenstack, I have applied your changes and am currently testing in Xcode simulator. Looks good so far!

One observation: Applying this has some implications to how we analyze BG data and IOB levels in Nightscout and Loop. Until now, negative IOB has been probably the best indicator of having basal set too high. Particularly in combination with falling BGs, and in absence of physical activity. As such, it is very convenient to evaluate night time IOB to understand if basal is accurate. I will probably be testing with the slider set to 0%, to see how that works. But this will also ensure I will never observe negative IOB values.

However, it appears that the negative IOB will be displayed as usual if the slider is set to 100%, but only after a new loop cycle. So the IOB is not deleted, just scaled down according to the sliders setting.

[bjornoleh]

For anyone intending to test this with the FreeAPS-fork of Loop, please note that there is already a settings.bundle file, which is used for the Adaptive Rate Nonlinear Model toggle.

Just add the three Preference Items as described above. These can be placed above or below the Adaptive Rate Nonlinear Model toggle. (and you might want to set the default value of that setting to OFF while you are editing that file).

[kenstack]

@bjornoleh that is exactly correct - on every loop iob is calculated and so if you change the slider, after the next loop the calculation is repeated this time with the new multiplier.

As you and other posters have mentioned, if a user constantly has negative iob, then really it's likely basal is set too high (or potentially sensitivity is set too low). On the other hand, if in general you feel settings are decent (they will never be perfect :)), and you are trying to combat the double low problem of negative iob hitting you as you rebound, and this negative iob is due to say exercise or some other factor, then this kind of solution I think works well.

As I mentioned in the initial post, I'm not 100% sure this is the right way to handle it. It might be better to a) make it adaptive, ie look back for the last hour or 2 (sort of like rc) and then turn off negative iob if the model has been over predicting bg, or b) move long term to a "better" model, though I think a) may be more practical.

For us so far, it's worked well - nights and the next am post exercise we have had no double low events in quite a while. But it still requires user interaction.

[Trpl7ca]

Using V2.2.5 and it builds successfully to iPhone simulator but I get this error:Thread 7: "This NSPersistentStoreCoordinator has no persistent stores (schema mismatch or migration failure). It cannot perform a save operation." Reviewed 3 times. Sure don't want to bother you so if no time don't answer. I will get fresh clone and start over.

[kenstack]

I didn't build to the simulator but that looks like (I'm guessing) the settings bundle isn't working - can you build to a test phone and see if the slider shows up properly ? Someone else can perhaps help I tend to do my testing on a test phone.

[bjornoleh]

I have successfully built to both simulator and, so I would not expect any differences there.

[Trpl7ca]

Think you are right none of the normal toggle switches show up in settings. Thanks I will start over.

[kenstack]

If you Send a pic of the settings in Xcode perhaps we can debug

---

Kenneth D. Stack President

Proximus, LLC. M&A, Venture Capital, Advisors

734.330.6422 734.470.6332 fax @.*** www.proximusllc.com

CONFIDENTIALITY NOTE: This electronic transmission, including all attachments, is directed in confidence solely to the person(s) to whom it is addressed, or an authorized recipient, and may not otherwise be distributed, copied or disclosed. The contents of the transmission may also be subject to intellectual property rights and all such rights are expressly claimed and are not waived. If you have received this transmission in error, please notify the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distribution or disclosing same.

On Sep 1, 2021, at 12:50 PM, Trpl7ca @.***> wrote:

 Think you are right none of the normal toggle switches show up in settings. Thanks I will start over.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bjornoleh]

If useful to anyone, the exact changes I made are available in the commits that are referenced above. Use on your own risk ;-)

Edit: the commit referenced below is the current one for the app settings, I just clumsily updated the commit description afterwards, sorry :-)

[Trpl7ca]

[bjornoleh]

@Trpl7ca , there is an additional space in your multiplierTitle ;-)

[Trpl7ca]

nope fixed that but :

[Trpl7ca]

Wait working need to input settings cgm and pump into sim.

[Trpl7ca]

Nope no slider option, Thanks I will delete and start over. Not much going on anyway and maybe learn some swift.

[bjornoleh]

I did spend some time making sure I did not change the indentation (tabulator) of the code. Copy/paste of the initial description here did introduce some changes. In went over everything to make it was coherent with the original structure. Not sure if this is critical, but I would think so.

[Trpl7ca]

It working just not getting settings slider, in fact some of the other options in settings like blue tooth, Face ID, cellular data. Thanks for advice will start over.

[kenstack]

@Trpl7ca if I had to guess the project isn't picking up the settings bundle. I'd clean the build folder and I'd save the files after, but that's a pure guess.

[bjornoleh]

I just applied the modification to Loop master 2.2.5, and no issues there, at least not with a sim build.

Working with Xcode and GitKraken, I did have to make sure to commit the changes made in the Xcode project file as well as the settings files that was created (I forgot at first, did not work then), possibly that was the issue?:

[kenstack]

Thanks for doing that ! I'm guessing not committing / saving was the issue discussed above.

[bjornoleh]

Perhaps someone would test if these patches will do the trick? I will test later.

Download the .txt files and place them in their respective directories within the workspace. In Terminal, navigate to each folder and type

In LoopKit: git apply LoopKitNegIOBpatch.txt

In Loop: git apply LoopAppSettingsPatch.txt

LoopKitNegIOBpatch.txt

LoopAppSettingsPatch.txt

[Trpl7ca]

I will try later on the way out. Rookie here so not sure how to commit. Tried with Xcode source control but get: Multiple working copies failed to commit files. I will have to research how to do that correctly.

[bjornoleh]

I tested the patches now with a fresh clone of LoopWorkspace master. Short version: The patches works.

Edit2: I was previously seeing crashes in simulator when disconnected from Xcode (was running fine until disconnected). After starting over with a fresh clone and a rebooted Mac, I am no longer seeing this.

How to use the patches:

In Terminal, clone LoopWorkspace into Downloads folder:

git clone --branch=master --recurse-submodules https://github.com/LoopKit/LoopWorkspace

Navigate to Downloads and the freshly cloned workspace:

cd LoopWorkspace
cd LoopKit
git apply LoopKitNegIOBpatch.txt

The patch was applied successfully, but with warning: 3 lines add whitespace errors. This should not cause any issues.

cd ..
cd Loop
git apply LoopAppSettingsPatch.txt

This patch was also applied successfully, with no confirmation in Terminal

cd ..
xed . 

This opens the workspace in Xcode. Make sure to select Loop(Workspace) and the correct phone or simulator, then sign and build as usual (signing is not required for simulator builds!).

In the file tree on the left hand side, the folders and files that were modified by the patches are marked with an ´M´. This confirms the patches were successfully applied.

The settings.bundle file was marked with ´?´. Possibly, this indicates that the change has not been committed? I don´t know. But, the build to simulator was successful, so these patches seems like an easy way to test the negative IOB override.

As always, use at your own risk. But the patches seems to be in accordance with the code changes proposed by @kenstack.

[kenstack]

@bjornoleh thanks !! Great method for applying the patch.

Everyone should use carefully as it's only been tested on n=1.

[Willbumster]

Hi will this eventually be part of the core build?

Sent from my iPhone

On Sep 2, 2021, at 5:14 PM, kenstack @.***> wrote:

 @bjornoleh thanks !! Great method for applying the patch.

Everyone should use carefully as it's only been tested on n=1.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Trpl7ca]

Got it up and running on sim. Thanks @bjornoleh

[bjornoleh]

@Trpl7ca glad it worked! Are you seeing app crash/failure to launch after disconnecting from Xcode?

[Trpl7ca]

Nope, seems to work fine when disconnected. Closed and opened again no problem. Had to clean up some code issues. Is there any way to figure the % of reduction or is it just an estimate?

[bjornoleh]

Good to hear.

You will just have to eyeball the slider it seems. Might be possible to make that setting more numerical, I don't know. But probably good enough as is.

[Trpl7ca]

And it is working, created some negative IOB and put the slider at 0 and it cleared out the Neg IOB on next loop cycle. I will put it on a backup phone later today. thanks again

[bjornoleh]

I started over with a fresh clone of 2.2.5, and applied the two patches. I am no longer seeing the app crashes after disconnecting Xcode. Who knows what happened before, but the patches seem solid. It will be interesting to see how different people find this modification.

@Willbumster, I guess it is much too early to know if this or something similar will become a part of Loop. Some careful testing and reporting back the findings will be a first step.

[Trpl7ca]

Its been working fine on backup phone for 3 hours and not connected to Xcode I am able to zero out neg IOB and select 100% and it starts over There were a few extra characters and some extra lines just prior to the patch in func insulinOnBoard. So I went to another copy compare and cleared up the differences. No problem crashing so far. For me really only need something like this after exercise.

[Willbumster]

Thanks for the reply, sounds like a terrific enhancement.

Ron

Sent from my iPhone

On Sep 3, 2021, at 4:56 PM, bjornoleh @.***> wrote:

 I started over with a fresh clone of 2.2.5, and applied the two patches. I am no longer seeing the app crashes after disconnecting Xcode. Who knows what happened before, but the patches seem solid. It will be interesting to see how different people find this modification.

@Willbumster, I guess it is much too early to know if this or something similar will become a part of Loop. Some careful testing and reporting back the findings will be a first step.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[Nightfoxy]

I'm a little mixed on this. Practically, its great for minimizing hypos due to bad/incorrect basal.

On the other side, seeing the actual negative IOB is super valuable data. You can use this data to determine what basal SHOULD be. If you use the IOB near the bottom, before BG comes up on its own, you can follow this formula: IOB / DIA = basal rate change.

For example, -0.3u / 6 hours = -0.05 u/hr. Or, reduce basal by 0.05 u/hr.

This multiplier will mask this data.

Is there a way to save or log the actual IOB along the way? Maybe even propose a basal rate change or even just suggest that basal should be re-tested if negative IOB gets to a certain % of the scheduled basal rate(s)?

[Willbumster]

Hi ken What is DIA? R

Sent from my iPhone

On Sep 9, 2021, at 11:10 PM, Ken Fox @.***> wrote:

 I'm a little mixed on this. Practically, its great for minimizing hypos due to bad/incorrect basal.

On the other side, seeing the actual negative IOB is super valuable data. You can use this data to determine what basal SHOULD be. If you use the IOB near the bottom, before BG comes up on its own, you can follow this formula: IOB / DIA = basal rate change.

For example, -0.3u / 6 hours = -0.05 u/hr. Or, reduce basal by 0.05 u/hr.

This multiplier will mask this data.

Is there a way to save or log the actual IOB along the way? Maybe even propose a basal rate change or even just suggest that basal should be re-tested if negative IOB gets to a certain % of the scheduled basal rate(s)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[kenstack]

@Nightfoxy yes this is certainly possible to save the "error" between actual basal and scheduled basal as a new variable. Alternatively you can probably just go into your NS data (if you are using it) and calculate it. Be careful to ensure NS is correctly handling actual basal rate as loop doesn't upload it directly as I remember on every loop if you try the latter. I seem to remember that the V2 NS endpoint has a caching issue with basal rate - but maybe it's been fixed.

@Willbumster dia is duration of insulin action, which for novolog/humalog is about 5-5.5 hours.

[bjornoleh]

Ok, so now I have a little experience with this patch from running it for around ten days.

Short version: I do not recommend setting the slider to 0% or close to that. Negative IOB accumulates in the background, and might trick you into increasing basal too much.

To gain experience, I set the slider to around 5%. I wanted to see the full effect of this patch, while hoping to catch negative IOB accumulation since I did not set it to 0%. It turned out that there was accumulation of negative IOB nonetheless, and I did end up increasing basal too much. It caused no harm except a single mild low which was treated with 2 g glucose, and Loop was certainly a lot more forgiving of too high basal than usual. But oscillations with a 2 hour period were initiated, and it was not obvious from the IOB that basal was the cause. It looked a lot more like too strong ISF.

This morning I checked the "real" IOB by setting the slider to 100%. IOB was correctly reported at the next loop cycle, and it was -0,4 U, which is pretty unheard of for our little looper in normal circumstances. The prediction curve was for some reason correctly updated only after the second loop cycle.

I opened the loop before touching yhe basal multiplier slider, which was a good idea! Before closing the loop again, I entered a 0,3 U fake insulin entry in Health, and lowered basal by 0,1 U/hr to 0,2 U/hr.

I will keep the slider at 100% for a little while to verify basal is ok, then I will probably test again at around 50%.

For anyone testing this patch, please look out for any apparent reasons to increase basal, that may not be necessary. This is probably best checked in the morning by opening the loop, set the slider to 100%, and wait for a couple of cycles.

Negative IOB at around 09 in tbe morning, cancelled by fake insulin in Health:

[kenstack]

@bjornoleh nice example. My son generally runs between .25 to .5 on the multiplier. He has seen this "oscillation" at low multiplier levels, but as I look at your example, if the multiplier had been at 1.0, I'm guessing your son would have had the classic double low where loop would have replaced all that missing iob after that big bounce and sent him low, since by 9am he was in range but only used about half of the programmed insulin between midnight and 9am. Am I interpreting this correctly?

I'm not sure I would change any settings in this case. On a night that doesn't start with the drop, he's likely flat as loop runs normally (ie the multiplier doesn't really come into play).

My kid zeros it after exercise which I'm happy to take a bit of oscillation like that instead of a nasty iob replacement low! Then the next morning moves it higher but always below 0.5. But again - this is an n=1 optimization :)

I'm not sure there is a perfect method here. As my son now lives alone, avoiding night lows are the priority so it trumps an increased bg / oscillation. But if your son is young and at home and you are monitoring, then yes I agree completely it may be better to take a bit more "risk" for better control and crank it up or go back to 1.0.

Thanks very much for posting the example - this is a good discussion!

[bjornoleh]

The oscillations in my example are pretty much entirely an effect of me adjusting his basal up too much, and Loop did behave quite well in this situation. I would not have set such a high basal normally, but any negative IOB tends to bite pretty hard without the patch. So I think we will make good use of the negative basal multiplier in the future. Our use case is for periods of reduced basal needs, and it will probably work out well having some more tolerance for excessive basal.

As a disciple of Kenny, I expect I will have to find the right basal multiplier to still allow me to monitor IOB overnight so I can adjust basal as needed :-)

[Nightfoxy]

@Willbumster duration of insulin action, which should be 6 hours in loop.

@bjornoleh I hadn't thought about how this could be a nice way of mitigating that pesky problem our Littles have when true basal rates are in between what we can schedule on the pump/pod. Nice work!

[Nightfoxy]

@kenstack @bjornoleh Which IOB is reported to NS? The "real" or un-altered IOB? Or the IOB after the this feature takes effect?

If the second, then I would prefer to have the absolute IOB end up in NS some how. At minimum, in the Loop pill.

Until we can can get the Open/AndroidAPS feature in NS where you can hover over the data points in the day to day report and see the actual IOB, I guess it isn't super useful for exact calculations outside of the Loop pill.

I don't know what the long term design should be in Nightscout, so the pill would be sufficient. Maybe even available by hovering over the IOB pill?

I like that you can sort of get the "real" basal by adjusting the slider and waiting for a loop. Maybe some data could be added in the UI around the slider so its available at all times? Max negative IOB in the past hour or 2? Something else?

I really want to be able to quickly know if basal should be adjusted instead of leaning on the slider. That's what I'm after.

[bjornoleh]

You’ll see the same IOB everywhere, which is the altered one. So you will have to adjust the slider to see the normal IOB (I think Jon used a number picker?).

I think I have described this above, but it’s easy to end up with a too high basal based on your type of IOB analysis when using this feature. Just make sure not to set it too low, zero is no go. I think I used something like 50% most of the time, with some adjustments.

Switching to 100 % occasionally is pretty instructive. You will always see some accumulated negative IOB when switching from low to high %.

Please read my previous comments, there is one thing that need two cycles to update (prediction?)

[PavloBasiuk]

So, I've updated to v.2.2.9 and re-applied this patch, and it seems that something is off. I've placed a bunch of breakpoints in modified code to ensure that modified code is being called, and none of those breakpoints worked (that is a sign that modified insulinOnBoard and continuousDeliveryInsulinOnBoard are not being called/used). To verify my thought, I've changed the slider all the way to 0, and waited for IOB to become negative. And IOB fell to -0.15U, when my expectation was for IOB to remain at 0U.

Question: is anyone aware of some changes to LoopWorkspace that broke these patches? And how to fix it :)

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.