improving no-carb no-announcement no-bolus OpenAPS looping...

[tynbendad]

Is your feature request related to a problem? Please describe. We're using OpenAPS 0.6.2 with Fiasp and SMB-always to do a fully closed loop, i.e., no carb entries, no prebolus, no bolus, no announcements. This is a feature request to fully support that usage model, due to some limitations (possibly some of these have been or are being addressed already).

Describe the solution you'd like A clear and concise description of what you want to happen.

1. Autotune was recently way too aggressive on ISF (we were doing ok with it for a year, but once ISF got down to 20 it started to want to go towards 4 every day, which is way off) - if it can't be made "smarter" without carb entries, then perhaps alternative calculations of ISF can be an option (I have been semi-manually using TDD rules and autosens 8h/24h overnight sensitivities to come up with ISF, both have been helpful).

2. Autotune is also too aggressive on basals without entering carbs, although the autotune basal results do work, I've found less basal is better (even when I adjusted them more towards overnight autotune basal rates to avoid carb influence). Perhaps you can provide a % basal option to tune autotune - I have been using autosens.json (since I turned autosens off in crontab, see next issue) to turn down basals to a fixed 73% and getting better results. (A parallel option would allow me to re-enable autosens if next issue is fixed).

3. Autosens is too slow to return sensitivity to normal; e.g., when basals were too strong overnight, autosens would detect sensitivity and reduce basal, but not return sensitivity to normal for nearly half a day, since breakfast caused carbs to kick in which are ignored by autosens; this may be something already partially in progress as AndroidAPS has more autosens options. I also use "high_temptarget_raises_sensitivity": true to manually compensate for not having autosens enabled, in case of exercise, etc.

4. Hold-target profile vs Aggressive ISF profile - when near target with SMB-always you currently have to either set a higher than ideal target, weaker ISF, or a smaller SMB-minutes in order to avoid rollercoastering. Instead of sacrificing some of the benefit of SMB-always, I've been using a script to choose between "normal" and "aggresive" profiles, where if BG < 100 I lower SMB-basal-minutes to 5, set sensitivity_raises_target to false (to attain our normal target, since I have autosens fixed at .73), and set a slightly weaker than normal ISF. Once BG goes over 100, I reverse all of those, and set a slightly stronger than normal ISF (factoring in the fixed autosens).

Describe alternatives you've considered See above

Additional context I can provide more info as needed.

[tynbendad]

also see https://github.com/openaps/oref0/issues/1279 for details on how the strong ISF, used in (4) above, is calculated.

[scottleibrand]

@twain47 @stevebell117 have either of you had a chance to play with this yet?

[tynbendad]

5. this threshold that is hardcoded within determine_basal.js is hit too often with fast carbs, i've upped it to 30% instead of 20% on our rig: if ( maxDelta > 0.20 * bg ) { console.error("maxDelta",convert_bg(maxDelta, profile),"> 20% of BG",convert_bg(bg, profile),"- disabling SMB"); rT.reason += "maxDelta "+convert_bg(maxDelta, profile)+" > 20% of BG "+convert_bg(bg, profile)+": SMB disabled; "; enableSMB = false; }

[scottleibrand]

I wouldn’t object to making that percentage a hidden preference, with the default at the current value. Might be easiest to make that single change its own PR.

[tynbendad]

I wouldn’t object to making that percentage a hidden preference, with the default at the current value. Might be easiest to make that single change its own PR.

i'm still on an old commit of master 0.6.2, and also wouldn't know how to add a preference to the .js so i'll leave it to someone else.

[tynbendad]

FYI - i've enhanced the ability of original point #4 a bit since first posting here. I found that it helps to use bg delta and ".short_avgdelta " (a determine basal variable) to increase SMB minutes when its really needed, which enables lower SMB minutes to be used most of the time (e.g., our SMB minutes is usually set to 12 or 24 minutes and boosted to 40 only when these variables determine it is needed.)

attaching latest script, fwiw. i've also done this in aaps by modifying determinalbasal directly, as automation doesn't currently allow setting of smb minutes.

update-rates.sh.txt

[edited to add this missing piece] this is getdelta.js as used by update-rates.sh - reminder: i still use oref0 0.6.2 and am not sure if 0.7 has any changes that affect this:

!/usr/bin/env node

var cwd = process.cwd(); var glucose_data = require("/root/myopenaps/monitor/glucose.json"); var getLastGlucose = require('/root/src/oref0/lib/glucose-get-last'); var glucose_status = getLastGlucose(glucose_data); //console.log("glucose=" + glucose_status.glucose); //console.log("delta=" + glucose_status.delta); //console.log("short (<15m) avg delta=" + glucose_status.short_avgdelta); //console.log("long (<40m) avg delta=" + glucose_status.long_avgdelta); console.log(JSON.stringify(glucose_status));

[tynbendad]

as for original point #1&#3, we've recently been using "TDD" based rates (ISF,basal) as well as a new "sleepsens" which simply uses bg over the last few hours to determine if there are likely no carbs (bg within a certain range and all within a range of each other) and then adjust basal/ISF proportionate to the change needed to move the average bg in that time to the target, very similar to what autosens does but avoiding carb periods, so it only can take affect after several hours of no carbs, ie., when sleeping.

[edited:] and i should add "sleepsens" has a fast reversion back to the tdd-based rates (updates hourly) so that you're not stuck on lower sensitivity once you start eating, as we had with autosens.