-
Notifications
You must be signed in to change notification settings - Fork 725
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.6.0 docs #1104
0.6.0 docs #1104
Conversation
Known needs for the documentation (check against notes in openaps/oref0#707 for some pre-written content that can be pulled in, but needs original content elsewhere):
|
|
Removing safety pass phrases - it's now just added by enabling in the preferences list.
* Updating killalls to oref0-pump-loop * Update usability-considerations.md
plus other cleanup
…/docs into parenthetic-exponential_iob_docs
I've taken a stab at a lot of this. Would love if anyone wants to do the glossary update...please :) |
Dana do you want to list sections in order of priority as you see it and I can aim to knock a few of them off. |
Thanks @sjolundjohn! I think the big one is 1) "understand determine-basal" page has not been updated in many moons, and could use an overall refresher that we might as well tie in with the 0.6.0 release, to show what's now included in the logs/pills/decision making. The other one is 2) updating the glossary, which also is pretty outdated. If you could take a stab at either of those, it'd be much appreciated. Thank you! |
Suggestion for the glossary: Other terms? |
@jdhigh will you open a PR (target 0.6.0-dev-docs) and start with adding those? Thanks! |
I think any new variables in openaps pull need elaboration if not done previously. The following come to mind: Sensitivityratio |
I’m on mobile right now but can do some of these tonigh and add to this PR. |
|
||
Defaults to false. When true, > 105 mg/dL high temp target adjusts sensitivityRatio for exercise_mode. | ||
|
||
**This majorly changes the behavior of high temp targets from before.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we provide a summary of how in a sentence or two? I don't understand this feature well enough to write this sentence though...
|
||
#### resistance_lowers_target: | ||
|
||
Defaults to falss. When true, will lower BG target when autosens detects resistance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo - falss should be false
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - fixing
@@ -128,6 +188,10 @@ Generally, you won't need to adjust any of the preferences below. But if you do | |||
|
|||
This is used to allow autosens to adjust BG targets, in addition to ISF and basals. | |||
|
|||
#### adv_target_adjustments: | |||
|
|||
This feature, previously enabled by default but defaulting to false in oref0 0.6.0 and beyond, lowers oref0's target BG automatically when current BG and eventualBG are high. This helps prevent and mitigate high BG, but automatically switches to low-temping to ensure that BG comes down smoothly toward your actual target. If you find this behavior too aggressive, you can disable this feature. If you do so, please let us know so we can better understand what settings work best for everyone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider change: "This feature was previously enabled by default but will now default to false(will NOT be enabled automatically) in Oref) 0.6.0 and beyond."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - fixing
|
||
#### wide_bg_target_range | ||
|
||
Defaults to false, which means by default only the low end of the pump's BG target range is used as OpenAPS target. This is a safety feature to prevent too-wide targets and less-optimal outcomes. Therefore the higher end of the target range is used only for avoiding bolus wizard overcorrections. Use `wide_bg_target_range: true` to force neutral temps over a wider range of eventualBGs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought there was an 'escape, escape, escape work around. Is this still required? If yes, do the instructions need to reflect the option to enact the work around to use pump BW?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You made this comment related to wide BG target range, but I think you are talking about esc-esc-esc for A52. That is just the new default, it's not a work around. the work around is the new variable described elsewhere.
|
||
(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.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re smb for tiny basals not recommended - what about tiny basal option? Is this something that has to be enabled specifically? If yes, is this where that statement should go?
> **FINAL NOTE:** A separate program—[oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js)—creates variables named `activity` and `iob`. Those two variables, however, are not the same as the `activity` and `iob` variables plotted in this documentation page. Those two variables are summations of all insulin treatments still active. The `activity` and `iob` concepts plotted here are expressed in percentage terms and are used to scale the `treatment.insulin` dosage amounts, so the units for the `activityContrib` and `iobContrib` variables are *units of insulin per minute* and *units of insulin remaining at each minute*, respectively. Because the `activity` and `iob` variables in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js) are just the sums of all insulin treatments, they're still in the same units of measurements: *units of insulin per minute* and *units of insulin remaining each minute*. | ||
> **A NOTE ABOUT VARIABLE NAMES:** A separate program—[oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js)—creates variables named `activity` and `iob`. Those two variables, however, are not the same as the `activity` and `iob` variables plotted in this documentation page. Those two variables are summations of all insulin treatments still active. | ||
|
||
>The `activity` and `iob` concepts plotted here are expressed in percentage terms and are used to scale the `treatment.insulin` dosage amounts, so the units for the `activityContrib` and `iobContrib` variables are *units of insulin per minute* and *units of insulin remaining at each minute*, repectively. Because the `activity` and `iob` variables in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js) are just the sums of all insulin treatments, they're still in the same units of measurements: *units of insulin per minute* and *units of insulin remaining each minute*. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure where the best spot for these are, but here's a stab at it to put wherever they are thought best:
Sensitivity Ratio - this is a modifier of autosense and is newly reported in 0.6.0 in your loop log and in the Opeanps Pill in NightScout. It will calculate the % of normal basal you need and adjust accordingly. If the number provided is less than zero, then Openaps has determined you are running more sensitive than usual which means that ISF is increased, and basal rates and correction rates are reduced accordingly. Alternatively if your Sensitivity Ratio is greater than 1, then you are running somewhat more resistant and ISF will be decreased, basal rates and corrections rates will also be increased accordingly. In example, a Sensitivity Ratio of .74 would indicate you currently require 74% of your normal basal, etc. Likewise, as Sensitivity Ratio of 1.24 would indicate you require 124% of your regular basal rate (other impacted dosing rates within Openaps would also be adjusted according to this).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great - thank you. Will add in around understanding-determine basal to help explain what people will see in the OpenAPS pills.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you meant to say less than 1, not less than zero, for an increased sensitivity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is already merged, can you please PR in any fixes you see like that?
> **FINAL NOTE:** A separate program—[oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js)—creates variables named `activity` and `iob`. Those two variables, however, are not the same as the `activity` and `iob` variables plotted in this documentation page. Those two variables are summations of all insulin treatments still active. The `activity` and `iob` concepts plotted here are expressed in percentage terms and are used to scale the `treatment.insulin` dosage amounts, so the units for the `activityContrib` and `iobContrib` variables are *units of insulin per minute* and *units of insulin remaining at each minute*, respectively. Because the `activity` and `iob` variables in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js) are just the sums of all insulin treatments, they're still in the same units of measurements: *units of insulin per minute* and *units of insulin remaining each minute*. | ||
> **A NOTE ABOUT VARIABLE NAMES:** A separate program—[oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js)—creates variables named `activity` and `iob`. Those two variables, however, are not the same as the `activity` and `iob` variables plotted in this documentation page. Those two variables are summations of all insulin treatments still active. | ||
|
||
>The `activity` and `iob` concepts plotted here are expressed in percentage terms and are used to scale the `treatment.insulin` dosage amounts, so the units for the `activityContrib` and `iobContrib` variables are *units of insulin per minute* and *units of insulin remaining at each minute*, repectively. Because the `activity` and `iob` variables in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js) are just the sums of all insulin treatments, they're still in the same units of measurements: *units of insulin per minute* and *units of insulin remaining each minute*. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IOBpredBG - also a variable reported in your Openaps Pill in Nightscout - this is a predicted BG curve that is based on insulin only. It is represented by the purple prediction lines
COBpredBG - a variable that uses carbs and insulin together in predicting the BG curve. Again it is represented by a purple prediction line. The default behaviour has changed for carb absorption, with the adoption of a /\ shaped bilenear carb absorption model. This line in your NS display will show an S-curve shape immediately after entering carbs 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 about 3 hours is assumed which is then extended overtime 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.
UAMpredBG's - this variable represents the impact of 'floating carbs' and insulin together in predicting the BG curve, giving a prediction line for the new feature Unannounced Meals (or carbs).
MINpredBG - this variable is the lowest predicted value that Openaps has made for your future BG.
Adding in a few terms and taking away bolussnooze for 0.6.0
Update docs to change autotune run time (4AM) and few non-substantive changes.
I think someone said there is an extra comma in the settings.json example? Is this correct now?
Merging these to prepare for oref0 0.6.0 release. big thanks to everyone who's contributed to this docs update! I'm sure we'll have more additions/things we find missing; if so, please target subsequent doc updates to the master branch. |
* Update nightscout-setup.md (#1110) Added a bit of info about alkaline voltage to complement the lithium info. * Update ifttt-integration.md (#1109) Updating steps for IFTTT and Google Assistant to increase clarity / reduce confusion. * Accessing your offline rig via SSH over Bluetooth... (#1018) works similarly to an SSH connection over WiFi. * Update pump.md * Update loops-in-progress.md (#1115) * Improving formatting for updating rigs * Update update-your-rig.md * avoid using the & symbol in API_SECRET per openaps/oref0#801 * Update autosens.md (#1116) * Update autosens.md This is something I experience at leat once a week following pizza, french fries our other restaurant food with work colleagues. I was not grapsping the algo order of trating things. this hopefully will help other also undertand and be prudent. I'm not sure that this part is still valid, I do not have “autosens_adjust_targets” in my 5.5 preferences.json : Finally, if you do not want autosens to adjusted target that can be turned off by editing preferences.json (shortcut command edit-pref) and setting the “autosens_adjust_targets” to false. * Clarify, and add additional info on 0.5.x-only caveats * Update update-your-rig.md (#1117) Two 'Alternateive Step 1'. I put 1a and 1b. Maybe 1 and 2 seems more logical to you? * bluetoothctl power off/on to fix hci0; cron stop/start * Update Loops in progress (#1120) First Pull Request and starting looping * Update loops-in-progress.md (#1122) * Update OpenAPS-install.md (#1121) Shortcut aliases updated and missing shortcuts added. Some basic classification of shortcuts added, too * Update PC-flash.md (#1123) Additional note added for the intel standalone windows driver no longer being available. * Update OpenAPS-install.md (#1126) Tiny typo fix to reflect correct file name. * more description for max basal rate (#1124) * more description for max basal rate added bit more description to the example, but mainly added key search terms to the text to help numpties like me find the answer quicker. Sorry - read the docs 101 * Clarify, and remove comment about 4.5 U/h default I don't have any reason to believe 4.5 U/h is a pump default: unless you have reason to believe otherwise, I suspect that's just what your pump happened to be set to the last time it was used. * Update autotune.md (#1128) Simple typo * 0.6.0 docs (#1104) * first draft of adding documentation for exponential curves * add the graphs * fixing graph URLs * add example exponential growth and decay graph * add exponential examples, and added descriptions * fix some spacing * fix bolding * change title wrapping * fixed dimensions in last graph * adjust x12 instructions to reflect automated steps (#1047) * Removing safety pass phrases to match workflow of 0.6.0-dev (#1107) Removing safety pass phrases - it's now just added by enabling in the preferences list. * Updating purple lines for 0.6.0 (#1108) * Updating killalls to oref0-pump-loop (#1111) * Updating killalls to oref0-pump-loop * Update usability-considerations.md * Updating troubleshooting re: 0.6.0 and git (#1112) plus other cleanup * Updated preferences with 0.6.0-dev related preferences (#1114) * Add offline hotspot network name and password * Update glossary.md Adding in a few terms and taking away bolussnooze for 0.6.0 * Clarify * Update OpenAPS-install.md Update docs to change autotune run time (4AM) and few non-substantive changes. * clarify * Typo and clarifications * adding @JELCRAWFORD's glossary additions * Update x12-users.md (#1127) I think someone said there is an extra comma in the settings.json example? Is this correct now?
Please add to this PR any notes about docs that need to be written, or please target any PRs here that have 0.6.0-related content. Thanks!