oref0
oref0 copied to clipboard
openaps
Giving ALL the basal up front, except when near target (then give no basal up front)
Is your feature request related to a problem? Please describe. If you're using a calculated/tested ISF and not autotune's, using a "Super-ISF" can provide more insulin while still keeping you from going hypo later. (This is a follow-on to https://github.com/openaps/oref0/issues/1278, but it may have wider relevance than just no-carb/no-bolus/no-announcement looping.)
Describe the solution you'd like A clear and concise description of what you want to happen. Super-ISF uses the same approach as super-bolusing and SMB's, except where SMB's are fixed to a number of minutes and affect the micro-bolus amount, a Super-ISF automatically accounts for as many minutes as needed from the current BG (without any re-calculation needed), and affects max-IOB (but not the micro-bolus amount, dependent on implementation, which SMB still controls).
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Super-boluses and SMB both already assume that the amount of insulin you are "stealing" from your basal insulin will not immediately cause you to drop - i.e., there is some time wherein you can make up the amount of the super-bolus/SMB by zero-temping the basal. Super-ISF incorporates the time available into the ISF ahead of time, given your individual "maximum drop rate" - i.e., the likely fastest rate you will drop over an extended period of time (30-60 minutes or longer, not just a single 5minute drop). This rate can be gleaned from your past reports, and even scripted to calculate from past Nightscout data.
E.g., I've found that my son's max 45min average drop rate is about 11 mgdl/5min (excluding CGM anomalies, e.g., sensor start/stop noise), and usually its quite a bit lower than that. Using that drop rate, and his current average basal rate and normal ISF (from calculations or testing), his Super-ISF is calculated:
root@benaps2:~# ./calcSuperISF.sh 11 1.187 28.4 50
superISF=22.62
root@benaps2:~# ./calcSuperISF.sh 11 1.187 28.4 500
superISF=22.62
root@benaps2:~# ./calcSuperISF.sh 11 1.187 28.4 5000
superISF=22.62
root@benaps2:~# cat calcSuperISF.sh
#!/bin/bash
# usage: ./calcSuperISF.sh maxDropRate5Min basalAverageHourly normalISF deltaBGFromTarget
maxDropRate5Min=$1
basalAverageHourly=$2
normalISF=$3
deltaBGFromTarget=$4 # this gets cancelled out of the final result
#
if [ $(bc <<< "$maxDropRate5Min < 0") -eq 1 ]
then
maxDropRate5Min=$(bc <<< "scale=4; -$maxDropRate5Min")
fi
basalMinutesSteal=$(bc <<< "scale=4; ($deltaBGFromTarget/($maxDropRate5Min/5.0))")
stolenUnits=$(bc <<< "scale=4; ($basalMinutesSteal/60.0)*$basalAverageHourly")
regularUnits=$(bc <<< "scale=4; $deltaBGFromTarget/$normalISF")
totalUnits=$(bc <<< "scale=4; $regularUnits+$stolenUnits")
superISF=$(bc <<< "scale=2; $deltaBGFromTarget/$totalUnits")
echo "superISF=$superISF"
root@benaps2:~#
Additional context Add any other context or screenshots about the feature request here.
Running with his Super-ISF vs a calculated/tested ISF results in quicker BG recoveries and lower spikes. (I cannot currently compare to a working autotune since that was calculating a much stronger and not helpful ISF for our no-carb-entry usage model, as described in the other issue).
i don't have illusions that it will always be like this, but here's a glimpse of our last 2 days with dual profiles & superISF: 
no announcements or boluses of course, and plenty of carbs. and no temp targets or manual adjustments used.
I've updated the issue title, because SuperISF is just one way of "Giving ALL the basal up front", and also wanted to note that "when near target... give no basal up front". The point of this issue is that instead of giving a fixed maxSMBBasalMinutes of basal up front, we could be giving all of the basal up front that is expected to be given until we are back down near the target. In fact, giving a fixed maxSMBBasalMinutes is technically wrong, since you really can't safely increase it (much), i.e., its really currently a boolean preference && it currently fails when near target since it instigates rollercoastering (so this part could be a bug report or a feature request).
SuperISF is an easy way (for me) to achieve this since ISF already takes BG (and thus time) into account. However, another way to achieve this, which is probably more in line with existing OpenAPS mechanisms, is to use the Zero-temp prediction (ZTPred) to count up all the time/basal that is available until the prediction reaches target, and add that to the "insulin required" used for SMB calculation (subtracting out, or not double-counting maxSMBBasalMinutes of course).
Going to try setting this up later this evening and run it for a few days (won't run it overnight, since I'd like to be awake for it). Will report back here with some observations/ opinions!
i'm overwriting the ISF stored in /root/myopenaps/settings/autotune.json and /root/myopenaps/autotune/profile.json with a script that runs after autotune runs. (actually my script just runs every 2.5 minutes since it also implements BG-dependent profiles from #1278 )
yes... here is my override script (disclaimer: may not be appropriate for your use case, may not be fully tested, no claims as to quality, usability, etc...) fourISF.sh.txt
read the script carefully, as it also changes preferences and i raise targets (by disabling autosens and drastically reducing its sensitivity - see #1278 for other reasons), which creates a bigger safety window for the enhanced isf's... *** it also [un-]scales isf by autosens, since i don't use autosens but instead use its sensitivity to apply to basal's/targets only... if you don't understand this and know what you want to do with it please don't use the script [its a temporary workaround for testing, not intended for wide use] ***
(note: if you do disable autosens and use it like me, note that determine basal doesn't scale maxSMBBasalMinutes*basal by sensitivity [it probably should], so i've been scaling it myself in the parameter to this script instead)...
I think I like this approach, mostly as it feels like the safest approach so far to address potential non-static ISF scenarios by simply trying to avoid them.
Do I understand correct: I should set the script in my oref0 (I already did mount and write to oref0) and then write the script to cron, And manually stop autotune in cron. Right?
And how to start calculation? Do I need to set up another script (./calcSuperISF.sh)? Seems yes
please read my comments above about the script and how i use it - there are numerous caveats (at that time i had disabled autosens, not autotune, in order to scale the autotune results by my own fixed 'sens', but at this point i have disabled both). yes, i still calculate "super ISF" via the script in the original post, but your results may as always vary...
fyi, rather than run the script that overwrites settings/profile from crontab, i found that adding it here in oref0-pump-loop gets its updated just in time for each new bg:
try_fail wait_for_bg
+ /root/setisf.sh
I've been playing with no bolus/no carb announcement strategies to try and come up with a way of doing something similar to this. with Lyumjev. I figure that what we're really looking for is an early large bolus and then allowing the system to bolus beyond that.
What I've done is ad a modification into the SMB sizing section such that when eventualBG is driven by UAMpredBG, and IOB is not excessive, the system can scale up the first SMB when deviation has grown significantly.
SMBs are scaled by dividing by target_bg/(UAMpredBG-target_bg) instead of the standard division by 2. This value is always limited by MaxBolus, which is a function o maxUAMSMBminutes.
Due to the insulin delivery, this then reduces both UAMpredBG and eventualBG, creating a limit on the ability of the system to continue to use the scaled microbolus. As soon as eventualBG drops back below the threshold (which I've set to 165 mg/dl), standard SMB behaviour resumes.
if (eventualBG > 165 && iob_data.iob < 8) { var scaleSMB = (target_bg/(UAMpredBG-target_bg)); var microBolus = Math.floor(Math.min(insulinReq/scaleSMB,maxBolus)*roundSMBTo)/roundSMBTo; console.error("SMB scaled by "+scaleSMB+" ;"); } else { var microBolus = Math.floor(Math.min(insulinReq/2,maxBolus)*roundSMBTo)/roundSMBTo; }
@tim2000s If you're using openaps, @Foxy7 has taken my scripts and has been updating them for 7.0 as well as adding his own changes.
@tim2000s @tynbendad i can make the code available as it's a bolt on to the main script, i need to tidy up my additional changes to strip out the bits very specific to us since we are not using this as an autobolus/no carb entry system, would take me a couple of evenings to sort out.
I believe it will only work for adults or those on around 1U/hr basal or more.
The initial set up is tailored to the individual since it works off the TDD and max sgv drop, but we have a script to calculate that.
There are also a couple of extra bits that could be converted to be additions to Dev, including an automatic temp target if sgv goes below a threshold set in a param file, useful for us to prevent the rig from using SMB overnight when insulin demand is below normal.
The set up works off two windows depending on the hour of the day, daytime "ludicrous" hours where the rig can go "all out" and sleep hours where it's much more gentle and if sgv conditions are met then has a lower target and also watches for sgv that are too low (as above).
I've also added a pre-breakfast routine via cron (not used by @tynbendad) to bring sgv up, takes at least two hours for us current basal is 0.4U/hr, prior to a massive insulin load 40 mins before eating breakfast to help reduce her post-breakfast highs.
The first changes got us from high 7s to high 6s and the recent pre-breakfast routine has reduced this to low 6s.
