Prep for oref0 0.6.0 release dev to master

[danamlewis]

Note: this next release will be a big release (from 0.5.5 to 0.6.0 to match the significant changes).

WARNING: This code has many changes compared to 0.5.5. Do not implement this branch for testing unless you review the diff and plan to watch it closely. Also, do not change default behaviors of features until you test the defaults of this branch. There may be some things not yet documented here that need to be documented; please comment on this thread or in channel to help note what needs documenting. Make sure you follow this PR so you will get notifications about changes to this branch. It is still changing feature-wise, so you will want to update as new features and bug fixes are added in.

See the bottom-most comment for how to install and run 0.6.0.

CHANGED: Default behavior change for carb absorption

In 0.6.0, carb absorption now uses a /\ shaped bilinear carb absorption model (replacing the previous --- shaped constant model for predicting the future absorption of newly entered carbs that haven't shown any effect on BG yet. As a result, the COB predBG purple prediction line immediately after entering carbs shows an S-curve shaped rise that starts out flat (in line with current BG trends), and then rises sharply after about an hour before flattening out.

• A typical meal absorption time of 3h is assumed when carbs are first entered, which is then extended over time, so that oref0 gradually relies more on actual observed carb absorption as carbs are absorbed. When the carbs are first entered, remainingCATime is set to 3 hours. When 50% of carbs have absorbed, the remainder (that aren't seen to be absorbing already) are predicted to take another 4.5h. And as COB approaches zero, remainingCATime will approach 6 hours.
• As in 0.5.3, any actual observed carb absorption will be predicted to continue into the future. The predCI assumed carb absorption described above only kicks in for carbs would not be absorbed within the current carb absorption time if the current carb absorption rate decreases linearly over that time.

CHANGED: Single BG target (not range) by default

Since many people seem to set their pump's bolus wizard target range rather wide, and then ask questions about why OpenAPS isn't doing more to prevent highs and/or lows, and since most experienced users end up with a much narrower target range, usually setting the low and high targets equal (100-100 or similar), we've changed the default BG target behavior to use only a single value as target, specifically the low end of the pump's bolus wizard target range. This was done by making override_high_target_with_low the default behavior, and adding a wide_bg_target_range preference (false by default) to override that and restore the previous default behavior if someone really wants a wide target range. This also makes it possible to set the high end of the bolus wizard target range to something high (like maybe 160 mg/dL) to prevent the pump from adding on a correction bolus when entering a BG value into the bolus wizard.

Exponential Curves

The code now supports three new configuration variables in preferences.json to allow exponential curves that better reflect the effects of insulin:

• curve, with legal values of blank, "bilinear", "rapid-acting" and "ultra-rapid"

1. if set to "bilinear", OpenAPS uses the old insulin activity model
2. If set to "rapid-acting" (now the default), the new curve model analyzed from publicly available data for Novorapid (Novolog) from Novo Nordisk is used. This curve should match well to Novorapid, Novolog, Humalog and Apidra and is set to peak at 75 minutes
3. If set to "ultra-rapid", the new curve model analyzed from publicly available data for Fiasp from Novo Nordisk is used, set to reach activity peak at 55 minutes

• insulinPeakTime, with legal values from 35 to 120. The value defines the minutes from bolus to peak. Note if you don't set it, the above mentioned peak defaults are used.
• useCustomPeakTime, which must be set to "true" for the customized insulinPeakTime value to take effect

In order to use the rapid-acting or ultra-rapid curves, your pump must be set to 5 hour DIA, or longer. 6 hours is recommended as the starting point.

The details of the curve calculations and discussions can be found PR #568

Enhanced SMB (eSMB)

Note: for folks with tiny basals (in this case, say <0.5u/hr), exercise even more caution, as additional tweaks may need to be made to SMB-related portions of the code.

The default behaviour for SMB is that the max bolus that can be delivered is no greater than 30 mins of basal insulin. An additional preferences value, "maxSMBBasalMinutes", has been added to allow SMB to deliver a different amount of insulin as an SMB. This gives the ability to make SMB more aggressive if you choose. As with standard SMB, it is triggered by temp targets, carb entries and a pump bolus.

Increasing "maxSMBBasalMinutes" will allow the SMB functionality to deliver more insulin, earlier in the SMB process.

"maxSMBBasalMinutes" can be added into myopenaps/preferences.json. It is recommended that the value is set to start at 30, in line with the default, and if you choose to increase this value, do so in no more than 15 minute increments, keeping a close eye on the effects of the changes.

It is not recommended to set this value higher than 90 mins, as this may affect the ability for the algorithm to safely zero temp. It is also recommended that pushover is used when setting the value to be greater than default, so that alerts are generated for any predicted lows or highs.

Other SMB adjustments include: The preference of enabling SMB to always be on. (Leaving this as false (off) means the existing SMB toggles for carbs, temp targets, etc. will be what drives SMB behaviors.)

Also adjusted: the basal and bolus distinctions - we eliminated bolus snooze
With eSMB now allowing no-bolus operation of OpenAPS, the distinctions between manual boluses and microboluses are breaking down, which prevents things like bolus snooze, which assume that automatically administered insulin should be classified as basal insulin / IOB and kept distinct from bolus insulin / IOB. Now that carb ratios can be properly autotuned, carb absorption is assumed to occur over less than DIA, the original need for bolus snooze is largely eliminated. The only remaining need for it might be if anyone is not entering carbs (either via NS or the pump), is manually bolusing for food, and then is expecting bolus snooze to cover until UAM kicks in, but that is likely a minimal or non-existing set of people. (Please test & let us know if there are any issues). Moving forward, this removes all references to bolus snooze, bolus vs. basal insulin, and other similar now-obsolete distinctions.

Autotune adjustments

Autotune now tunes carb ratio directly, eliminating the previously known upward bias on ISF and carb ratio. This also smooths out mealtime basals based on surrounding hours when there's no data for tuning a particular hour due to meals.

Behavior change recommended as a result: You should be logging rescue carbs (carbs eaten for lows or predicted lows) so that Autotune knows about them. (Rescue carbs can be entered into Nightscout directly (i.e. NS website care portal, IFTTT buttons, etc.) or via the pump as long as they are accompanied by a 0.1 bolus. Any carb entry on the pump without a bolus is ignored by OpenAPS).

CHANGED: High temp targets and exercise mode

How temporary targets impact operation of OpenAPS in 0.6.0:

• For SMB, a temporary target of 99 or lower can enable SMBs (when the option for SMBs from targets is turned to true). A temporary target of 101 (or higher) will disable SMBs.
• A temporary target of (anything less than normal target) will trigger the traditional "eating soon" mode for temporary basal rates - even if target is normally 130, and ES target is set to 100, that will trigger more basal (but per above, no SMB's, since that is >99).
• Historically, a high temp target solely caused the system to adjust the target and calculate behavior from there. (i.e. a normal target of 100, an 'activity mode' temp target for 2 hours of 140 means that OpenAPS would target 140 instead of 100 for those two hours, then revert upon canceling or expiration to targeting 100). Now, exercise_mode when enabled means that for a target of 111 or higher will create a manual sensitivity ratio, thus adjusting ISF and basals in proportion to this adjusted target. The goal of this is to recalculate IOB down to zero sooner ahead of and during activity, when the human knows this increased sensitivity is coming.

There is another variable, half_basal_exercise_target, for people to configure at which level they'd like basals to be at 50%.

More documentation of all the new options and autosens behaviors is needed before release. The conversation at https://gitter.im/nightscout/intend-to-bolus?at=5a00e1d986d308b755b70913 is a good place to start for that.

A52 risk mitigation by disabling SMBs with Bolus Wizard

In order to cancel out of any bolus wizard or other menus before bolusing and reduce the risk of pump A52 errors, oref0 now sends ESC three times to the pump before issuing an SMB.

In addition, the recommended method for using SMBs is to enter carbs via NS and easy bolus any desired up-front insulin (generally less than the full amount that would be recommended by the bolus wizard) and then let SMB fill in the rest as it is safe to do so. For situations where the bolus wizard is preferred, such as for carb entry by inexperienced caregivers, or for offline use, we feel that it is safer for OpenAPS to disable SMBs and fall back to AMA until the next meal. In addition to reducing the risk of A52 errors, disabling SMBs when the bolus wizard is in use leads to more predictable AMA behavior (instead of SMB zero-temping) for untrained caregivers in an environment that is usually more prone to walk-away pump communication issues.

For anyone who does not wish to follow this recommendation, and wants to use the pump bolus wizard with SMB despite the increased risk of A52 errors, this change adds support for a non-displayed preference defaulting to false. Anyone who wishes to explicitly acknowledge their increased risk tolerance can add that preference, with a value of true, to retain the old behavior.

• Using the pump bolus wizard to enter carbs will prevent SMBs from being enabled for COB as long as those carbs are active.
• Using the pump bolus wizard will prevent SMBs from being enabled for up to 6 hours by the "after carbs" or "always" preferences.
• If anyone wants to get around that, they can add A52_risk_enable (with the capital A) to preferences and set it to "true" to acknowledge and intentionally use that approach, which we know leads to increased A52 errors.

Other stuff:

• carbsReqThreshold defaults to 1. Can be added to preferences.json if you want to change it to only get carb notifications via Pushover for larger amounts.
• The purple lines in Nightscout have changed. We are removing aCOB (unused by everyone) and subbing in a "zero temp"-predBG line (ZTpredBG, etc.) showing how long it will take BG to level off at/above target if deviations suddenly cease and we run a zero temp until then. It then uses the lowest of those ZTPredBGs to ensure that we're dosing safely with UAM: if UAM predicts BG to stay high (based on deviations), but we wouldn't be able to prevent a low if those deviations suddenly stopped, we'll adjust the UAM-based insulinReq to be somewhat less aggressive. Conversely, if UAM shows BG ending up below target in 4h, but the ZTPredBGs show that we can safely zero temp and level out well above target, it will allow oref0 to be slightly more aggressive and bring BG down faster, safe in the knowledge it can zero temp if needed. NOTE: you will require an update to NS to view the new line. See: display ZT PredBGs, and forecast tooltips nightscout/cgm-remote-monitor#2919

Troubleshooting

1. Make sure you've fully installed (see next section), including remembering to re-set your preferences.
2. If you're getting "not enacted" in Nightscout but are looping fine, update your Nightscout to the latest dev.
3. Number one error is a typo in preferences.json - if you get "Could not parse input data: {SyntaxError: Unexpected end of input]" or similar input error, double check preferences.json

How to install 0.6.0

0.6.0 also has support for no-git-based-flow, to reduce git-related errors for most users. This is now the default path.

Follow the dev instructions in the docs: http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/update-your-rig.html

As always, after an update/runagain, you'll also want to go in and edit your preferences as well. Check the code diff here to see what the optional preferences are for 0.6.0 - they are not in the main docs yet.

Testing list before release

• different time zones
• PI/TI stick rig
• WW pumps

Release checklist

• Doc changes (follow 0.6.0 docs docs#1104 for the work in progress)
• Release notes

(Help wanted beginning to take some of these PR notes and translate to the docs - see high level list in openaps/docs#1104 and please target doc PRs related to 0.6.0 features to the 0.6.0-dev-docs branch - thanks!)

[johnmales]

Rc2 Working well here 👍

[danamlewis]

FYI to all following this thread: we have updated to 0.6.0-rc2. Current confirmation is that Edison/EB is working ok; Pi/TI is working ok (based on rc1 feedback so far, rc2 includes minor changes. I'd like to make sure we get checks on all the sensors - I know traditional Dexcom G4 is working ok; please sign off if you're a G5 user; Medtronic CGM user; or xdrip user. Also, need someone with WW pumps confirming this is still good as well, plus confirm time zones are ok. Thanks!

• Medtronic CGM ok
• Dexcom G5 ok
• xDrip ok
• ww pumps ok
• European time zones ok
• Australia time zones ok

[Nalla306]

Been working well on a WW 522 pump with G5 sensor.

Also tested for just over a day with the same pump but with xdrip on a spare android phone and separate rig.
UK timezone

[dirkgastaldo]

I’m running rc2 with a G5 on the iOS app and a 523 pump. All is well.

[achris2000]

We have been running rc2 on 2 edison/explorer rigs, one with WW 722 and another with WW 522, both with xdrip+. No issues.

[cjo20]

I think there might still be an issue with MDT CGM and the oref0-set-device-clocks.sh script. Unless changes have been made in the last few weeks, sending an UpdateTime command to the MDT pump causes the loop to fail - I've still got that line commented out in my local codebase. I'll try turning it back on when I get home tonight and let you know.

[cjo20]

Looks like it does cause an error for MDT CGM. Is there a way of determining which CGM device was selected inside oref-set-device-clocks.sh?

$ sudo ~/src/oref0/bin/oref0-set-device-clocks.sh
Waiting for ntpd to synchronize... OK!
Setting pump time to Wed Nov 22 18:17:00 GMT 2017
CommsException aa
Setting CGM time to Wed Nov 22 18:17:19 GMT 2017
openaps-use cgm: error: argument USAGE: invalid choice: 'UpdateTime' (choose from 'bolus', 'config', 'filter_glucose_date', 'filter_isig_date', 'iter_glucose', 'iter_glucose_hours', 'iter_pump', 'iter_pump_hours', 'mmtune', 'model', 'mytest', 'press_keys', 'read_basal_profile_A', 'read_basal_profile_B', 'read_basal_profile_std', 'read_battery_status', 'read_bg_targets', 'read_carb_ratios', 'read_clock', 'read_current_glucose_pages', 'read_current_history_pages', 'read_glucose_data', 'read_history_data', 'read_insulin_sensitivies', 'read_insulin_sensitivities', 'read_selected_basal_profile', 'read_settings', 'read_status', 'read_temp_basal', 'reservoir', 'resume_pump', 'set_clock', 'set_temp_basal', 'settings', 'status', 'suspend_pump', 'test_oref0_compat_menu')

This doesn't actually stop the loop working, so not critical to fix for this release.

[scottleibrand]

Ok, let’s move the MDT CGM clock set thing to a new issue then, as it’s not a new regression and not a blocker. Should be pretty straightforward once we refactor the MDT CGM stuff into oref0-pump-loop.

[dirkgastaldo]

Today I entered two boluses using Easy Bolus on my 523 pump, fairly soon after a small SMB had been delivered. Both of these Easy Boluses did not appear in Nightscout. I used CarePortal to enter the two boluses into Nightscout.

[JELCRAWFORD]

@dirkgastaldo - did the data appear in Openaps logic - coming up within the Openaps data for carbs and insulin (meaning they'd be in your database)? We periodically have instances where the data does not appear as a treatment in NS but Openaps knows about it (i.e. IOB and carbs are correct as reported by the openaps pill and logs). We have noticed this when using bolus wizard on the pump. Because we know the info has made it into the logic of Openaps, it is mostly just a nuisance that it doesn't show in NS. The communication between the pump and the rig is fine - data is read by Openaps w/o any troubles from the pump and is updated accordingly within the active looping process. In our instance, at least, the problem would seem to be on the NS side.

[efidoman]

👍 I'm running with g5, xdrip-js one-shot mode and 522. All is well.

[dirkgastaldo]

@JELCRAWFORD - I'm not sure if it was in my log. I will check next time it happens. Thank you. Makes sense.

[woodduckie]

Running a NAM 522 & overall things are working well. I really like the new prediction lines & the decrease sensitivity while low temp as an option to drive more aggressive correction.

Had an interesting scenario this afternoon, where the purple prediction lines were inverted / mislabeled. highest prediction line was IOB, middle line was COB, and the bottom line was labeled as Zero-temp. Had 3 COB, 0.49 IOB. LMK if I should report/document this elsewhere...

[scottleibrand]

They weren’t mislabeled. The COB and IOB lines are inverted like that when the absorption time for the remaining carbs is less than 1 hour, because the IOB curve always assumes current deviations will continue for an hour. UAM can be above or below any of the others, depending on the recent deviation trend.

[woodduckie]

Thanks Scott. Perhaps some clarification would be beneficial for the Zero-temp curve as well. Based on the fact that zero-temp curve is the lowest, I assume it takes IOB into account, but not COB.

[scottleibrand]

The zero-temp scenario is that deviations will immediately revert to zero, and that a zero temp will be run until BG starts rising and is above target. If that isn’t clear yet in the 0.6.0-dev docs, please do PR to clarify.