Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 40 million developers.Sign up
0.7.0 release notes:
oref0 0.7.0 is a fairly major refactoring release that switches from the no-longer-maintained python-based
openaps toolkit to @ecc1's Go-based libraries for pump and CGM comms. This dramatically improves performance, particularly on the Pi Zero, and makes pump comms much more robust on all platforms. This has long been tested on the dev branch (over a year) by a large portion of the community.
There are no major algorithm changes in this release, but please see below for notes about supported hardware changes in this version and other changes. The docs have been updated to reflect 0.7.0 as the latest release.
Note for Carelink stick users: Carelink support is being deprecated and will no longer be supported, beginning in 0.7.0 and subsequent releases. If you are a legacy Carelink rig user, please install 0.6.3 from the archives, or look at the docs for current, recommended hardware options.
Note for TI stick users: There is no support for USB-connected TI sticks in 0.7.0. If you want to keep using the hardware, you'll need to jumper the header to the Pi or Edison, and re-flash the cc111x chip:
- There is support within
oref0-setup.shfor the TI stick when it the headers are jumper-connected to the SPI ports on the Pi (or Edison).
- There is no support in
oref0-setup.shfor UART-wired TI sticks in oref0-setup at the moment, but you can manually configure the software.
Detailed notes about what's included in this release
(in approximate diff order from https://github.com/openaps/oref0/pull/1036/files):
- Password checking for Raspbian on initial install
- Use node 8
- Refactor into oref0-bash-common-functions.sh
- autosens-history.js (research tool)
- oref0-autotune-dayofweek.sh (for manually autotuning weekdays vs. weekends differently)
- Dev / custom branch name support in openaps-bootstrap.sh / openaps-install.sh
- Option for insulin curve tuning of insulinPeakTime and insulinEndTime on manual autotune runs
- Additional autotune field showing how often a given hour's basal was tuned vs. interpolated
- oref0-bluetoothup.sh improvements
- Refactor cron jobs into oref0-cron-every-*.sh
- Various syntax fixes and refactoring
- New oref0-g4-loop.sh using Go binaries for G4 CGM comms
- Updates to support MDT Enlite CGM (including new oref0-mdt-update.sh, oref0-monitor-cgm.sh)
- New oref0-mmtune.sh to handle mmtuning using Go pump comms
- Various oref0-online updates
- Extensive updates to oref0-pump-loop.sh for Go-based pump comms etc.
- Updates to oref0-set-device-clocks.sh to use Go-based pump comms and only update CGM time where possible
- Extensive updates to oref0-setup.sh for Go-based pump comms etc.
- Add example json files for use with oref0-simple-simulator
- Updates to autotune to improve convergence
- Support for retrospective autosens
- Support for additional treatment data entry input methods
- If CGM data is changing less than 1 mg/dL/5m for 45m, cancel any high temps and shorten any long zero temps
- Support for custom SMBInterval
- Ignore SGVs older than the last cal record to avoid dosing for calibration jumps
- Remove old
openapsaliases (from Python code, now that we are using Go)
- Allow high_temptarget_raises_sensitivity for temptargets >= 101 and exercise_mode > 100 (vs. 111 and 105 previously)
- Support custom bolus_increment
- Update npm dependencies
- Additional unit tests
- Uploading the oref0 version and preferences file inside of devicestatus (useful for retrospective analysis)
- x12 pump users no longer need extra setup steps; this is taken care of in
- xdrip-js support in
- also now supports xdrip+ offline as CGM source, when rig is connected to the phone's hotspot, it can pull BGs from xdrip+ even when the phone is technically offline.
This is a patch release
Note: Existing 0.6.2 users do not need to update their rigs to obtain this release. This has minor updates to allow the setup process to complete without errors. Existing, working rigs are not impacted.
This fixes an issue where an existing dependency was moved as well as installing an updated version of node and mraa (which fixes the sporadic
Radio check failed. ImportError: No module named spi_serial error).
Existing, working rigs:
If you are X commits out of date, you do not need to update to 0.6.3 unless you have developed an
Radio check failed. ImportError: No module named spi_serial error.
However, don't feel otherwise obligated to update your rigs since the changes only impact the setup process of the rig - no algorithm or feature changes are included.
0.6.2 - minor changes including a Carelink fix. This version supports both Edison/Explorer and Raspberry Pi-based rigs.
- Fixes mraa for raspbian users with kernel 4.10+ (mostly affecting new Explorer HAT setups)
- Automates a setup step that was previously manual for Carelink users
- Ability for Enlite CGM users, particularly those using Carelink USB, to better control loop timing
- New /sgv.json route/endpoint, similar to xdrip+, for offline use with watchfaces, etc.
- Retries 3 times to get a Bluetooth IP address
- Avoids trying to set xdripaps "CGM" time, as it doesn't have a clock
- Autosens IOB calculations use the basal in effect at the time, not the current basal
Note: full support for use of Explorer HAT display is a WIP in 0.7.0-dev.
Many minor fixes & improvements.
• x12 fixes
• limit SMB zero temps to 60 minutes
• offline web page
• raise BG target for noisy / raw CGM data (#833)
• autosens is always enabled (to disable, set min/max to 1)
• faster autotune; and avoids raising basals from UAM carbs
• added cleaning to address full diskspace issues
• Carelink support re-added
• Suspends will count as zero IOB; no longer need to temp to zero and suspend (but people should make sure to change their settings for suspend-if-no-temp if they leave this as false, so pumps don't get unsuspended and issue SMB's while they're still disconnected)
• No longer warns in logs (causing excessive buildup) about DIA of 2 < 3. Defaults to 5, regardless, for curves, since 0.6.0
See http://openaps.readthedocs.io/en/latest/index.html for OpenAPS documentation. See #816 for specifics on what changed related to 0.6.1.
There are many changes in oref0 0.6.0. Before updating to 0.6.0, please read the following and the related documentation.
High level summary of changes, with more detail below:
- The default behavior for carb absorption has changed. See notes below.
- OpenAPS will now use the bottom BG target from the pump (not the range) by default.
- Exponential curves are now being used for insulin activity. The default is rapid-acting. Fiasp users should select ultra-rapid.
- SMB has been enhanced (eSMB). There is now also an option for SMB to always be on.
- oref0-setup.sh will not ask you for the passphrases for enabling SMB. They will only be enabled by adding the related preferences to your
- There is now an exercise mode, which allows high temp targets to also adjust sensitivity manually.
- There are added risk mitigation steps to prevent A52 pump errors. Bolus wizard is NOT recommended for use if you are using SMB’s (instead enter carbs through NS/IFTTT)
- The purple lines in NS have changed.
- Bolus snooze has been eliminated.
- 0.6.0 and beyond will no longer use git, which will reduce git-related errors.
More details on the above:
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.x, 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
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. Most experienced users end up with a much narrower target range, usually setting the low and high targets equal (100-100 or similar). So 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.
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"
- if set to "bilinear", OpenAPS uses the old insulin activity model
- 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
- 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
If you use the rapid-acting or ultra-rapid curves, you DIA will be set to a minimum of 5 hours, or longer. 6 hours is recommended as the starting point, especially if you see lows 4h+ after large meals.
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 minutes, 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.
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_modewhen 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%.
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.
Purple lines changing in NS
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: nightscout/cgm-remote-monitor#2919
- 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.
carbsReqThresholddefaults to 1 gram. Can be added to
preferences.jsonif you want to change it to only get carb notifications via Pushover for larger amounts.
Documentation is now updated to support this release
See http://openaps.readthedocs.io/en/latest/index.html for OpenAPS documentation. See openaps/docs#1104 for specifics on what changed related to 0.6.0