+
+You can also create desktop widgets on your Android device to directly enter data into nightscout (just like IFTTT with workflow on Apple devices) using tools like HTTP Request Shortcuts from the play store. Examples toward end of document for this tool.
+
+**Note for iPhone users** In June 2018 Apple released iOS 12 which renamed Workflow to Shortcuts and unfortunately
+removed the IFTTT integration. You can however achieve the same result of a button press on an iPhone sending
+instructions to your Nightscout site by following the [iPhone Shortcuts Integration](https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/iPhone%20Shortcuts%20Integration.html) instructions.
+
+## IFTTT Setup for phones
+
+* First we need to gather one thing called your "hashed API Secret". This is basically your Nightscout site's API secret, but scrambled into a confusing long string for safety. Find out what your NS hashed secret key is by running the command to find out: `nightscout hash-api-secret
+
+ +
+
+The second method involves installing an application called xDripAPS onto your rig. The details for setting up xDripAPS are described in the [section below](https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/offline-looping-and-monitoring.html#xdripaps-offline-looping-for-users-of-the-xdrip-android-app). The naming can be confusing. xDrip+ (maintained by [@jamorham](https://jamorham.github.io/#xdrip-plus)) is the app being actively developed. While Google may lead you to several older versions of the xDrip/xDrip+ Android app, you can always get the latest version here:
+ * xDrip+: [https://github.com/NightscoutFoundation/xDrip](https://github.com/NightscoutFoundation/xDrip)
+ * There is no direct iOS version of xDrip+. [Spike](https://spike-app.com/) is a different app with a different set of features.
+
+### B. Plug CGM into rig (easiest for G4/G5)
+
+**EASIEST:** For either Android or iPhone G4/G5 users, you can plug the CGM receiver directly into your rig via USB. This will pull BGs into the rig directly from the receiver and be used for looping. If you are a G4 user, this should also bring RAW BG data into the rig during sensor restarts or ??? times (although multiple users with pediatric model G4 receivers have reported inability to obtain raw data. This seems to be related to a firmware difference between adult and pediatric G4 receivers). The rig will loop using RAW BGs so long as the BG value is under 150 mg/dl. A few notes about how to make the direct-receiver configuration work:
+
+ * Explorer boards built prior to late January of 2017 are not always working well/automatically with a CGM receiver plugged in. These boards can be identified by looking to see if they say "2016" on the board's label tag, as shown in the photo below. The boards can be fixed to use a CGM receiver by making a single trace cut, but doing so will disable the board's the ability to re-flash your Edison. Please make sure you have a second Explorer board or another base block or breakout board that you can use to re-flash the Edison if needed before considering this modification. For more details, see [this issue](https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/issues/14), and if you decide to make the cut, see [this document for details on how to cut the copper trace from pin 61 of the 70 pin connector](https://github.com/EnhancedRadioDevices/915MHzEdisonExplorer/wiki#usb-otg-flakiness). Cut in two places and dig out the copper between. Cut by poking a razor point in. Avoid the narrow trace above the one being cut.
+
+ * Explorer Boards that shipped at or after the end of February 2017/first week of March 2017 should enable users to simply plug in the CGM receiver to the OTG port, and a USB battery into the UART port, in order to run offline and pull BGs from the receiver. Those boards will have a label of v1.2 2017.
+
++ +
Click here to display images of the xDrip settings screens
+ +  +  + +
+
+ +
++ +
Click here to display images of the Explorer Board to help identify which version you have
+ +  + ++ + * The order of the cables and ports is important. The OTG cable must be plugged into the OTG port on the Explorer board. There are two kinds of OTG cables; (1) both ends are micro-USB like the one you can [order here](https://www.amazon.com/dp/B00TQOEST0/ref=cm_sw_r_cp_api_Niqfzb3B4RJJW) or (2) one end is USB and one end is micro-USB like the one you can [order here](https://www.adafruit.com/product/1099). Both will work, but if you have the second kind, that cable must be the one plugged into the rig directly, and the other non-OTG cable must be plugged into the receiver (as shown in photo below). That port is labeled on the underside of the port, it is the one closest to the lipo battery plug. A USB battery or wall charger must be plugged into the UART port to supply sufficient voltage to the OTG port (the lipo battery alone is not enough to power the OTG port). + +
+
+ +
++ +
Click here to display images of the Explorer Board with the OTG cable plugged into the OTG port
+ + + ++ + * If you are using this configuration for G4 receivers and (1) are online and (2) want to see RAW BGs in NS, then you must remember to add `rawbg` to your ENABLE line in your Heroku/Azure settings. You will also have to go to your Nightscout site's settings and select "always" from the Show RAW BG options. You will also have to select `g4-raw` (if on master branch) or `g4-upload` (if on dev branch) as the CGM type in the loop setup script. + +### C. Send G5 or G6 BGs direct to rig (xdrip-js, Lookout/Logger) + +On your OpenAPS rig, the xdrip-js library can read directly from the Dexcom transmitter, similar to xdrip+ on the phone. It can be configured to replace either the Dexcom receiver or the iPhone Dexcom mobile app / xdrip+ on the phone. In Alternate Channel (receiver emulation) mode, xdrip-js can be used simultaneously with a phone app. You cannot use more than one rig with xdrip-js alongside a phone, but it is possible to configure one rig to emulate a phone and one rig to emulate a receiver if desired. (The gitter channel for xdrip-js and related stuff is at [https://gitter.im/thebookins/xdrip-js](https://gitter.im/thebookins/xdrip-js) - head there for questions about setup.) There are two ways to use the xdrip-js library (you can only use one at a time on the rig): + +#### Lookout/Logger: + +The oref0-setup option for `xdrip-js` installs Logger by default. + + * **Lookout** - this application runs on your rig and uses the xdrip-js library to read from the G5 or G6 transmitter directly. It uses the transmitter's built-in calibration algorithm, and you can enter BG calibrations either from the receiver or from a browser on your phone or computer, when connected to a web server that Lookout manages on your rig. The Lookout web pages also allow you to view CGM, pump, and OpenAPS status. Regardless of whether you use the receiver or Lookout to enter calibrations, they will be sent to the transmitter and both devices will report the same resulting BG values (though they may take a reading or two to 'catch up' after a calibration). Depending on your phone's hotspot capabilities, you may be able to access the Lookout web server even when cellular data is not available. Lookout will read Dexcom transmitter BG data and update OpenAPS locally (via xDripAPS), so your rig will continue to loop while offline, as well as send to Nightscout when your rig is online. Since Lookout uses the official transmitter calibration algorithm, it still requires sensor restarts every 7 days, with 2-hour warmups, and cannot be used with transmitters that have reached the Dexcom expiration (105-112 days from their first use). + + * **Logger** (xdrip-js-logger) - this application is restarted regularly from your rig's crontab, and uses the xdrip-js library to read from the Dexcom G5 or G6 transmitter directly. It can use non-expired or expired transmitters. It leverages both the in transmitter session calibration algorithms and falls back to LSR calibrations automatically when the sensor has an issue or stops (i.e. after 7 days). For LSR calibration, Logger uses the raw filtered/unfiltered values from the Dexcom transmitter, instead of the official calibrated value, and so can be used with transmitters that are past their standard expiration (including those with replaced batteries). Logger also has the ability to reset an expired transmitter to new so that in transmitter calibrations can be used (even for battery replaced transmitters). Calibrations for Logger are entered through nightscout as BG Treatments, or through the pump (e.g., via the Contour Next Link meter that automatically loads to the pump), or through the command line. BG data is sent to both OpenAPS (via xDripAPS) locally, so your rig will continue to loop while offline, and include Nightscout when online. You can use a receiver with Logger, but the BG values will not necessarily match between the two, and the calibrations on the receiver must be entered separately. Nightscout is the user interface for entering calibration and getting sensor status / requests such as "Needs calibration" as Announcements. Nightscout also shows the transmitter battery status, voltages, resistance, temperature every 12 hours as a note. Nightscout is also used to let Logger know that a new sensor has been inserted and to start a sensor. You can set the time back on a start - i.e. 2 hours (if you soaked the sensor). Logger has command line scripts that run on the rig (cgm-reset, cgm-start, cgm-stop, cgm-battery, and calibrate). There is currently no local web browser for entering calibrations or interacting with Logger, so the only way to view its data is through a terminal, xDripAPS web server, or Nightscout. **NOTE: for expired transmitters, Logger LSR calibration method is an approximation of what the Dexcom transmitter does internally so caution and serious oversite and testing should be exercised when using.** + +> NOTE: Lookout, Logger (xdrip-js-logger), and xdrip-js library should be considered a WIP (Work In Progress), i.e., do not use if you cannot watch your BG and loop very carefully, and tolerate issues, failures, idiosynchrosies. Also please plan on contributing either through testing and feedback, updates, documentation, etc. + + A summary of their features: + +
| Feature | +Lookout | +Logger | +
|---|---|---|
| Still unfinished, i.e., a work-in-progress? | +Yes | +Yes | +
| Rig continues updating BG and looping while offline using xdripAPS? | +Yes | +Yes | +
| Offline (network) mode supports backfill to Nightscout? | +Yes | +Yes | +
| Offline (away from transmitter times) supports backfill? | +Yes | +Yes | +
| Uses Dexcom official calibration? | +Yes | +Yes | +
| Can use with expired/battery replaced transmitter? | +Yes | +Yes | +
| Can interact with rig-hosted web page? (e.g., for calibration, start/stop sensor) | +Yes | +No, can use rig cmd line while offline | +
| Also able to calibrate and start/stop sensor thru receiver? | +Yes | +Yes, for non-expired transmitter/session | +
| Calibrate through Web/Nightscout? | +Yes (local rig Web UI) | +Yes | +
| Calibrate through pump-connected meter (e.g., Contour Next Link)? | +No | +Yes | +
| Calibrate from command line? | +Yes | +Yes | +
| Linear Squared Regression Calibration | +Yes, for > 7 day extension | +Yes | +
| Single Point Linear Calibration | +Yes, for > 7 day extension | +Yes | +
| Calculate and send Noise with entries | +Yes | +Yes | +
| Calculate glucose trending | +Yes | +Yes | +
| Start Stop Sensor | +Yes via UI | +Yes via NS/cmd line | +
| Reset Expired Transmitter | +Yes via UI | +Yes via cmd line | +
| Support mmol | +Yes | +Yes, in NS and for Meter-Pump Calibration | +
| View transmitter battery/resistance levels | +Yes via NS CGM pill | +Yes | +
+
+ +@:5000/api/v1/`
+
+A few notes to clarify:
+ * enter "http://" NOT "https://
+ * is the plain-text API secret used when creating your online Nightscout instance.
+ * is the IP address of your OpenAPS rig assigned by your WiFi, WiFi hotspot, or Bluetooth PAN tether connection. It will usually take the form of: `192.168.xxx.xxx`.
+
+
+
+##### Entering multiple REST URLs
+
+* If you need to constantly switch between two or more "personal" networks, you would have to edit the `Base URL` each time with the new IP address. To simplify this process, multiple URLs can be added to the REST API Upload `Base URL` setting, and xDrip+ will attempt to upload to each URL. NOTE: the URLs must be "space" delimited. For example:
+```
+http://@:5000/api/v1/ http://@:5000/api/v1/
+```
+* OpenAPS/xDripAPS will NOT upload CGM data to Nightscout. You can enter both your xDripAPS URL and your Nightscout URL, again separated by a space character. For example:
+```
+https://@.herokuapp.com/api/v1/ http://@:5000/api/v1/
+```
+Be careful when entering the addresses - xDripAPS uses the http protocol, Nightscout uses the https protocol.
+
+NOTE: To ensure your OpenAPS rig recieves glucose data through XdripAPS please confirm the following setting is UN-CHECKED : Open XDrip + and navigate to Settings > Cloud Upload > Nightscout Sync (REST-API) > Extra options > "Skip LAN uploads". This setting is checked by default, however does not allow your openaps rig to recieve glucose data when tethered offline.
+
+
++ +
Click here to expand the setup instructions for using oref0-setup.sh
+ + +##### Setting up your OpenAPS rig +Install OpenAPS as per the documentation. While running the oref0-setup script you will be prompted to specify a CGM source. Enter "xdrip" (without the quotes). The setup script takes care of the rest! Follow the remainder of the setup script as normal. + +##### Connecting your Android phone and your OpenAPS rig +In order to allow xDrip+ app on your Android phone to send CGM data directly to xDripAPS on your OpenAPS rig, both need to be connected to the same "personal" network. Note that an internet connection is not required - this solution allows you to loop without internet connectivity. + +There are two approaches for establishing a "personal" network between your phone and your OpenAPS rig. The first is to run a WiFi hotspot on your phone and connect your OpenAPS rig to the WiFi network your phone exposes. This is the easiest option, but there are two drawbacks - it drains your phone battery quickly, and most phones cannot connect to a normal WiFi network while the WiFi hotspot is enabled (they can connect to the internet via 3G/4G when coverage is available). + +The other option is to enable Bluetooth PAN tethering on your phone and have your OpenAPS rig connect to it. Battery drain is minimal and the phone can still connect to a normal WiFi network for internet access when available as well as to 3G/4G networks when WiFi is not available. (Some users have their OpenAPS rig permanently tethered to their Android phone. The drawback is that connecting to the rig via SSH in this configuration is only possible by using an SSH app on the phone or by connecting it to a computer using a USB cable) + +Instructions on both WiFi and Bluetooth tethering can be found in the main OpenAPS documentation. + +##### Configuring the xDrip+ Android app +First, determine your OpenAPS rig's IP address within your "personal" network. If you can open a terminal session to your rig via serial, then `ifconfig wlan0` (when using the WiFi hostpost option) or `ifconfig bnep0` (when using bluetooth tethering) will display your IP address. Alternatively, you can use an Android app - there are lots of "Network IP Scanner" apps in the Play store. The Hurricane Electric Network Tools app works with both the WiFi hotspot and BT tethering options. + +Next, open xDrip+ and navigate to Settings > Cloud Upload > Nightscout Sync (REST-API) and enable it. In the `Base URL` setting, configure the following URL + +`http://+ +#### Known limitations of xDripAPS +* xDripAPS does not process anything other than CGM data. If you use the xDrip+ Android app to enter carbs, these will not be processed by OpenAPS. If you upload to Nightscout simultaneously, OpenAPS will download the carbohydrate entries from Nightscout once it has internet connectivity. For alternative solutions for offline carb entry see above. +* Changing between xDripAPS and Nightscout as sources for CGM data may lead to problems with the calculation of carbohydrate absorption. This can be avoided by leaving the OpenAPS rig tethered to the phone via Bluetooth or WiFi as long as there are carbs on board. + +#### Manual installation steps for xDripAPS + +It is strongly recommended that you use the oref0-setup script as described above, rather than installing manually. + +
+
+ +
++ +
Click here to expand the setup instructions for installing manually (not recommended)
+ + +1. Install SQLite3 - + + a. Raspbian - + ``` + apt-get install sqlite3 + ``` + + b. Yocto - + ``` + cd ~ + wget https://sqlite.org/2016/sqlite-tools-linux-x86-3150200.zip + unzip sqlite-tools-linux-x86-3150200.zip + mv sqlite-tools-linux-x86-3150200 sqlite + ``` + +2. Get dependencies - + ``` + pip install flask + pip install flask-restful + ``` + +3. Clone this repo - + ``` + cd ~ + git clone https://github.com/colinlennon/xDripAPS.git .xDripAPS + ``` + +4. Create directory for database file - + ``` + mkdir -p ~/.xDripAPS_data + ``` + +5. Add cron entry to start the microservice at startup - + e.g. - + `@reboot python /home/root/.xDripAPS/xDripAPS.py` + +6. Configure the xDrip Android app - + `xDrip > Settings > REST API Upload > Set Enabled and enter Base URL: http://[API_SECRET]@[Pi/Edison_IP_address]:5000/api/v1/` + + (Note: Enter your plain-text API_SECRET in the Android app, not the hashed version of it). + + +7. Use the microservice within OpenAPS + e.g. + ``` + openaps device add xdrip process 'bash -c "curl -s http://localhost:5000/api/v1/entries?count=288"' + openaps report add monitor/glucose.json text xdrip shell + ``` + +diff --git a/docs/docs/Customize-Iterate/on-the-go-wifi-adding.md b/docs/docs/Customize-Iterate/on-the-go-wifi-adding.md new file mode 100644 index 000000000..7c67e91ad --- /dev/null +++ b/docs/docs/Customize-Iterate/on-the-go-wifi-adding.md @@ -0,0 +1,43 @@ +# How to add new wifi network(s) + +Adding a wifi network is pretty easy once your initial loop has been setup. Simply enter `edit-wifi` (which is a shortcut command for `nano /etc/wpa_supplicant/wpa_supplicant.conf`. + +First check that `wpa_supplicant.conf` doesn't contain `update_config=1` + +If it does, delete this from the file as it will interfere with switching between wifi networks. + +You can then add wifi networks using the following template: + +``` +network={ + ssid="my network" + psk="my wifi password" +} +``` +Newer versions of the setup script enact the editor `vi` instead of `nano`. The important commands to know in vi are `i` to turn on insert mode on and `esc` to turn it off. Once insert mode is on, edit your file and when you are done hit `esc`. To exit vi you have a few choices: `:q!` will exit and not save any changes, in case you mess up badly. `:w` will write your changes and keep you in vi. Once you are satisfied with your edits, `:wq` will write your changes and quit vi. + +Older version use `nano`, which is more intuitive, but doesn't work well over USB serial console connections, unless your window is exactly 80 characters wide. If you're using `nano`, you can save the edits to the file using `control-x`, `y`, and `enter`. If you mess up, you can do `control-x` and `n`. + +Helpful tip: Add a couple "blank" networks to the file (see screenshot below), so that if you ever need to add new wifi networks while on-the-road, the process will be much faster and easier. You'll only need to edit the network name and password then...instead of needing to type in the whole string of the template. + + + +Some wifi networks may require you to enter a login name and password at an initial screen before allowing access (such as many school wifi networks). Some users have success in using the following wpa network settings for those types of networks: + +``` +network={ + scan_ssid=1 + ssid="network name" + password="wifi password" + identity="wifi username" + key_mgmt=WPA-EAP + pairwise=CCMP TKIP + group=CCMP TKIP WEP104 WEP40 + eap=TTLS PEAP TLS + priority=1 +} +``` + +Other wifi networks require you to accept a terms and conditions (or enter a room number and last name) prior to allowing access. For example, Starbucks coffee shops and many hotels. These networks are termed "captive" networks and connecting your rig to captive networks is currently not an option for a standard rig setup. A device like [Hootoo mobile router](https://www.hootoo.com/network-devices.html) is an excellent tool in these situations. A Hootoo mobile router will login to the hotel/Starbucks network via an app on your phone, and then the Hootoo "bridge" (non-technical word) the hotel's network for your rig to be able to connect to once you add the network to the rig. + +If you use priority (priority=1) to select among more than one network at a time, just remember that HIGHER numbers are HIGHER priority. diff --git a/docs/docs/Customize-Iterate/optimize-your-settings.md b/docs/docs/Customize-Iterate/optimize-your-settings.md new file mode 100644 index 000000000..316ebeb76 --- /dev/null +++ b/docs/docs/Customize-Iterate/optimize-your-settings.md @@ -0,0 +1,33 @@ +# Optimizing your settings + +Once you've been looping, you may look at your graphs and wonder how to achieve different results. It takes some time to do, but optimizing your settings is one of the keys to improving things, once you have basic looping up and running. + +Note: if you're not familiar with the approach of optimizing settings, it's very important to understand that you should only change ONE thing at a time, and observe the impact for 2-3 days before choosing to change or modify another setting (unless it's obviously a bad change that makes things worse, in which case you should revert immediately to your previous setting). The human tendency is to turn all the knobs and change everything at once; but if you do so, then you may end up with further sub-optimal settings for the future, and find it hard to get back to a known good state. + +Think about this: when many people start looping, they often have too high basal and too low carb ratio or ISF. What this means is they're using basal insulin around mealtimes to compensate for not usually giving the amount of insulin needed for food. When you go on a DIY closed loop and the system begins to help with adjusting insulin for BGs, it can become apparent that settings need to be tweaked. Here are a series of general approaches you can take for optimizing your settings, with example patterns: + +## Using Autotune + +The most powerful tool at your disposal for adjusting settings is Autotune, which you can run nightly as part of your loop, and which will automatically start adjusting your basals, carb ratio, and ISF based on observed trends. If your pump settings are too far from what autotune thinks is necessary, it won't be able to adjust further without some manual action on your part, so you'll want to review autotune's recommendations periodically and consider adjusting pump settings in the recommended direction. As noted before, it's best to change things gradually, and observe the results before changing additional settings. + +In oref0 0.6.0 and beyond, autotune runs every night on your rig automatically. You can `cat-autotune` to view your autotune recommendations log. ([More about Autotune in the docs here](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/autotune.html).) + +## Frequent negative IOB at the same time every day + +Negative IOB happens when you are getting less insulin than your normal basal amount. We created [Autotune](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/autotune.html) to help deal with these situations and to automatically tune your basal rates for any recurring patterns where you need more or less basal. However, if you're not running autotune, and you're observing patterns of negative IOB (for more than a day or two in a row), indicating a trend, you may need to change your settings. Things to test include: + +* Adjusting your DIA. In oref0 0.6.0 and beyond, it will default to using a DIA of 5, unless the value is set higher in the pump. It is also very common for OpenAPS users to have DIA of 6 or 7 set in their pump. +* Basal rates are too high for the hours preceding the pattern of negative IOB. +* ISF is wrong. (Usually not this; start with testing and tweaking basals and DIA first.) + +## Hills and valleys / Peaks and troughs / Up and down patterns + +Sometimes people observe "roller coasters" in their BG graph. Remember this is all relative - to different people, BG rising and falling by 20 points may or may not be a big deal (but a 50 point rise or drop might feel like a roller coaster). + +First, you should eliminate human behaviors that cause these. Usually, it's things like giving a traditional dose of "fast carbs" (such as 15g+ of sugar, glucose tabs, candy, etc.) that is more than needed for a low or a pending low. Remember the system is reducing insulin, and so you often need way fewer carbs to deal with a low, so you may rise afterward if you do too large of a carb correction. If you're unsure how large a carb correction is needed, OpenAPS has the ability to send carbsReq notifications via Pushover. Overcorrections like that generally can't be fixed by changing settings: you have to also change behaviors. Ditto for human-driven drops; e.g. by rage bolusing or otherwise bolusing too much when BG is high. A better approach is to set a low temporary target, which asks OpenAPS to do "more", but will still keep you in a safe range. + +Human behaviors set aside, if you are still seeing hills and valleys in your BG graphs, consider the following: +* ISF may be off, so you may want to raise ISF to make corrections less aggressive. Remember, make small changes (say, 2-5 points for mg/dl, and .5 or less for mmol) and observe over 2-3 days. Before changing ISF or any other setting, check to see what autotune recommends. +* If you're seeing highs followed by lows after meals, CR may need adjusting. One common mistake is to compensate for rapid post-meal rises with a very aggressive (low) CR, which then causes subsequent low BG. One tool for preventing meal spikes include setting an "eating soon" low temp target before and/or right after a meal, to get more insulin started earlier, and then allow OpenAPS to reduce insulin once the temp target expires, to help prevent a post-meal low. Similarly, a small manual "eating soon" bolus up to an hour before a meal, or a larger prebolus right before a fast-carbs meal, can help match insulin timing to carb absorption without increasing the total amount of insulin delivered (and subsequently causing a post-meal low). ([Here are some tips on using temp targets](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/usability-considerations.html#how-can-you-make-adjustments-to-insulin-delivery-while-on-the-go-optimizing-with-temporary-targets), and you can [use IFTTT to make it easy to enter them from your phone or watch or device of choice](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/ifttt-integration.html).) + + diff --git a/docs/docs/Customize-Iterate/oref0-runagain.md b/docs/docs/Customize-Iterate/oref0-runagain.md new file mode 100644 index 000000000..0e9c61995 --- /dev/null +++ b/docs/docs/Customize-Iterate/oref0-runagain.md @@ -0,0 +1,19 @@ +# Re-running the setup script + +In the future, you may want to run the setup script again (such as when you want to come back and turn on new, advanced features), or if someone asks you to "cat your runagain", which means to display this file so we can analyze the contents. + +**First**: `cd ~/myopenaps && cat oref0-runagain.sh` to see what options you have saved in there. + +If you want to **edit** the file: `cd ~/myopenaps && nano oref0-runagain.sh` to edit, ctrl-x to save when finished. *Make sure to change `myopenaps` to your openaps directory name if you chose something non-standard when you ran oref0-setup originally.* + +To **run again**: `bash ~/myopenaps/oref0-runagain.sh` will run oref0-setup with the options you have saved in the runagain file. + +Don't have a runagain or want to start fresh? `cd && ~/src/oref0/bin/oref0-setup.sh` + +Because you're re-running, **remember you will need to also re-do adjustments to your `preferences.json` once you finish re-running setup with either of the methods above. You can do that by `edit-pref`.** + +Note: The following items are not impacted by re-running the setup script: + +- Wifi settings +- Bluetooth tethering (assuming you have not changed the Bluetooth address you entered during the initial setup) +- Papertrail settings (assuming you are update to the openaps directory name used in your intial setup, typically `myopenaps`) diff --git a/docs/docs/Customize-Iterate/oref1.md b/docs/docs/Customize-Iterate/oref1.md new file mode 100644 index 000000000..811576764 --- /dev/null +++ b/docs/docs/Customize-Iterate/oref1.md @@ -0,0 +1,105 @@ +# oref1 (super advanced features) + +NOTE OF CAUTION: +* oref1 is different than oref0, the baseline "traditional" OpenAPS implementation that only uses temporary basal rates. +* You should have run oref0 (basic OpenAPS looping) for more than two weeks, and be very aware of all the types of situations in which your rig might fail, before you enable oref1-related features. +* If running more than one rig, you will want to make sure all rigs are running an Super Micro Bolus (SMB) aware oref0 version (release 0.5.1 or higher) before enabling Super Micro Bolus (SMB) on any of them (even if Super Micro Bolus (SMB) is not enacted on all rigs, all rigs need to know about it). +* Super Micro Bolus (SMB) is about front-shifting insulin activity. It is NOT a synonym for no-bolus, although it can enable no-bolus options (with very close monitoring and testing). But you should first test Super Micro Bolus (SMB) with your existing bolus method. + * Take steps one by one to turn on Super Micro Boluses; validate that Super Micro Boluses are working and understand if it is working for you; and only then should you approach changing behaviors related to meal-time boluses. + * Do not combine turning on Super Micro Bolus (SMB) and trying to do no-bolus or partial-bolus meals at the same time. +* Make sure you have your easy bolus button on ([details here](https://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/collect-data-and-prepare.html#easy-bolus-button)) and know how to deliver boluses without using the bolus wizard. +* See this page on [optimizing settings](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/optimize-your-settings.html#optimizing-your-settings) for reminders and tips on changing one thing at a time. + +## Only run oref1 with the following caveats in mind: + +* Remember that you are choosing to test a still-in-development feature. Do so at your own risk & with due diligence to keep yourself safe. +* You should have run oref0 (basic OpenAPS looping) for more than two weeks, and be very aware of all the types of situations in which your rig might fail. +* **We are requiring that you also have run autotune prior to enabling Super Micro Bolus (SMB).** Why? Because if you have wonky ISF settings, for example, you may be more likely to go low or high with Super Micro Bolus (SMB). It will help a lot to have run autotune and be aware if the algorithm is recommending changes to ISF, basal, and/or carb ratio. You are not required to run autotune automatically/nightly as part of your loop with Super Micro Bolus (SMB); but you should at least run it manually and get an idea for how confident you are in your settings being right or not; and keep that in mind when evaluating Super Micro Bolus (SMB) outcomes for yourself. +* You should have basals of > 0.5 U/hr. (Super Micro Bolus (SMB) is *not* advisable for those with very small basals; since 0.1U is the smallest increment that can be bolused by Super Micro Bolus (SMB). We also added a basal check to disable Super Micro Bolus (SMB) when basals are < 0.3 U/hr. If your "regular" basal in the pump is 0.3 U/hr and autosens or autotune has adjusted your basal rate to below 0.3 U/hr, Super Micro Bolus (SMB)s will be disabled as well.) +* Read the following: + * A. The updated reference design ([https://openaps.org/reference-design/](https://openaps.org/reference-design/)) that explains the differences between oref0 and oref1 + * B. The following two posts for background on oref1: + * [https://diyps.org/2017/04/30/introducing-oref1-and-super-microboluses-smb-and-what-it-means-compared-to-oref0-the-original-openaps-algorithm/](https://diyps.org/2017/04/30/introducing-oref1-and-super-microboluses-smb-and-what-it-means-compared-to-oref0-the-original-openaps-algorithm/) + * [https://diyps.org/2017/05/08/choose-one-what-would-you-give-up-if-you-could-with-openaps-maybe-you-can-oref1-includes-unannounced-meals-or-uam/](https://diyps.org/2017/05/08/choose-one-what-would-you-give-up-if-you-could-with-openaps-maybe-you-can-oref1-includes-unannounced-meals-or-uam/) +* Make sure you understand what Super Micro Bolus (SMB) & Unannounced Meals (UAM) stand for (**read the above posts, we know you skipped them**!) +* Plan to have a learning curve. You will interact with oref1 differently when on Super Micro Bolus (SMB) and Unannounced Meal (UAM) than how you were interacting with oref0. In particular: **do not do correction boluses based on insulinReq**; instead use temp targets to give the rig a "nudge". You are very likely to overshoot if you try to do things manually on top of what Super Micro Bolus (SMB) has already done! +* Super Micro Bolus (SMB) may not be for everyone. Like everything else, plan to test it, fall back to previous methods of diabetes treatment if needed, and give yourself a time period for deciding whether or not it works well for you. + +## Understanding Super Micro Bolus (SMB) + +SMB: Super Micro Bolus + +Super Micro Bolus (SMB), like all things in OpenAPS, is designed with safety in mind. (Did you skip reading the updated reference design? Go read that first!) Super Micro Bolus (SMB) is designed to give you reasonably SAFE amounts of bolus needed upfront and use reduced temporary basal rates to safely balance out the peak insulin timing. You are likely to see many long low or zero temps (upwards of 120 minutes long) with Super Micro Bolus (SMB) turned on, while oref1 is administering Super Micro Boluses or waiting until it's safe to do so. + +Single Super Micro Bolus (SMB) amounts are limited by several factors. The largest a single Super Micro Bolus (SMB) bolus can be is the SMALLEST value of: + +* 30 minutes of the current regular basal rate (as adjusted by autotune/autosens), or +* 1/2 of the Insulin Required amount, or +* the remaining portion of your maxIOB setting in preferences + +It's important to note that maxIOB will limit Super Micro Bolus (SMB)s from being issued if your Insulin On Board (IOB) (for instance, from an easy bolus you have inputted before a meal) exceeds your maxIOB. So if your maxIOB is relatively low and you are running high post-meal, you may want to examine your logs to see if it is routinely preventing Super Micro Bolus (SMB)s. + +In addition, as of 0.6.0-master, using Bolus Wizard to input boluses and meal carbs is no longer recommended because of the possibility of errors when the rig attempts to issue an Super Micro Bolus (SMB) while Bolus Wizard is in use. Instead, many users [use IFTTT to notify their rig of upcoming carbs](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/ifttt-integration.html). + +(History of Super Micro Bolus (SMB) development: https://github.com/openaps/oref0/issues/262 ) + +## Understanding Unannounced Meals (UAM) + +UAM: Unannounced meal + Unannounced Meals (UAM) provides an alternative method (in addition to or instead of carb entry) for detecting and safely dosing insulin in response to significant BG rises, whether they are due to meals, adrenaline, or any other reason. + +(History of Unannounced Meals (UAM) development: https://github.com/openaps/oref0/issues/297 ) + +## How to turn on Super Micro Bolus (SMB) + +* In oref0 0.6.0 and later, you will enable Super Micro Bolus (SMB)s by adding the related preferences to your preferences.json. You may want to experiment with turning only one enableSMB option on at a time so you can closely observe the behavior (via both Nightscout and pump-loop.log) in the enabled situation. In addition to testing oref1 in "normal" situations, pay special attention to how it behaves in more extreme situations, such as with rescue carbs (announced or not), post-meal activity, etc. + +There are multiple preference toggles for Super Micro Bolus (SMB). Check out the [preferences page](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html#advanced-oref1-preferences) for more details on all the settings, but the short version is: + +``` + * enableSMB_with_COB means Super Micro Bolus (SMB) will be enabled as long as COB is above zero + * enableSMB_after_carbs means Super Micro Bolus (SMB) will be enabled for 6h after carb entry + * enableSMB_with_temptarget means Super Micro Bolus (SMB) will be enabled with a low temp target (< 100 mg/dL). +By default, a higher temp target (101 if your target is 100) will disable Super Micro Bolus (SMB). +``` + +## Troubleshooting + +1. Make sure you read the above, especially the "only enable oref1 if..." section. Super Micro Bolus (SMB) will behave differently than oref0 would. Watch carefully, and use your common sense and do what's right for you & your diabetes. +2. Common errors include: +* Not changing the preferences to be "true" for the relevant settings after you've enabled the oref1 features. +* Not running autotune. Remember, you don't have to enable it to run as part of your loop at night, but you should run it manually, review the results, and otherwise be VERY confident in your underlying pump settings (basals, ISF, carb ratio) before using oref1. +* Pump clock being >1 minute off from rig's time. This means 60 seconds. Not 61 seconds; 68 seconds; 90 seconds. Needs to be less than 60 seconds apart. `"Checking pump clock: "2017-05-16T15:46:32-04:00" is within 1m of current time: Tue May 16 15:47:40 EDT 2017` is an example of a >60 second gap that needs fixing before it will work properly. We added a script to automatically attempt to fix the pump time in case of a >60 second difference, but you may occasionally see this type of error in the logs until the script is able to properly adjust the pump time. + +## Pushover, Super Micro Bolus (SMB), and OpenAPS + +_This is for OpenAPS-specific pushovers related to oref1 features about insulin required (insulinReq) and carbs required (carbsReq). Pushover is a way to easily send messages to your phone from another device with simple messages. If you have Pushover set up for Nightscout, you still need to tell your OpenAPS rig your Pushover information to get these rig-driven alerts. Nightscout Pushover alerts are separate and distinct from OpenAPS-generated Pushover alerts. Each can exists with or without the other._ + +If Pushover API token and User key were added during the setup script and you have oref1 enabled, you can get Pushover alerts in the following situations: + +* When OpenAPS thinks carbs are needed to bring eventual BG up, and a 30m low temp won't be enough to do it + + + +* When Super Micro Bolus (SMB) is active and hitting maxBolus. This is intended to alert you when Super Micro Bolus (SMB) is going "all out", and will tell you the total amount of insulin OpenAPS thinks you require (insulinReq) if current BG trends continue. **DO NOT just blindly bolus for the amount of insulinReq.** You will also see that the pushover alert lists the amount it is attempting to Super Micro Bolus (SMB). You should use this notification as a reminder to tell the rig about anything you know it doesn't (like "oh yea, I want to enter my carbs for this meal", or "oh, hold on, I need an activity mode, because I'm gonna go for a walk in a few minutes"). You can also decide if a manual meal bolus is appropriate, or if you'd like to manually bolus part of the insulinReq. **If you're just using insulinReq and not doing a normal meal bolus, you should NOT do the full insulinReq as a manual bolus**, as oref1 is already attempting to deliver part of it as a Super Micro Bolus (SMB). Super Micro Bolus (SMB) is designed to administer the insulinReq a little at a time, in order to be able to safely react if the BG rise slows or stops, so in cases where you might otherwise consider a correction bolus, it'll often be best to not do anything at all and let Super Micro Bolus (SMB) safely handle the increased need for insulin. If you do choose to do a small manual correction bolus for a portion of the insulinReq, be sure to subtract out the Super Micro Bolus (SMB) oref1 is already delivering, and round down for safety. + + + +Cautions: +1. You are likely to cause yourself a low if you manually administer too much insulin. Be very careful about doing manual boluses based on Pushover alerts; see above about not doubling up on a microbolus that's just been delivered. +2. If the rig attempts to deliver a microbolus AND you have the bolus wizard menu open, it may cause the pump to error (and maybe reset). **Recommendation**: If you are getting Pushover alerts and decide to manually bolus in addition to the Super Micro Bolus (SMB)s, you may want to use the "easy bolus" (up button arrow) method for bolusing, which is less likely to cause the pump to receive this error. When using the easy bolus, you may not be able to deliver the easy bolus if the rig has sent an Super Micro Bolus (SMB) underneath. In that case, you'll have to hit escape, wait for the Super Micro Bolus (SMB) to finish delivering, and then perform your manual bolus (adjusting for the insulin just delivered). + +### If you are new to Pushover: + +Pushover is a way to easily send messages to your phone from another device with simple messages. (kind of like getting a text message from your OpenAPS rig), but to use this you must first have Pushover installed on your iPhone or Android (download from your OS's store). + + - Log into https://pushover.net/. From this page you will see your User Key. + - At the bottom of the page you will see "Your Applications (Create an Application/API Token)". You must first create an API Token: + - Click on the link provided. You must supply a name for your application, such as "OpenAPS", and change the type to _Script_ + - Then Check the box _"By checking this box, you agree that you have read our Terms of Service and our Guide to Being Friendly to our API"_ + + +To put these in your setup you must add them to the oref0-setup.sh parameters, either by saying "Yes" to advanced features in the oref0-setup.sh script and entering the info there, or by using `edit-runagain` and adding `--pushover_token=yourpushoverAPItoken --pushover_user=yourpushoveruserkey` to the end of your runagain line. Then `bash ~/myopenaps/oref0-runagain.sh` in order to rerun your script. + + + diff --git a/docs/docs/walkthrough/phase-4/understanding-autotune.md b/docs/docs/Customize-Iterate/understanding-autotune.md similarity index 87% rename from docs/docs/walkthrough/phase-4/understanding-autotune.md rename to docs/docs/Customize-Iterate/understanding-autotune.md index b07449390..798c2b013 100644 --- a/docs/docs/walkthrough/phase-4/understanding-autotune.md +++ b/docs/docs/Customize-Iterate/understanding-autotune.md @@ -10,8 +10,8 @@ Autotune is a WIP (work in progress) tool. Do not blindly make changes to your p ## What you'll see in autotune inputs and outputs -* You might wonder what CSF in the autotune results refers to: Carb Sensitivity Factor is the amount your blood sugar will rise for a given quantity of carbs consumed. And initial value for CSF is calculated from your ISF and carb:insulin ratio (CR), i.e., CSF = ISF / CR (e.g., for an ISF of 42mgDL/U and CR of 14g/U, CSF is 3mgDL/g.) Subsequent autotune estimates for CSF are adjusted for the actual observed post-meal BG rise (relative to what would be expected based on insulin activity) compared to the number of carbs eaten. -* You might wonder what min_5m_carbimpact in profile.json refers to: It tells autotune how fast to decay carbs when your BG isn't rising. The default value means to assume 3mg/dL per 5m of carb absorption, even when your BG is falling or rising less than that. +* You might wonder what CSF in the autotune results refers to: Carb Sensitivity Factor is the amount your blood sugar will rise for a given quantity of carbs consumed. And initial value for CSF is calculated from your ISF and carb:insulin ratio (CR), i.e., CSF = ISF / CR (e.g., for an ISF of 42(mg/dL)/U and CR of 14g/U, CSF is 3(mg/dL)/g.) Subsequent autotune estimates for CSF are adjusted for the actual observed post-meal BG rise (relative to what would be expected based on insulin activity) compared to the number of carbs eaten. +* You might wonder what min_5m_carbimpact in profile.json refers to: It tells autotune how fast to decay carbs when your BG isn't rising. The default value means to assume 8mg/dL per 5m of carb absorption, even when your BG is falling or rising less than that. * If you only input one basal rate in the profile.json, it will only show one basal in the left hand column, and tune the day around that basal. You can go back and edit the profile.json (and cp again to make all files the same) with your multiple basal rates if you want to appropriately tune and most easily compare the output suggested against what your existing basal schedule is. ## If you are DIY closed looping and looking at autotune: diff --git a/docs/docs/Customize-Iterate/update-your-rig.md b/docs/docs/Customize-Iterate/update-your-rig.md new file mode 100644 index 000000000..71bfecf86 --- /dev/null +++ b/docs/docs/Customize-Iterate/update-your-rig.md @@ -0,0 +1,76 @@ +# How to update oref0 on your OpenAPS rig in the future + +You've probably heard about all kinds of cool new features that you want to try. If they're part of the master branch already, you just need to go enable them (usually by [re-running the oref0-setup script](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/oref0-runagain.html)). You can see notes about what is included in a particular release in [the release notes page for oref0](https://github.com/openaps/oref0/releases). + +However, if it's a brand-new feature that's being tested or is recently added to master, you'll need to install the new version of `oref0` first. By the way, if you want to check which version of oref0 you are currently running, `npm list -g oref0` and if you want to check which branch `cd ~/src/oref0` and then `git branch`. + +
+
+ +1. `cd ~/src/oref0` +2. `git fetch` will update the local git repository. This does not change anything in your working directory +3. `git status` will tell you which branch your working directory is on and how many commits your working directory is behind +4. `git log origin/master` (replace `master` with the branch you are on) will print the commit descriptions. You only need to review the number of log messages corresponding to the number of commits your working directory is behind. +5. `git diff origin/master..` (replace `master` with the branch you are on) will print the individual file differences between your working copy and the new version. + +
+
+## Step 1 (Master): Install the new version
+
+1. `cd ~/src/oref0 && git checkout master && git pull && sudo npm install -g oref0`
+
+*(If you get a message that you need to commit or stash, use command `git stash`*)
+
+Trouble Shooting Installing Master:
+If installing Master fails with something like:
+```
+ File "/usr/local/lib/python2.7/dist-packages/parsedatetime/pdt_locales/icu.py", line 56, in get_icu
+ result['icu'] = icu = pyicu.Locale(locale)
+AttributeError: 'module' object has no attribute 'Locale
+```
+
+then run ```pip install parsedatetime==2.5``` and then rerun ```oref0-runagain.sh```
+
+### Alternative Step 1a (Dev): To get on "dev" branch to test even more recently added new stuff
+
+Or, if the feature you want hasn't been released yet, and you want to test the latest untested development version of `oref0`, run:
+
+1. `cd ~/src/oref0 && git checkout dev && git pull`
+2. `npm run global-install`
+
+### Alternative Step 1b (Test a feature branch): Not recommended for initial setup
+
+If you want to view the commit records between the version you are running and the new version (click here):
++ +1. `cd ~/src/oref0` +2. `git fetch` will update the local git repository. This does not change anything in your working directory +3. `git status` will tell you which branch your working directory is on and how many commits your working directory is behind +4. `git log origin/master` (replace `master` with the branch you are on) will print the commit descriptions. You only need to review the number of log messages corresponding to the number of commits your working directory is behind. +5. `git diff origin/master..` (replace `master` with the branch you are on) will print the individual file differences between your working copy and the new version. + +
+
+ +In case you want to test even more advanced stuff you've read about on gitter channels ([intend-to-bolus](https://gitter.im/nightscout/intend-to-bolus) / [openaps/oref0](https://gitter.im/openaps/oref0) / [openaps/autotune](https://gitter.im/openaps/autotune)) or on [official pull request list](https://github.com/openaps/oref0/pulls) you should follow the link, read description and in case you've decided to try it out, do: + +1. Checkout the header of pull request. It will contain author name, the branch to be merged to (dev or master) and the feature branch name that you want to test. +2. run `cd ~/src/oref0 && git fetch && git checkout && git pull && npm run global-install`
+ * don't forget to replace `` with the actual name of the feature branch you want to test
+
+
+
+
+## Step 2: Re-run oref0-setup
+
+Now that you've updated your `oref0` version, you will want to run the oref0-setup script (`cd && ~/src/oref0/bin/oref0-setup.sh`) again. See [this section](http://openaps.readthedocs.io/en/latest/docs/Build%20Your%20Rig/OpenAPS-install.html#be-prepared-to-enter-the-following-information-into-oref0-setup) for a guide of what the setup script will be prompting you to enter.
+
+## Step 3: Remember to set your preferences!
+
+Reminder! You'll need to re-set your preferences in `preferences.json`. See [the preferences page](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html) to see what preferences might have changed or become available since your last update.
+
+ To edit any of your preferences, you can enter `edit-pref` (as a shortcut) or `cd ~/myopenaps && nano preferences.json`
+
+## How to update Linux on your OpenAPS rig in the future
+
+Along with updating the OpenAPS software on your rig, you will also want to periodically update your operating system. This isn't the place for a primer on [Linux Commands](http://www.circuitbasics.com/useful-raspberry-pi-commands/), but the following two are useful to keep your system updated and as secure as they can be from recently-found bugs:
+
+```bash
+# apt-get update
+# apt-get upgrade
+```
+
+The first fetches all of the updated package lists for your system, and the second upgrades all of your installed packages to their most current versions.
diff --git a/docs/docs/Customize-Iterate/usability-considerations.md b/docs/docs/Customize-Iterate/usability-considerations.md
new file mode 100644
index 000000000..7fde5af38
--- /dev/null
+++ b/docs/docs/Customize-Iterate/usability-considerations.md
@@ -0,0 +1,173 @@
+# Usability Considerations
+
+Now that you've closed the loop, you probably have a lot of new "first" experiences to deal with. Like much of this looping experience, you'll figure it out as you go along, and figure out what's right for you. But here are some ideas or tips to consider:
+
+Not recommended for initial setup, click here to see instructions
++ +In case you want to test even more advanced stuff you've read about on gitter channels ([intend-to-bolus](https://gitter.im/nightscout/intend-to-bolus) / [openaps/oref0](https://gitter.im/openaps/oref0) / [openaps/autotune](https://gitter.im/openaps/autotune)) or on [official pull request list](https://github.com/openaps/oref0/pulls) you should follow the link, read description and in case you've decided to try it out, do: + +1. Checkout the header of pull request. It will contain author name, the branch to be merged to (dev or master) and the feature branch name that you want to test. +2. run `cd ~/src/oref0 && git fetch && git checkout
+
+
+## How do I enter carbs and boluses so OpenAPS can use them?
+Boluses always have to be set on the pump for OpenAPS to take them into consideration. Carbs can be either entered in any of several ways:
+- on the pump (for example, using Bolus Wizard),
+- into the Nightscout UI (using the Care Portal),
+- via an HTTPS POST to the treatments API, for example using the iOS Shortcuts app,
+- via [IFTTT](./ifttt-integration.html?highlight=IFTTT),
+- via [xDrip](https://github.com/NightscoutFoundation/xDrip),
+- via [CarbDialer (iOS App)](https://apps.apple.com/us/app/carbdialer/id1315809661).
+
+**SAFETY WARNING:** If the pump has a target range high end set lower than the BG input into the Bolus Wizard, the Bolus Wizard will add insulin to cover the carbs as well as bring BG down to the high end. I.e. if your high end is 110 and you enter a 160 BG and 45g of carbs in the Bolus Wizard, the Bolus Wizard will dose 1U to bring BG to 110 and 3U for carbs (assuming 50 (mg/dL)/U and 15g/U factors). The rig will likely have already dosed insulin to bring your BG to your low target, and you are potentially "double dosing". In these scenarios, you will have too much insulin onboard and can experience a severe low. If you use the Boluz Wizard, ensure the high end of the BG target range is a high number such as 250 mg/dL. OpenAPS default behavior (`wide_bg_target_range` preference) is to only use the target range lower end. Setting the high end does not impact the OpenAPS algorithms.
+
+## What do you do with the loop in airport security when you travel
+The loop is off the shelf hardware - it's no different than your phone or other small gadgets, so leave it in your carry-on bag when going through security. (Dana note: I have traveled [well](https://twitter.com/danamlewis/status/811682733445496833) over 100 times with my loop, and in some cases with 3-4 Pis and batteries and related accessories, and have never had issues going through security because of my loop.)
+
+## What do you do with your loop when you travel across timezones? How do you update devices for a time zone change?
+You have a couple of options. If you are traveling briefly, or only across a couple of timezones, and would not normally feel the need to adjust the timing of your basals, then you may choose to simply leave your pump, receiver, and Pi/Edison on your home timezone. But, if you would like to adjust to the new timezone (perhaps for a longer trip or a move), you can adjust your rig's timezone using `sudo dpkg-reconfigure tzdata` and then either run `killall-g oref0-pump-loop; oref0-set-device-clocks` to set the devices to match, or just change your pump and receiver time manually. Make sure to test in your new location to make sure everything is working! We also recommend planning to do this when you have some extra time for troubleshooting, in case you have issues. Also, it's worth noting that your body only changes about an hour or so of timezone a day, so even if you go abroad, there's not a rush to change timezones/the time on your devices - you can wait until 2-3 days into your trip to make the swap, at a time when you have some room to update your rigs.
+
+After the timezone change OpenAPS sometimes gets confused about the BG and/or pump data being "in the future". The pump and CGM data are not timestamped in UTC, so being unsynchronized with the OpenAPS can cause incorrect behavior. When the BG or pump data is "in the future" the software may stop pulling current information from the pump, and stop functioning (until the current time in the system reaches the time when the monitor data is no longer "in the future"). It often makes sense to remove all files from OpenAPS monitor folder after changing the timezone. However, this is sometimes insufficient, as the devices will still have records that are "in the future" from the perspective of your new timezone. As a result, you should expect Nightscout uploads to fail until the system time catches up to the previous device time, particularly when traveling west.
+
+## What do you do with the loop when you shower?
+Because the pumps aren't really waterproof, most of us choose to suspend and disconnect our pumps before we shower. You'll do the same thing even after you're looping. One trick, though, is to cancel any running temp basal rate and set a temp basal for 30 minutes with a rate of 0.0, and then suspend the pump. This will help OpenAPS accurately track your netIOB while you are off your pump. When you get out of the shower and are ready to reconnect your pump, do so. Make sure to unsuspend it. You can then either manually cancel the zero temp basal or let OpenAPS read and decide what temp basal to issue next.
+
+## What do you do when you change sites?
+The time required for the typical site change is normally not long enough to appreciably change the netIOB while disconnected. If you want to stay as close as possible to your true netIOB, follow the same process as the shower to put the pump into suspend mode. When it is time to prime, unsuspend and then prime. After priming, you can suspend again after checking to ensure the rig did not enact a temp basal > 0 while you unsuspended. If your site does not require priming after insertion, simply unsuspend the pump. If your site requires priming a canula after insertion, use fix prime to prime the canula after unsuspending. At this point, you can either manually cancel the zero temp basal or let OpenAPS read and decide what temp basal to issue next.
+
+## What do you do when you exercise?
+This varies from person to person, and depends on the type and length of activity. Here's a few tidbits from [Dana](http://twitter.com/danamlewis) on how she does various activities. (Other loopers, PR into this page with your additional tips and how-to's.)
+ * **Hiking** - Definitely take the loop with! Think about setting a temporary target (you can enter it in Nightscout if you have connectivity) higher for the duration of the exercise. If you're offline, just change your targets in your pump. The loop will read the adjusted targets and begin looping toward that target. When you're done with the activity, change your targets back. In this scenario, I might change my loop target from 100 (normal day or nighttime) to 130 or 140 as a target.
+
+ * **Swimming, Snorkeling, Scuba Diving, etc. (water sports)** - You can't loop while you're in the water, because the pump is not waterproof. (Unless you're sitting in a hot tub and have your pump safely above water, along with your CGM sensor being above water so it can transmit to the receiver, which is also not waterproof.) You can try having your sensor on your arm and keeping it above water so it can read every now and then if the receiver is in range. That being said, again, pump is NOT waterproof so you'll need to apply shower methodology (temp to zero, suspend, take pump off) to best track your netIOB. Some people observe having the CGM, once it gets back into range and reads data after the sensor has been submerged, read falsely high. It's not a big deal for the loop (because it's looking at trends, and doses using temp basals in a conservative way), but you'll likely want to fingerstick and/or wait a while before you'll be really happy with your CGM results again. See below for another strategy that could work as well if you're much more active than usual.
+
+ * **Running** - If it is a short run, (<30 minutes), I may not take the loop with me because any adjustments it would make are going to impact me after the run is done. For longer runs, I often now take my small, Edison based rig which can slip into the pocket of my hand-held running drink bottle that holds Gatorade. Before any length run, I try to make sure I don't have much positive netIOB on board (that's the biggest key to success). I also turn on activity mode (essentially a temp target of 120-140 or changing my pump targets to 120-140) an hour or so before a run and during the run; especially if I am carrying the loop during the run.
+
+ For any exercise or activity or time period, if you do not choose to take your loop (or if you forget it), the loop will pick up again once you get back into range and resume. (This is why it's important to temp then suspend so it can track the amount of insulin you haven't been getting.)
+
+## What do you do if you want to be off the pump for long periods during a day when you're really active? Like for the beach or water park or sporting activity or similar?
+
+Let's face it. There are some days when you just don't want to be attached to a pump. It's not uncommon for kids at diabetes camp to take a "pump holiday" where they revert to insulin injections in order to be unencumbered by the pump as they run and play and swim. Unfortunately this means a trade off - giving up the safety of closed loop control. Some have employed a strategy to be off the pump while active for extended periods but still have the advantages of closed loop assistance during less active periods of the day and overnight by using a combination of long acting basal injections in conjunction with the closed loop, in a manner similar to the following. Note that this will only work on days that you're really, really active (and as such will have significant reductions in your overall basal requirements).
+
+ * **First -** Look at your pump and determine your 24 hour basal insulin dose.
+
+ * **Second -** Create an alternate basal profile (Profile A or B) on your pump with settings for each time period that are half of your normal settings (we'll call this a "Half Basal" profile). You'll also want to make a "Half Basal" profile in Nightscout with the new settings, and consider establishing target glucose ranges for the entire 24 hour period that are higher than you might normally use (use values similar to what you would use for activity). For children a reasonable choice might be 140-180 but yours may be different.
+
+ * **Third -** On the morning of the active day, record the time and give an injection of long acting basal insulin at HALF THE USUAL DOSE of your usual 24-hour basal requirement (which you determined above). At the same time switch your pump to the "Half Basal" profile you created. You'll get half the usual basal dose from the injection, and half from your pump. You should also change your blood sugar targets on your pump to whatever you decided on when you set up your alternate profile above (don't forget to change them back later). Use the + icon on Nightscout (upper right corner) and choose event Profile Switch to Half Basal (or whatever you called it) in order to assure appropriate visualization of the basal settings via Nightscout when you have connectivity.
+
+ * **Fourth -** During periods when you're going to be very active, disconnect your pump and set an extended temp basal manually of 0.0 (choose a duration of several hours, or as long as you think you might be off the pump), and then suspend. This will allow the APS to track the negative IOB. Obviously since you're going to be off the pump (and if in the water, potentially without the benefit of CGM data as well) you'll want to remember to test more frequently.
+
+ * **Fifth -** Hook back up to the pump for meals to bolus and/or correct for hyperglycemia, and for periods where you'll be less active during the day. Don't forget to reset a temp basal of 0.0 when you suspend again in order to track negative IOB
+
+ * **Sixth -** At the end of the day, hook up to the pump, cancel your temp basal of 0.0 and start looping again. If you've been in the water, recognize it may take some time before your CGM data regains full accuracy, so you may still want to check more frequently. Check and make sure your pump is setting temp targets appropriately and check Nightscout to make sure all is going as you expect. You should still be on the "Half Basal" profile.
+
+ * **Overnight -** The loop will titrate your basal up or down in response to your CGM data. The caveat is, of course, that even if it lowers your temporary basal to 0.0 you will still be subject to the effects of the dose of long acting subcutaneous insulin you took in the morning. This will render the loop somewhat less effective at avoiding hypoglycemic events, and is in part the reason that higher than usual targets for blood glucose would be appropriate. Recognize also that after intense periods of physicial activity it is likely you will be more insulin sensitive, which could exacerbate the potential for hypoglycemia. Better to be safe and run slightly higher than normal.
+
+ * **The Next Morning -** Around 24 hours after the time you took your long acting insulin dose, switch your pump back to the normal profile, and readjust your glucose targets to your normal values on your pump. Use Profile Switch in Nightscout to switch back to your usual profile. Continue to monitor yourself somewhat more frequently until you're sure things are completely back to normal and all of the effects of the long acting insulin bolus from the prior day have resolved. Alternatively, if you're going to have several days of similar activities in a row, you could take another long acting basal dose and go at it again. Use your experience from the prior day to adjust that dose up or down slightly depending on how things went with your first day's glucose readings.
+
+## What if I want to turn off the loop for a while?
+
+If you're near the rig or pumper, any one of these actions will turn off the loop:
+* Power down the rig
+* Turn the temp basal type to % on the pump, which blocks temps from being set
+* Log in and stop cron
+
+If you're not near the rig or pumper, any one of these actions will turn off the loop:
+* If on same wifi as rig, you can log in and stop cron
+* Or change the API secret of NS temporarily, which means OpenAPS can't pull BGs in and loop anymore (so after last temp basal previously set expires, defaults to normal basal rates).
+* *(This one needs testing and validation, the low target may get ignored, or set as 80 as that's the lowest target you can usually set in OpenAPS)*: use very wide temp targets in your Nightscout website. You can set an wide range from -1000 to 1000 as a temp target for a period of time and it will effectively turn off the loop.
+* You can also choose to leave it at home if you are going out and do not want to be looping during that time. It will start looping again when you get back into range and it can successfully read your pump and CGM data again.
+
+## How do I open loop?
+
+The easiest way to "open loop" is to set the temp basal type on your pump to be "%" instead of "u/hr". This means your pump cannot and willnot accept temporary basal rates commands issued by the rig. But, the rig will still be able to read from the pump and your CGM, and make the calculations of what it would otherwise do.
+
+You can then watch the OpenAPS pill in Nightscout, or your logs (`l`) on the rig to see what OpenAPS would be doing.
+
+## How can you make adjustments to insulin delivery while on the go? - Optimizing with Temporary Targets:
+The use of Temporary Targets can provide additional fine tuning of insulin control on the go, or remotely for parents monitoring children when they are at school or away from home. As described elsewhere in this documentation, an Eating Soon-type (lower than normal) Temporary Target can be used in advance of a meal or activity. Lower Temporary Targets can also be used to force the OpenAPS system to be somewhat more aggressive in correcting a rising blood sugar. Similarly, a higher temporary target can soften a blood sugar drop and help avoid a low, or help limit stacking of insulin that is likely to peak during activity. Temp targets can be set a number of ways, from using IFTTT so you can set them easily from your watch or phone; or by entering them in Nightscout Care Portal.
+
+Temporary Targets can be set in advance by setting a future date/time stamp in Nightscout when you set them. For example, a parent may wish to set a week's worth of Eating Soon or Activity Modes in advance of a regular school week. This may be particularly helpful for meals or activity (i.e. gym class) which are regularly scheduled but for which you may have difficulty remembering to trigger the Temporary Target at the right time. Scheduled or remotely activated Temporary Targets can also be very useful in supporting children in optimal management at school or other locations where there may not be an adult who is in a position to set the Temporary Target each time it is needed. It's also helpful even for adult PWDs when traveling; a loved one at home in a different time zone can set temp targets as needed to help direct the rig's activity while the PWD might be asleep or otherwise occupied.Click here to expand a clickable list to see all tips on this page:
+ +- [How do I enter carbs and boluses so OpenAPS can use them?](#how-do-i-enter-carbs-and-boluses-so-openaps-can-use-them-) +- [What do you do with the loop in airport security when you travel](#what-do-you-do-with-the-loop-in-airport-security-when-you-travel) +- [What do you do with your loop when you travel across timezones? How do you update devices for a time zone change?](#what-do-you-do-with-your-loop-when-you-travel-across-timezones--how-do-you-update-devices-for-a-time-zone-change-) +- [What do you do with the loop when you shower?](#what-do-you-do-with-the-loop-when-you-shower-) +- [What do you do when you change sites?](#what-do-you-do-when-you-change-sites-) +- [What do you do when you exercise?](#what-do-you-do-when-you-exercise-) +- [What do you do if you want to be off the pump for long periods during a day when you're really active? Like for the beach or water park or sporting activity or similar?](#what-do-you-do-if-you-want-to-be-off-the-pump-for-long-periods-during-a-day-when-you-re-really-active---like-for-the-beach-or-water-park-or-sporting-activity-or-similar-) +- [What if I want to turn off the loop for a while?](#what-if-i-want-to-turn-off-the-loop-for-a-while-) +- [How do I open loop?](#how-do-i-open-loop-) +- [How can you make adjustments to insulin delivery while on the go? - Optimizing with Temporary Targets:](#how-can-you-make-adjustments-to-insulin-delivery-while-on-the-go----optimizing-with-temporary-targets-) +- [How do I improve the range of my Edison/Explorer Board?](#how-do-i-improve-the-range-of-my-edison-explorer-board-) +- [How do I switch between insulin types, or switch to Fiasp? What should I change?](#how-do-i-switch-between-insulin-types--or-switch-to-fiasp--what-should-i-change-) +- [How do I switch to a different Medtronic pump?](#how-do-i-switch-to-a-different-medtronic-pump-) +- [Improving the battery life of your Raspberry Pi](#improving-the-battery-life-of-your-raspberry-pi) + ++ +## How do I improve the range of my Edison/Explorer Board? + +There are two options for improving the range of an Explorer Board. The easiest way is to purchase a "wire whip" antenna to add to your rig. [Here is one available at Mouser (915MHz only)](https://www.mouser.com/ProductDetail/620-66089-0930?R=66089-0930virtualkey65480000virtualkey620-66089-0930) or for 866/868 MHz [also availabe at Mouser](https://www.mouser.at/ProductDetail/Anaren/66089-0830?qs=pH7abCSN9NPb5X5zwyxl2w==). You can buy one [at Enhanced Radio Devices](https://www.enhancedradio.com/collections/all) as well, you may consider ordering it with your Explorer Board. It physically clips on to your rig. The picture below shows the antenna clipped on and extended from the board; but you can experiment with wrapping the antenna around your rig to fit in your preferred case to see various impacts to the range. + + + +The other option is to tune the existing on-board antenna by cutting it. The antenna on the Explorer Block is a strip of copper underneath the green outer coating. The antenna is labeled A1. It will have its maximum power at 868 MHz. The antenna has a line across it at one point with a label that says "915". The antenna defaults to the 868 MHz range, which is what WW pumps use. If you have a US pump, mmtune will run and tune to something near 916MHz. Even with the 868 MHz antenna, you should get half a dozen feet or more of range on average. If you (optionally) want to boost the range of your antenna by a couple more feet, then you cut through the outer coating and the copper on that line with an X-ACTO knife. A single clean cut is sufficient, but if the cut doesn't look clean you could make two cuts and then dig out the circumscribed piece and then reseal the copper with nail polish. With that cut, the antenna will have maximum power near 915 MHz. + +If you're unsure whether you need to cut your Explorer Block's antenna, you probably don't. And if you decide you need slightly more range after using the Edison+Explorer rig for a few weeks, you can always come back later and do so then. + + + +## How do I switch between insulin types, or switch to Fiasp? What should I change? + +The most important setting for switching between insulin types in an OpenAPS rig is the "curve" type for duration of insulin activity. In oref0 0.6.0, most users will use the rapid-acting curve if they are using Humalog, Novolog, or similar. Fiasp users should use the "ultra-rapid" curve type. [See the preferences page here for more details on how to change your curve](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html#curve-rapid-acting) in your `preferences.json` file (which you can edit with `edit-pref`). + +Additionally, because Fiasp has a slightly faster peak time, you may need to adjust your behavior around meal-time dosing. If you pre-bolus, you may want to consider *not* pre-bolusing for the first few meals with Fiasp until you understand the differences, to avoid lows during or after the meal. + +Some users who switch to Fiasp find that they need to adjust settings. Others do not need to change settings that much, and autosens and/or autotune can help adjust to any variances over time as your body's needs change related to the difference insulin type. YDMV, as always! + +## How do I switch to a different Medtronic pump? + +First locate the serial number of the Medtronic pump you would like to start using. Then log into your rig and open your "runagain" script so you can edit the serial number. + +`cd ~/myopenaps && nano oref0-runagain.sh` + +Change the number in `--serial=123456` from your old serial number to your new serial number, save the changes, and exit nano. + +Now run the "runagain" script and respond to any prompts it gives you. + +`cd ~/myopenaps && bash oref0-runagain.sh` + +When the script is done and you have rebooted, log back into your rig and look at the pump loop logs + +`l` + +If you see errors regarding the pump history such as `Couldn't invoke_pumphistory_etc - continuing` and `Couldn't refresh_pumphistory_and_meal` then delete your pump history from your rig. + +`rm ~/myopenaps/monitor/pumphistory-24h-zoned.json` + +Now look at the pump loop logs again. + +`l` + +After some time, all errors should resolve and you should begin looping successfully with your new pump! + +## Improving the battery life of your Raspberry Pi + +!! Important for Enlite users: If you are using Enlite as CGM source, your rig will not work when it's underclocked, since the loop will not run fast enough! (You will always see the "BG too old" error). We are aware of that issue and try to find a solution... + +Version - CPU Clock - Battery Life @ 2500mAh (Li-Po) +___ +* 0.6.2 - 1000 MHz - **8 hours** +* 0.7.0-dev - 1000 MHz - **9 hours** +* 0.7.0-dev - 500 MHz - **14.5 hours** +___ + +As you can see, 0.7.0 made some battery life improvements, but under-clocking the CPU makes an even more significant improvement. + +To accomplish this, log into your rig via SSH and modify the file `/boot/config.txt`. + +Scroll down to find the line + +`#arm_freq=1000` + +and change it to + +`arm_freq=500` + +Note the removal of the `#` at the beginning of the line. Save your change and reboot your rig! diff --git a/docs/docs/Customize-Iterate/useful-mobile-apps.md b/docs/docs/Customize-Iterate/useful-mobile-apps.md new file mode 100644 index 000000000..5ec6f3f5a --- /dev/null +++ b/docs/docs/Customize-Iterate/useful-mobile-apps.md @@ -0,0 +1,190 @@ +# Helpful Mobile Apps + +Beyond just services, such as IFTTT and Papertrail, there are times where your mobile device can provide more access to your rig. The apps described below can help you login to your rig (both at home and while on the road) to make edits, run commands, troubleshoot, etc. + +## IP address of rig + +In order to connect to your rig wirelessly, sometimes you'll need it's IP address. There's several places you can get your rig's IP address if you aren't currently logged in, including: + +* Papertrail through doing a search for `network` and reading the rig's private IP address +* Logging into your home router, if rig is on your home network +* using a mobile app on your phone to scan the network for the rig + +### iNet or NetAnalyzer (iPhone) + +There are many scanning apps for iPhone. iNet or NetAnalyzer (lite version...don't need to pay for this to work) will scan the network that the phone is using for other connected devices and their IP addresses on that same network. So, if you run the scan while your phone is on a wifi network, the scan will be for the wifi network and range will likely be `192.168.1.1` to `192.168.1.254`. If you have your rig connected via mobile hotspot, then the scan will be for devices in the mobile hotspot range of `172.10.20.1` to `172.10.20.20`. (IP address ranges depend on the type of network being scanned.) Some people have had more success with the NetAnalyzer app over the iNet app, depending on their router settings. + +* Open the iNet app and click on the big `NETWORK SCANNER`. If using NetAnalyzer app, click on the `LAN` button on bottom bar and then `scan` button in top right corner of app. + + + +* The app will begin scanning the network that the phone is currently connected to. In this example, a home wifi network. Scan the results for your rig's name. If you don't see the name, try using the other app. If you still don't see your rig's name, it's possible that the rig is not actually connected to the network being scanned. Check the other options (such as papertrail or your home router) to verify whether the rig is actually online with the same network you are scanning. + + + +Now you have your rig's IP address...a valuable piece of information. + +If the rig is connected to your iPhone's hotspot, the scan will be performed for the mobile hotspot range. You can always re-do a scan by clicking on the little circle arrow in the bottom left of the iNet screen, or the `scan` button on the top right of NetAnalyzer app. + + +## Logging into Rig + +There are many apps that will allow you to use an ssh command to login to your rig wirelessly. These apps make it super convenient to login to your rig while on the go running errands, laying in bed on a Saturday morning, or other situations where you may not want to get to a computer to login to the rig. + +************** +**In order to use these apps, your rig and phone must be on the same internet connection or paired and connected over BT PAN** So if your rig is on your home wifi network, your phone must also be logged on to your home wifi network. The SSH connection also works when your rig and phone are properly paired and connected over a BT PAN. If they are not on the same network, you will get a login error. +************* + +I've tried a few apps, both paid and free, and these have been my favorite two iPhone apps; Termius and SimpleSSH. Each has its pros/cons, and therefore I pick which app based on what I'd like to do in the rig. + +Termius app has a FAR BETTER file editing ability...as in don't even bother trying to edit files (like preferences.json or adding wifi networks) in SimpleSSH. However, if you want to navigate files on your rig or issue commands that you've preprogrammed, SimpleSSH is better. So, if you're doing an activity which involves editing files...definitely stick with Termius app. + +### Termius app (iPhone AND Android) + +When you first open the Termius app, it will prompt you to add a new host. Go ahead and click the `+` button to add a `new host`. Turn the toggle on for `Use SSH` and then fill out the following information: + +* Alias – use an alias name that let’s you know which rig and which connection point this host is for, for example `YourRigName on home wifi` or "YourRigName on phone BT" + +* Hostname – Enter either `YourRigName.local` or the IP address of the rig + +* Username – click to the left of the little blue man and type `root` + +* Password – Enter your rig’s root password (default is “edison” but you should have changed it during setup) + +Click `Save` in the upper right corner. You should now see the host you just created. If you click on that host, you’ll see a message that it is connecting (first time connections will ask if you want to save the rig to known hosts, cick `continue` and then you'll be connected to a terminal app screen. You can now issue commands and edit files just like you can using Putty or Terminal app on your computer. + + + + +**HINT:** In portrait orientation, the middle part of the upper keyboard row can be moved/slid left or right using a fingertip drag. The arrow navigation keys may need to be dragged to see them all in that row. Unlock your phone's orientation, turn your iPhone sideways and the keyboard will be more prominently shown. + +To end a terminal session, just type `logout` + +### SimpleSSH + +SimpleSSH has a few more bells and whistles than Termius app. Namely, you can navigate the folders and files using a touch screen (similar to windows explorer or Mac finder) and you can setup scripts to be run with touch of button (to save yourself typing). However, SimpleSSH has terrible file editing (`vi` editor will crash and `nano` editor is pretty much unusable). + +SimpleSSH is divided into three pages; Commands, Hosts, and Settings & Info. You can access the different pages by swiping left/right in the app. To start using the app, you'll need to add your rig as a "host" by clicking on the `+` in the upper right corner of the Hosts page, and then filling out: + + * Name - use a name that let’s you know which rig and which connection point this host is for, for example `YourRigName on home wifi` + + * Host/IP address - Enter either `YourRigName.local` or the IP address of the rig. Leave the `:22` part unchanged + + * Username - enter `root` + + * Authentication - choose `password` type of authentication and enter your rig's root password. + +Click `Save` in the upper right corner. You should now see the host you just created. Underneath the host, there are two icons; one with a little `>_` terminal prompt and the other is a folder with magnifying glass. The first icon is for logging into your rig and using the terminal app (much like the Termius app access provides). The magnifying glass folder is for navigating your rig's directories and files. If you click on one of those folders, you’ll see a message that it is connecting (first time connections will ask if you want to save the rig to known hosts, cick `continue` and then you'll be connected. If you chose the terminal prompt, you'll be sent to the terminal screen. If you selected the magnifying glass, you'll be dropped in the rig's folders/files. + +#### SimpleSSH Commands +One of the best features of SimpleSSH can be found on the Commands page (swipe right on the SimpleSSH home screen to see the Commands page). You can add scripted commands to this page to give you single-button-press access to common rig interactions...like setting up shortcuts. There are pre-scripted commands that come with the app...you can see those by pressing the `+` in the upper right corner and then selecting `New Script Library Command`. You can click on the circled down-arrow to the right of the command name to save it to your commands page. + + + +Some useful/fun commands from the Script Library that I've added to my Commands Page: + +**Hardware Information** +* **Show Disk Status** will run `df -h` which shows available memory on your rig. If you ever have memory errors, this would be a helpful tool to see where your memory has been going. +* **Show Current Version** will run the equivalent of `uname -a` and show which version of the Linux kernel your rig is running. This can be useful in determining your Jubilinux version. +* **Show USB Devices** will run `lsusb` and can help confirm your dexcom receiver is being properly recognized when plugged in. +* **Show External IP address** will run `ifconfig` and show your rig's wifi (wlan0) IP address or hotspot (bnep0) IP address. + +**System Restart/Shutdown** +* **Shutdown** will turn off your rig +* **Reboot** will reboot your rig + +But, what I've found particularly useful is making some of my own custom commands. From your Commands page, press the `+` in the upper right corner and then choose `New Command` and fill out the following: + + * Name - Pick a name that is useful for your command + + * Hosts - I recommend leaving this one blank, and instead you'll be prompted which rig (aka host) you'd like to run the command on when you use it. + + * Command Script - this is where you'll enter the exact script you'd want to execute (examples below) + + * Show Results after execution - toggle this switch `on` + +These are some of my favorite Commands: + +**Show current preferences** - Sometimes I just want to double check what my preferences.json file has saved to it. Setting up this command gives me a print out of my preferences.json file with just a single button press. For this command, simply enter `cat-pref` in the command script body. + +**Show known wifi networks** - If I'm headed to a friend's house or traveling, I may want to double check if I have their wifi network already saved to my rig. This gives me a simple list of the wifi networks I have saved in the rig already, and helps me know if I want to add a new one before I travel. For this command, simply enter `cat-wifi` in the command script body. (note: if I actually want to add a wifi network, I would switch to Termius app or login on my computer to add a wifi network...SimpleSSH just isn't a robust editor) + +**git lock fix** - Probably the most common error in a rig is the `.git lock` error that happens on occasion and by deleting the .git directory, you can get back to looping quickly. For this command, enter `rm -rf /root/myopenaps/.git` in the command script body. + +**mmtune** - If you want to check how well your pump tune strength is you can use this command script to test it `cd ~/myopenaps && sudo service cron stop && killall -g openaps ; killall-g oref0-pump-loop; oref0-mmtune && sudo service cron start` + +**Edison temperature** - If you are ever concerned that your rig may be overheating, you can use this command to read if your edison cores are reaching critical temperatures. For this command, enter `sensors` in the command script body. + + + +If you want to run a particular command, just click on the command & confirm which host (rig) you'd like to run the command on. Assuming the rig is on the same network (wifi or BT tethered) as the phone, then the results will be displayed. Below is a few screenshots of some of the custom command outputs: + + + +#### SimpleSSH file navigation + +Perhaps a more slightly advanced-user (or curious-user) feature of SimpleSSH is the ability to use the file/directory navigator. The navigator (accessed using the magnifying glass icon in Hosts page) will allow you to peruse the various directories and files used by your rig and openaps. If you wanted to see your oref0 code, it is stored in the `root/src/oref0` folder. Or if you wanted to see your loop directory, you could navigate to your `root/myopenaps` folder. This can be particularly useful if you are getting troubleshooting help and someone asks "What does your pumphistory.json show?"...you could easily navigate to that file and copy the contents of it. (Note: For further reading about the file structure of your loop and rig, see [here](http://openaps.readthedocs.io/en/latest/docs/Troubleshooting/General_linux_troubleshooting.html#before-you-get-started) For example, here's the navigation chain to find your pumphistory.json: + + + +## SerialBot (Android) + +This app is useful for logging into the rig via a terminal session when not near a computer or using offline looping, can be done via USB serial cable, bluetooth or wifi depending on your setup. Simply select the connection method using the drop down box and type in the rig's connection details. +For SSH use the format root@yourigname/ipaddress:22 +This app will use the same commands as other terminal session apps such as PuTTy. + +## Nightscout Apps + +There are a few useful apps for viewing and maintaining your Nightscout site. + +### Nightscout app (iPhone) + +This one is pretty self-explanatory. You can access your Nightscout site by either using the Nightscout app, or by using your NS URL in a mobile browser. + +### Glimpse Webpages (Apple Watch) + +If you use an Apple watch and want to view your Nightscout site on the watch, give Glimpse Web Pages app a try. + +### LePhant for Heroku (iPhone) + +Logging into your NS site isn't a frequent need, but sometimes helpful when you need to redeploy your site, restart your dynos, add or change configuration settings, or check NS status. You can use a browser to login to your Heroku account, but an app can make the process simpler by saving your password and providing an easier viewing screen for mobile device. LePhant app costs about $5 in the iPhone app store, but provides a really slick way to access your Heroku controls. + + +## Review Logs +Beside using SSH and reading logs by calling `l`, there are solutions to review the logs using a browser + +### Frontail +[Frontail](https://github.com/mthenw/frontail) is a Node.js application for streaming logs to the browser. It's a `tail -F` with UI. +To install frontail, just call `npm i frontail -g`. + +For a test run you have to call `frontail /var/log/openaps/pump-loop.log` and visit `
+
+ + + + + + + + + +Here's a rough-and-ready budget version of a rig put together: contents of a 2000mAh powerbank, a plastic housing, a micro USB cable and some more soldering and hot glue. BE AWARE that this case will most likely overheat the Pi after a while. You need to at least drill some venting holes into the lid. + + + + + +
+
+### Summary of what you need:
+* Raspberry Pi Zero
+* RFM69HCW
+* [microSD Card]((http://openaps.readthedocs.io/en/latest/docs/Gear%20Up/edison.html#sd-card))
+* Bread board
+* Jumper wires
+* Soldering iron
+* Power source via Micro USB
+
+### The Raspberry Pi Zero
+
+For this setup, you want a Raspberry Pi Zero WH. (The "H" means it has Header pins). (Also, a regular Raspberry Pi 3 model B works fine.)
+
+### RFM69HCW
+You can buy this board e.g. [here](https://www.adafruit.com/product/3070), but you can really buy it wherever you want. These boards are, like the RPi Zero, very common. Just make sure you get the right frequency. 868/915 MHz is correct. All others are wrong.
+
+### Breadboard
+Any breadboard will do, no special requirements.
+
+### Soldering
+You need to solder the pin stripe into the RFM69HCW. Insert the pin stripe from the bottom of the board, with the short endings reaching through the holes. Fixate a bit, so you can rest the soldering iron tip on the pins and the board.
+
+Solder the included pin stripe diligently into the 9 holes named
+VIN GND EN G0 SCK MISO MOSI CS RST
+
+Cut an antenna at your preferred length corresponding to your frequency. This can be a simple piece of isolated, unshielded wire. (I simply took one of the jumper wires for my first try.)
+Calculate your length here: https://m0ukd.com/calculators/quarter-wave-ground-plane-antenna-calculator/ and just use the value from A (first green box). This should be the length of your antenna, from the soldering point on the board to the tip.
+
+Solder it to the board. It's the hole near the "o" from Radio. Make sure to not connect the soldering to the ground plates left and right from the hole. This antenna is really only connected to the one hole.
+
+This is your connection scheme for the RPi to RFM69HCW. Stick the RFM69HCW on a bread board, and connect:
+
++Click here to expand and see pictures of a rig with a Pi0WH and RFM69HCW::
++ + + + + + + + + +Here's a rough-and-ready budget version of a rig put together: contents of a 2000mAh powerbank, a plastic housing, a micro USB cable and some more soldering and hot glue. BE AWARE that this case will most likely overheat the Pi after a while. You need to at least drill some venting holes into the lid. + + + + + +
| Board | +Connect | +Connect | +Connect | +Connect | +Connect | +Connect | +Connect | +Connect | +
|---|---|---|---|---|---|---|---|---|
| RPi | +3.3V | +GND | +MOSI | +MISO | +SCLK | ++ | CE1_N | ++ |
| RPi PIN | +17 | +25 | +19 | +21 | +23 | +15 | +26 | +22 | +
| RFM69HCW | +VIN or 3.3V | +GND | +MOSI | +MISO | +SCK or CLK | +G0 or DIO0 | +CS or NSS | +RST or RESET | +
+
+ +* Use Paypal and purchase using the "Goods and Services" payment option. This costs nothing for the buyer, but the seller will lose 2.95% of the sale to Paypal fees. Paypal offers some protection for both buyer and seller in the event of fraud. + +* Ask for photos of the pump. Check to make sure the serial number of the pump on the backside matches the serial number of the pump showing in the display menu. Ask for a short video of the pump, or at least a photo of the pump turned on, so that you can see the pump's firmware and model number. Cracks and some wear on these pumps is expected...these pumps are not usually free of any marks. Many people are successfully looping on pumps that have cracks and rub marks...but you may want to ask if you are concerned about any you see. + +* Ask for shipping that includes a tracking number. USPS Priority Mail's smallest box is a great option. It's only $7.15 and includes tracking. Ask the seller to add a small bit of packing protection such as bubble wrap around the pump to keep it safe during shipping. Make sure you get a tracking number within a reasonable period of time after you have paid. + +Red flags that may indicate a scam: + +* Asking for payment through "friends and family" on Paypal, especially if you don't know the person or have any solid references for them. Paying in that way offers you no buyer protection. It's just like giving the seller cash, so you had better trust the seller. + +* Offering an "almost new" pump is a big red flag. These pumps should be at least 5 years old by now. Do you really think a 5 year old pump should be unused and sitting in shrink wrap at this point? Seems highly suspicious. + +* Not able to provide new pictures of the pump when requested. Sure they posted some pictures with the ad, but what if they just downloaded them from other people's ads? The seller should be able to furnish a couple "new" photos are your request. A good one to ask for is the battery and reservoir tops so you can see the condition of those. + +
+
+## Word of warning: Pump repairs rendering pumps useless for looping
+
+If you need to send your pump away to Medtronic for repair, be aware that during the repair process the firmware will get upgraded. This makes your pump not usable for looping. Ask the community if you run into a pump error - the community has tips for solving several common pump errors.
+
+## Tips for longer battery life
+
+If you are new to looping, one of the first things you will notice is that you will go through batteries _very_ quickly. Even known good alkaline batteries may only last a few days of 24/7 looping. Many OpenAPS users recommend [Energizer Ultimate Lithium](https://www.amazon.com/Energizer-Ultimate-Lithium-Batteries-Count/dp/B06ZYWKBRB/) batteries. These should last a week or more. Just ensure you use the correct settings if you are using NightScout - [see here for details about alert settings in Nightscout for the different battery types](https://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/nightscout-setup.html#battery-monitoring)
diff --git a/docs/docs/introduction/contribute.md b/docs/docs/Give Back-Pay It Forward/contribute.md
similarity index 57%
rename from docs/docs/introduction/contribute.md
rename to docs/docs/Give Back-Pay It Forward/contribute.md
index df8be952c..6f0dde281 100644
--- a/docs/docs/introduction/contribute.md
+++ b/docs/docs/Give Back-Pay It Forward/contribute.md
@@ -1,4 +1,4 @@
-# Ways to Contribute
+# Ways to Contribute to OpenAPS
OpenAPS doesn't require you to be a formally trained engineer/developer/anything to get started or use these tools. The main requirement is interest and willingness to safely DIY new technology that may help improve your life as well as others.
@@ -13,4 +13,10 @@ If you're not sure where to get started, here are some ways to get involved:
* Spread the word about #OpenAPS and get others involved; the more, the merrier. (You can direct them to [OpenAPS.org](http://OpenAPS.org) for more information.)
* Consider calling your device manufacturer and ask about communication protocols in order to understand how your device operates.
-If you would like to work on the core openaps code, take a look at the openaps [contributing guidelines](https://github.com/openaps/openaps/blob/master/CONTRIBUTING.md) before getting started.
+If you would like to work on the core openaps code, take a look at the openaps [contributing guidelines](https://github.com/openaps/openaps/blob/master/CONTRIBUTING.md) before getting started. Thank you for your contributions!
+
+# Pay it forward to those less fortunate
+
+One of the common questions we also get is how to donate money to further #OpenAPS. As this is an open source project, there is no financial organization behind OpenAPS that makes sense to donate to. Instead, we recommend considering the following:
+
+If you've been helped by the generosity of others, please [pay it forward by helping those less fortunate than any of us.](https://diyps.org/2017/05/24/different-ways-to-make-a-difference/) There are children dying of T1D who could live healthy lives into adulthood with only a very small contribution from each of us. If you haven't already, please visit [https://lfacinternational.org/](https://lfacinternational.org/) and sign up to make a regular monthly donation to [Life for a Child](https://lfacinternational.org/). If you can afford to donate $1/day, that is enough to save the life of one child. And if you can't afford that, please set up whatever monthly donation you feel you can afford right now. If you're already donating, please consider increasing your donation. With some small adjustments to our lifestyle, all of us can afford to give at least 10% of our income, and/or 10% of our time, to help the least fortunate. If you don't feel like you can afford that all at once, feel free to start smaller. But also think about what you would be willing to do, if you had to, in order to get insulin for your own child with T1. Every child with T1 deserves to live.
diff --git a/docs/docs/Give Back-Pay It Forward/data-commons-data-donation.md b/docs/docs/Give Back-Pay It Forward/data-commons-data-donation.md
new file mode 100644
index 000000000..29c3f5413
--- /dev/null
+++ b/docs/docs/Give Back-Pay It Forward/data-commons-data-donation.md
@@ -0,0 +1,58 @@
+# How to donate your data to research with the OpenAPS Data Commons in OpenHumans
+
+## About the OpenAPS Data Commons and OpenHumans
+
+Members of the OpenAPS community have frequently expressed the desire to donate their DIY closed loop data for scientific research; or to perform research themselves. The OpenAPS Data Commons was created to enable a simple way to share data sets from the community, both with traditional researchers who will create traditional research studies, and with groups or individuals from the community who want to review data as part of their own research projects. The OpenAPS Data Commons uses the “[Open Humans](https://www.openhumans.org/about/)” platform to enable people to easily upload and share their data.
+
+For more background, see [the OpenAPS.org Data Commons page](https://openaps.org/outcomes/data-commons/).
+
+
+
+(Tip: you may want to right click and open any links from this page in new windows.)
+
+## How to upload your data to the OpenAPS Data Commons
+
+
+* **A**. Create a profile on Open Humans. Keep in mind that your name/username can be public; so you may want to choose a non-name related username.
+ * Make sure to verify your profile (see Open Humans email confirmation).
+* **B**. (Optional, but recommended method for getting your data into OpenHumans). Use the Nightscout Data Transfer app to upload your data into
+ * **1**. Go to the [Nightscout Data Transfer App webpage](https://www.openhumans.org/activity/nightscout-data-transfer/)
+ * **2a**. NEW USERS: Scroll down to the bottom of the page and click "Connect Nightscout Data Transfer". (Log in to your OH account first if you haven't already).
+ * **2b**. REPEAT USERS: Go here: https://dataxfer-ns-oh.herokuapp.com/ . (Log in to your OH account first if you haven't already).
+ * **3**. It will take you to a page and ask for your Nightscout URL. Note the app DOES NOT store your URL but will just use it to fetch the data from Nightscout. Select the date range you want it to fetch data from. Tip: Start with two days or so of data to test that it works; you can then re-upload with a longer time frame of data.
+ * Warning: if you want to upload ALL of your data (yay!), then don't put a start date. However, this will take a while, so don't expect it to be done in minutes, but may take upward of half an hour to an hour depending on how much Nightscout data you have - this is normal.
+ * It will say "queued" on the page. You can refresh, and it should soon say "initiated". It may take several minutes to pull even a few days worth of data, so keep refreshing the page or come back later. Once done, it should show you a list of files that it has pulled, and provide download buttons if you want to download a local copy or open it to check that it correctly pulled data. Your screen should look like this:
+
+ 
+
+ When completed, after refreshing the status bar should turn green and look something like this:
+ 
+
+ * You can always go back to the [Nightscout Data Transfer app](https://www.openhumans.org/activity/nightscout-data-transfer/) and see what data it has uploaded for you. It should look something like this:
+
+
+
+* **C**. Now that you have data in Open Humans, next [click here to go directly to the OpenAPS Data Commons project](https://www.openhumans.org/activity/openaps-data-commons/).
+ * **1**. Scroll down and click "join". Carefully read the terms & consent to make sure you understand how your data is going to be used. You can also read the OpenAPS Data Commons research criteria here to better understand what criteria research projects are held to before they may be granted access to the data commons data. Note: the data will not be publicly available; it will only be shared privately and securely with individuals or research groups that meet this criteria and are vetted by a volunteer group from our community.
+ * **2**. Agree to share your data with the OpenAPS Data Commons.
+ * **3**. You will then be redirected to a survey to also provide basic data to be added to the data you uploaded – please also fill out this survey information. (This data will be tied to your OpenHumansdata shared with the Data Commons, which should prevent having to answer the same questions (i.e. how long you have had diabetes) on any future research studies that have questionnaires.)
+ * **4**. Hooray! You’ve just added data to the OpenAPS Data Commons.Thank you for contributing your data!
+ * Please note:
+ * We may contact you in the future (we will not see your email address) to request to upload a new batch of data or fill out a survey for another research study that is accessing the Data Commons data.
+ * Per the Terms and Conditions, you can *always* choose to delete and remove your data from Open Humans, or pull it from the OpenAPS Data Commons. Some data may have already been shared with individual research studies. However, if you contact dana@openaps.org, we will also do our best to remove it from any active/ongoing research studies.
+
+## Notes about OpenHumans and other data
+
+You can also donate your data to places like the [Nightscout Data Commons](https://www.openhumans.org/activity/nightscout-data-commons/), or any other research project you find interesting on Open Humans. Make sure to read the terms and conditions clearly for each of the research studies you donate your data to, and in particular look for what types of data they may be asking you to share. In addition to Nightscout data, you can upload things like Fitbit or Moves data, etc. to Open Humans.
+
+## Frequently Asked Questions
+
+* **I filled out the survey. What next?** Other purchasing tips (click here to expand):
++ +* Use Paypal and purchase using the "Goods and Services" payment option. This costs nothing for the buyer, but the seller will lose 2.95% of the sale to Paypal fees. Paypal offers some protection for both buyer and seller in the event of fraud. + +* Ask for photos of the pump. Check to make sure the serial number of the pump on the backside matches the serial number of the pump showing in the display menu. Ask for a short video of the pump, or at least a photo of the pump turned on, so that you can see the pump's firmware and model number. Cracks and some wear on these pumps is expected...these pumps are not usually free of any marks. Many people are successfully looping on pumps that have cracks and rub marks...but you may want to ask if you are concerned about any you see. + +* Ask for shipping that includes a tracking number. USPS Priority Mail's smallest box is a great option. It's only $7.15 and includes tracking. Ask the seller to add a small bit of packing protection such as bubble wrap around the pump to keep it safe during shipping. Make sure you get a tracking number within a reasonable period of time after you have paid. + +Red flags that may indicate a scam: + +* Asking for payment through "friends and family" on Paypal, especially if you don't know the person or have any solid references for them. Paying in that way offers you no buyer protection. It's just like giving the seller cash, so you had better trust the seller. + +* Offering an "almost new" pump is a big red flag. These pumps should be at least 5 years old by now. Do you really think a 5 year old pump should be unused and sitting in shrink wrap at this point? Seems highly suspicious. + +* Not able to provide new pictures of the pump when requested. Sure they posted some pictures with the ad, but what if they just downloaded them from other people's ads? The seller should be able to furnish a couple "new" photos are your request. A good one to ask for is the battery and reservoir tops so you can see the condition of those. + +
+You're all done! (For now. In the future, studies accessing the OpenAPS Data Commons may choose to send additional surveys to collect things like various QOL metrics, which you can choose to participate in or not.) Thanks for donating your data! + +* **How much data should I donate?**
+You can donate as much as you want, or as little as you want. However, many of the studies are interested in looking at before/after looping - so at a minimum, I'd suggest a month or two before you started looping. If you don't have any reason to limit what you share, I'd suggest sharing all of your Nightscout data to make it the most useful to all potential researchers. (This means don't bother to put a start or end date in the Nightscout Data Transfer tool; just put in your URL and hit upload.) + +* **Who is accessing the data?**
+Any project from OpenHumans accessing the OpenAPS Data Commons should be listed on the page. We'll also keep a list going (probably here, on the [OpenAPS.org Data Commons page](https://openaps.org/outcomes/data-commons/)) to reflect the different studies using the data. + diff --git a/docs/docs/Give Back-Pay It Forward/index.rst b/docs/docs/Give Back-Pay It Forward/index.rst new file mode 100644 index 000000000..d6b25ba6e --- /dev/null +++ b/docs/docs/Give Back-Pay It Forward/index.rst @@ -0,0 +1,9 @@ +Give Back/Pay it Forward +---------------------- + +.. toctree:: + :maxdepth: 4 + + + data-commons-data-donation + contribute diff --git a/docs/docs/Images/Autosync_Autotune_Nightscout.jpeg b/docs/docs/Images/Autosync_Autotune_Nightscout.jpeg new file mode 100644 index 000000000..e76328f81 Binary files /dev/null and b/docs/docs/Images/Autosync_Autotune_Nightscout.jpeg differ diff --git a/docs/docs/Images/AutotuneWeb_ProfileStep.jpeg b/docs/docs/Images/AutotuneWeb_ProfileStep.jpeg new file mode 100644 index 000000000..287a33937 Binary files /dev/null and b/docs/docs/Images/AutotuneWeb_ProfileStep.jpeg differ diff --git a/docs/docs/Images/AutotuneWeb_Results2.png b/docs/docs/Images/AutotuneWeb_Results2.png new file mode 100644 index 000000000..7c17a7dab Binary files /dev/null and b/docs/docs/Images/AutotuneWeb_Results2.png differ diff --git a/docs/docs/Images/AutotuneWeb_Results_1.png b/docs/docs/Images/AutotuneWeb_Results_1.png new file mode 100644 index 000000000..4a84dcb69 Binary files /dev/null and b/docs/docs/Images/AutotuneWeb_Results_1.png differ diff --git a/docs/docs/Images/AutotuneWeb_Results_RedYellow.png b/docs/docs/Images/AutotuneWeb_Results_RedYellow.png new file mode 100644 index 000000000..670e32ec2 Binary files /dev/null and b/docs/docs/Images/AutotuneWeb_Results_RedYellow.png differ diff --git a/docs/docs/Images/BT_pairing.png b/docs/docs/Images/BT_pairing.png new file mode 100644 index 000000000..9c46b3f6e Binary files /dev/null and b/docs/docs/Images/BT_pairing.png differ diff --git a/docs/docs/Images/BT_papertrail.PNG b/docs/docs/Images/BT_papertrail.PNG new file mode 100644 index 000000000..eaaccc8bb Binary files /dev/null and b/docs/docs/Images/BT_papertrail.PNG differ diff --git a/docs/docs/Images/BT_sudos.png b/docs/docs/Images/BT_sudos.png new file mode 100644 index 000000000..4909b6fa4 Binary files /dev/null and b/docs/docs/Images/BT_sudos.png differ diff --git a/docs/docs/Images/Building_OpenAPS_steps.jpg b/docs/docs/Images/Building_OpenAPS_steps.jpg new file mode 100644 index 000000000..ed1c8bac1 Binary files /dev/null and b/docs/docs/Images/Building_OpenAPS_steps.jpg differ diff --git a/docs/docs/Images/Can_I_close_the_loop_with_this_pump_July_13_2017.jpg b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_July_13_2017.jpg new file mode 100644 index 000000000..438da5e73 Binary files /dev/null and b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_July_13_2017.jpg differ diff --git a/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_18_2018.png b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_18_2018.png new file mode 100644 index 000000000..f42f309e2 Binary files /dev/null and b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_18_2018.png differ diff --git a/docs/docs/walkthrough/phase-0/Can_I_close_the_loop_with_this_pump_May_20_2016.jpg b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_20_2016.jpg similarity index 100% rename from docs/docs/walkthrough/phase-0/Can_I_close_the_loop_with_this_pump_May_20_2016.jpg rename to docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_20_2016.jpg diff --git a/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_5_2018.png b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_5_2018.png new file mode 100644 index 000000000..54b022b22 Binary files /dev/null and b/docs/docs/Images/Can_I_close_the_loop_with_this_pump_May_5_2018.png differ diff --git a/docs/docs/Images/Carb_data_to_rig.jpg b/docs/docs/Images/Carb_data_to_rig.jpg new file mode 100644 index 000000000..fd3a3f5ff Binary files /dev/null and b/docs/docs/Images/Carb_data_to_rig.jpg differ diff --git a/docs/docs/Images/Carb_data_to_rig.png b/docs/docs/Images/Carb_data_to_rig.png new file mode 100644 index 000000000..ae5aebad0 Binary files /dev/null and b/docs/docs/Images/Carb_data_to_rig.png differ diff --git a/docs/docs/Images/Carb_predictions.jpg b/docs/docs/Images/Carb_predictions.jpg new file mode 100644 index 000000000..e25a30216 Binary files /dev/null and b/docs/docs/Images/Carb_predictions.jpg differ diff --git a/docs/docs/Images/Computer_rig_different_wifi.png b/docs/docs/Images/Computer_rig_different_wifi.png new file mode 100644 index 000000000..566133703 Binary files /dev/null and b/docs/docs/Images/Computer_rig_different_wifi.png differ diff --git a/docs/docs/Images/Computer_rig_same_wifi.png b/docs/docs/Images/Computer_rig_same_wifi.png new file mode 100644 index 000000000..661c6e030 Binary files /dev/null and b/docs/docs/Images/Computer_rig_same_wifi.png differ diff --git a/docs/docs/Images/Dosing_scenario_1.jpg b/docs/docs/Images/Dosing_scenario_1.jpg new file mode 100644 index 000000000..258739513 Binary files /dev/null and b/docs/docs/Images/Dosing_scenario_1.jpg differ diff --git a/docs/docs/Images/Dosing_scenario_2.jpg b/docs/docs/Images/Dosing_scenario_2.jpg new file mode 100644 index 000000000..63dc8dedc Binary files /dev/null and b/docs/docs/Images/Dosing_scenario_2.jpg differ diff --git a/docs/docs/Images/Dosing_scenario_3.jpg b/docs/docs/Images/Dosing_scenario_3.jpg new file mode 100644 index 000000000..23dcdc7f1 Binary files /dev/null and b/docs/docs/Images/Dosing_scenario_3.jpg differ diff --git a/docs/docs/Images/Dosing_scenario_4.jpg b/docs/docs/Images/Dosing_scenario_4.jpg new file mode 100644 index 000000000..d078a232d Binary files /dev/null and b/docs/docs/Images/Dosing_scenario_4.jpg differ diff --git a/docs/docs/Images/Edison/64_bit.png b/docs/docs/Images/Edison/64_bit.png new file mode 100644 index 000000000..8c8a8d602 Binary files /dev/null and b/docs/docs/Images/Edison/64_bit.png differ diff --git a/docs/docs/Images/Edison/After_Homebrew.png b/docs/docs/Images/Edison/After_Homebrew.png new file mode 100644 index 000000000..3c5125e2f Binary files /dev/null and b/docs/docs/Images/Edison/After_Homebrew.png differ diff --git a/docs/docs/Images/Edison/After_install_other_stuff.png b/docs/docs/Images/Edison/After_install_other_stuff.png new file mode 100644 index 000000000..40a6e5d24 Binary files /dev/null and b/docs/docs/Images/Edison/After_install_other_stuff.png differ diff --git a/docs/docs/Images/Edison/Edison_Explorer_Board.png b/docs/docs/Images/Edison/Edison_Explorer_Board.png new file mode 100644 index 000000000..2b3a85a0f Binary files /dev/null and b/docs/docs/Images/Edison/Edison_Explorer_Board.png differ diff --git a/docs/docs/Images/Edison/Edison_in_Finder_folder.png b/docs/docs/Images/Edison/Edison_in_Finder_folder.png new file mode 100644 index 000000000..beef2523d Binary files /dev/null and b/docs/docs/Images/Edison/Edison_in_Finder_folder.png differ diff --git a/docs/docs/Images/Edison/Enter_return.png b/docs/docs/Images/Edison/Enter_return.png new file mode 100644 index 000000000..9d7949f8e Binary files /dev/null and b/docs/docs/Images/Edison/Enter_return.png differ diff --git a/docs/docs/Images/Edison/ExplorerBoard_two_charging_cables.png b/docs/docs/Images/Edison/ExplorerBoard_two_charging_cables.png new file mode 100644 index 000000000..90b390bba Binary files /dev/null and b/docs/docs/Images/Edison/ExplorerBoard_two_charging_cables.png differ diff --git a/docs/docs/Images/Edison/Inside_terminal.png b/docs/docs/Images/Edison/Inside_terminal.png new file mode 100644 index 000000000..312422e39 Binary files /dev/null and b/docs/docs/Images/Edison/Inside_terminal.png differ diff --git a/docs/docs/Images/Edison/Phone_hotspot_wifi.png b/docs/docs/Images/Edison/Phone_hotspot_wifi.png new file mode 100644 index 000000000..979c6159a Binary files /dev/null and b/docs/docs/Images/Edison/Phone_hotspot_wifi.png differ diff --git a/docs/docs/Images/Edison/Rig_login_time.png b/docs/docs/Images/Edison/Rig_login_time.png new file mode 100644 index 000000000..df17c7f28 Binary files /dev/null and b/docs/docs/Images/Edison/Rig_login_time.png differ diff --git a/docs/docs/Images/Edison/Terminal_example.png b/docs/docs/Images/Edison/Terminal_example.png new file mode 100644 index 000000000..54e172a02 Binary files /dev/null and b/docs/docs/Images/Edison/Terminal_example.png differ diff --git a/docs/docs/Images/Edison/Time_zone.png b/docs/docs/Images/Edison/Time_zone.png new file mode 100644 index 000000000..886d76888 Binary files /dev/null and b/docs/docs/Images/Edison/Time_zone.png differ diff --git a/docs/docs/Images/Edison/Wifi_add.png b/docs/docs/Images/Edison/Wifi_add.png new file mode 100644 index 000000000..9a6fe60f3 Binary files /dev/null and b/docs/docs/Images/Edison/Wifi_add.png differ diff --git a/docs/docs/Images/Edison/Wifi_edit_screen.png b/docs/docs/Images/Edison/Wifi_edit_screen.png new file mode 100644 index 000000000..234ea991f Binary files /dev/null and b/docs/docs/Images/Edison/Wifi_edit_screen.png differ diff --git a/docs/docs/Images/Edison/after_install_lsusb.png b/docs/docs/Images/Edison/after_install_lsusb.png new file mode 100644 index 000000000..b8417f8c4 Binary files /dev/null and b/docs/docs/Images/Edison/after_install_lsusb.png differ diff --git a/docs/docs/Images/Edison/apt-get.png b/docs/docs/Images/Edison/apt-get.png new file mode 100644 index 000000000..4c67f90db Binary files /dev/null and b/docs/docs/Images/Edison/apt-get.png differ diff --git a/docs/docs/Images/Edison/bootstrap-end.png b/docs/docs/Images/Edison/bootstrap-end.png new file mode 100644 index 000000000..59598a508 Binary files /dev/null and b/docs/docs/Images/Edison/bootstrap-end.png differ diff --git a/docs/docs/Images/Edison/cd_jubilinux.png b/docs/docs/Images/Edison/cd_jubilinux.png new file mode 100644 index 000000000..f68e2966f Binary files /dev/null and b/docs/docs/Images/Edison/cd_jubilinux.png differ diff --git a/docs/docs/Images/Edison/change_me_out_for_jubilinux.png b/docs/docs/Images/Edison/change_me_out_for_jubilinux.png new file mode 100644 index 000000000..6506ad7f1 Binary files /dev/null and b/docs/docs/Images/Edison/change_me_out_for_jubilinux.png differ diff --git a/docs/docs/Images/Edison/changing_edison_password.png b/docs/docs/Images/Edison/changing_edison_password.png new file mode 100644 index 000000000..975e52788 Binary files /dev/null and b/docs/docs/Images/Edison/changing_edison_password.png differ diff --git a/docs/docs/Images/Edison/control_d.png b/docs/docs/Images/Edison/control_d.png new file mode 100644 index 000000000..4e9a079ee Binary files /dev/null and b/docs/docs/Images/Edison/control_d.png differ diff --git a/docs/docs/Images/Edison/dfu_files.png b/docs/docs/Images/Edison/dfu_files.png new file mode 100644 index 000000000..0347e0daa Binary files /dev/null and b/docs/docs/Images/Edison/dfu_files.png differ diff --git a/docs/docs/Images/Edison/dfu_inside.png b/docs/docs/Images/Edison/dfu_inside.png new file mode 100644 index 000000000..d42dcda97 Binary files /dev/null and b/docs/docs/Images/Edison/dfu_inside.png differ diff --git a/docs/docs/Images/Edison/dfu_unzip.png b/docs/docs/Images/Edison/dfu_unzip.png new file mode 100644 index 000000000..c031a11c1 Binary files /dev/null and b/docs/docs/Images/Edison/dfu_unzip.png differ diff --git a/docs/docs/Images/Edison/dfu_util.png b/docs/docs/Images/Edison/dfu_util.png new file mode 100644 index 000000000..3b6954a6b Binary files /dev/null and b/docs/docs/Images/Edison/dfu_util.png differ diff --git a/docs/docs/Images/Edison/directory.md b/docs/docs/Images/Edison/directory.md new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/docs/docs/Images/Edison/directory.md @@ -0,0 +1 @@ + diff --git a/docs/docs/Images/Edison/dont_worry_during_reboot.png b/docs/docs/Images/Edison/dont_worry_during_reboot.png new file mode 100644 index 000000000..e08158388 Binary files /dev/null and b/docs/docs/Images/Edison/dont_worry_during_reboot.png differ diff --git a/docs/docs/Images/Edison/edison_driver.png b/docs/docs/Images/Edison/edison_driver.png new file mode 100644 index 000000000..c980cd8e1 Binary files /dev/null and b/docs/docs/Images/Edison/edison_driver.png differ diff --git a/docs/docs/Images/Edison/edison_driver2.png b/docs/docs/Images/Edison/edison_driver2.png new file mode 100644 index 000000000..59c14a1a8 Binary files /dev/null and b/docs/docs/Images/Edison/edison_driver2.png differ diff --git a/docs/docs/Images/Edison/edison_hostname_password.png b/docs/docs/Images/Edison/edison_hostname_password.png new file mode 100644 index 000000000..085252307 Binary files /dev/null and b/docs/docs/Images/Edison/edison_hostname_password.png differ diff --git a/docs/docs/Images/Edison/edison_popup.png b/docs/docs/Images/Edison/edison_popup.png new file mode 100644 index 000000000..eeacb71e1 Binary files /dev/null and b/docs/docs/Images/Edison/edison_popup.png differ diff --git a/docs/docs/Images/Edison/flash.png b/docs/docs/Images/Edison/flash.png new file mode 100644 index 000000000..1d533050d Binary files /dev/null and b/docs/docs/Images/Edison/flash.png differ diff --git a/docs/docs/Images/Edison/ifup_wlan0.png b/docs/docs/Images/Edison/ifup_wlan0.png new file mode 100644 index 000000000..ccbb26f46 Binary files /dev/null and b/docs/docs/Images/Edison/ifup_wlan0.png differ diff --git a/docs/docs/Images/Edison/ip_address.png b/docs/docs/Images/Edison/ip_address.png new file mode 100644 index 000000000..605d0a2cc Binary files /dev/null and b/docs/docs/Images/Edison/ip_address.png differ diff --git a/docs/docs/Images/Edison/jubilinux_unzip.png b/docs/docs/Images/Edison/jubilinux_unzip.png new file mode 100644 index 000000000..370d130cf Binary files /dev/null and b/docs/docs/Images/Edison/jubilinux_unzip.png differ diff --git a/docs/docs/Images/Edison/log_rotation.png b/docs/docs/Images/Edison/log_rotation.png new file mode 100644 index 000000000..6940ca62f Binary files /dev/null and b/docs/docs/Images/Edison/log_rotation.png differ diff --git a/docs/docs/Images/Edison/login_after_successful_reboot.png b/docs/docs/Images/Edison/login_after_successful_reboot.png new file mode 100644 index 000000000..4fadb7014 Binary files /dev/null and b/docs/docs/Images/Edison/login_after_successful_reboot.png differ diff --git a/docs/docs/Images/Edison/logrotate.png b/docs/docs/Images/Edison/logrotate.png new file mode 100644 index 000000000..af2d0ec68 Binary files /dev/null and b/docs/docs/Images/Edison/logrotate.png differ diff --git a/docs/docs/Images/Edison/mid_flash.png b/docs/docs/Images/Edison/mid_flash.png new file mode 100644 index 000000000..87dc1efd4 Binary files /dev/null and b/docs/docs/Images/Edison/mid_flash.png differ diff --git a/docs/docs/Images/Edison/name.png b/docs/docs/Images/Edison/name.png new file mode 100644 index 000000000..3dd544273 Binary files /dev/null and b/docs/docs/Images/Edison/name.png differ diff --git a/docs/docs/Images/Edison/nodejs.png b/docs/docs/Images/Edison/nodejs.png new file mode 100644 index 000000000..66ac3ebfb Binary files /dev/null and b/docs/docs/Images/Edison/nodejs.png differ diff --git a/docs/docs/Images/Edison/openaps-bootstrap-wifi-setup.png b/docs/docs/Images/Edison/openaps-bootstrap-wifi-setup.png new file mode 100644 index 000000000..fdc1a1d2a Binary files /dev/null and b/docs/docs/Images/Edison/openaps-bootstrap-wifi-setup.png differ diff --git a/docs/docs/Images/Edison/ping_success.png b/docs/docs/Images/Edison/ping_success.png new file mode 100644 index 000000000..9cc9e87e5 Binary files /dev/null and b/docs/docs/Images/Edison/ping_success.png differ diff --git a/docs/docs/Images/Edison/ping_unsuccessful.png b/docs/docs/Images/Edison/ping_unsuccessful.png new file mode 100644 index 000000000..cb039651f Binary files /dev/null and b/docs/docs/Images/Edison/ping_unsuccessful.png differ diff --git a/docs/docs/Images/Edison/port.png b/docs/docs/Images/Edison/port.png new file mode 100644 index 000000000..81b98ca10 Binary files /dev/null and b/docs/docs/Images/Edison/port.png differ diff --git a/docs/docs/Images/Edison/putty.png b/docs/docs/Images/Edison/putty.png new file mode 100644 index 000000000..d6b324070 Binary files /dev/null and b/docs/docs/Images/Edison/putty.png differ diff --git a/docs/docs/Images/Edison/putty2.png b/docs/docs/Images/Edison/putty2.png new file mode 100644 index 000000000..a3b2c3dee Binary files /dev/null and b/docs/docs/Images/Edison/putty2.png differ diff --git a/docs/docs/Images/Edison/putty3.png b/docs/docs/Images/Edison/putty3.png new file mode 100644 index 000000000..c462a248b Binary files /dev/null and b/docs/docs/Images/Edison/putty3.png differ diff --git a/docs/docs/Images/Edison/putty_port.png b/docs/docs/Images/Edison/putty_port.png new file mode 100644 index 000000000..8db30c53b Binary files /dev/null and b/docs/docs/Images/Edison/putty_port.png differ diff --git a/docs/docs/Images/Edison/python.png b/docs/docs/Images/Edison/python.png new file mode 100644 index 000000000..3b4be0db2 Binary files /dev/null and b/docs/docs/Images/Edison/python.png differ diff --git a/docs/docs/Images/Edison/ram.png b/docs/docs/Images/Edison/ram.png new file mode 100644 index 000000000..2d94993c3 Binary files /dev/null and b/docs/docs/Images/Edison/ram.png differ diff --git a/docs/docs/Images/Edison/ready.png b/docs/docs/Images/Edison/ready.png new file mode 100644 index 000000000..4d9173f38 Binary files /dev/null and b/docs/docs/Images/Edison/ready.png differ diff --git a/docs/docs/Images/Edison/ready_to_flash.png b/docs/docs/Images/Edison/ready_to_flash.png new file mode 100644 index 000000000..f6330a886 Binary files /dev/null and b/docs/docs/Images/Edison/ready_to_flash.png differ diff --git a/docs/docs/Images/Edison/reboot.png b/docs/docs/Images/Edison/reboot.png new file mode 100644 index 000000000..87029c018 Binary files /dev/null and b/docs/docs/Images/Edison/reboot.png differ diff --git a/docs/docs/Images/Edison/root.png b/docs/docs/Images/Edison/root.png new file mode 100644 index 000000000..e66be7c2c Binary files /dev/null and b/docs/docs/Images/Edison/root.png differ diff --git a/docs/docs/Images/Edison/setup-paste.png b/docs/docs/Images/Edison/setup-paste.png new file mode 100644 index 000000000..ccade79ec Binary files /dev/null and b/docs/docs/Images/Edison/setup-paste.png differ diff --git a/docs/docs/Images/Edison/successful.png b/docs/docs/Images/Edison/successful.png new file mode 100644 index 000000000..6cf5ea36b Binary files /dev/null and b/docs/docs/Images/Edison/successful.png differ diff --git a/docs/docs/Images/Edison/wifi_interfaces.png b/docs/docs/Images/Edison/wifi_interfaces.png new file mode 100644 index 000000000..60c49a99c Binary files /dev/null and b/docs/docs/Images/Edison/wifi_interfaces.png differ diff --git a/docs/docs/Images/Edison/winzip.png b/docs/docs/Images/Edison/winzip.png new file mode 100644 index 000000000..597cbb6ae Binary files /dev/null and b/docs/docs/Images/Edison/winzip.png differ diff --git a/docs/docs/Images/Example_AutotuneWeb.png b/docs/docs/Images/Example_AutotuneWeb.png new file mode 100644 index 000000000..7b80ec54e Binary files /dev/null and b/docs/docs/Images/Example_AutotuneWeb.png differ diff --git a/docs/docs/Images/Example_batch_images_upload.png b/docs/docs/Images/Example_batch_images_upload.png new file mode 100644 index 000000000..29feb2768 Binary files /dev/null and b/docs/docs/Images/Example_batch_images_upload.png differ diff --git a/docs/docs/Images/Example_iphone_apps.png b/docs/docs/Images/Example_iphone_apps.png new file mode 100644 index 000000000..6970b7130 Binary files /dev/null and b/docs/docs/Images/Example_iphone_apps.png differ diff --git a/docs/docs/Images/Example_screen_from_NightscoutDataTransfer_app_while_data_upload_in_progress.png b/docs/docs/Images/Example_screen_from_NightscoutDataTransfer_app_while_data_upload_in_progress.png new file mode 100644 index 000000000..52bd5c958 Binary files /dev/null and b/docs/docs/Images/Example_screen_from_NightscoutDataTransfer_app_while_data_upload_in_progress.png differ diff --git a/docs/docs/Images/Explorer_Board_rig.png b/docs/docs/Images/Explorer_Board_rig.png new file mode 100644 index 000000000..5dd9defff Binary files /dev/null and b/docs/docs/Images/Explorer_Board_rig.png differ diff --git a/docs/docs/Images/High_level_components_OpenAPS_setup_process.png b/docs/docs/Images/High_level_components_OpenAPS_setup_process.png new file mode 100644 index 000000000..b73bf40c8 Binary files /dev/null and b/docs/docs/Images/High_level_components_OpenAPS_setup_process.png differ diff --git a/docs/docs/Images/How_data_looks_in_NightscoutDataTransferApp_OpenHumans.png b/docs/docs/Images/How_data_looks_in_NightscoutDataTransferApp_OpenHumans.png new file mode 100644 index 000000000..1e4f66467 Binary files /dev/null and b/docs/docs/Images/How_data_looks_in_NightscoutDataTransferApp_OpenHumans.png differ diff --git a/docs/docs/Images/IFTTT_NSkey.png b/docs/docs/Images/IFTTT_NSkey.png new file mode 100644 index 000000000..8322a2cfb Binary files /dev/null and b/docs/docs/Images/IFTTT_NSkey.png differ diff --git a/docs/docs/Images/IFTTT_actionfields.png b/docs/docs/Images/IFTTT_actionfields.png new file mode 100644 index 000000000..0ecf420a6 Binary files /dev/null and b/docs/docs/Images/IFTTT_actionfields.png differ diff --git a/docs/docs/Images/IFTTT_applets.png b/docs/docs/Images/IFTTT_applets.png new file mode 100644 index 000000000..4055c3ee5 Binary files /dev/null and b/docs/docs/Images/IFTTT_applets.png differ diff --git a/docs/docs/Images/IFTTT_button.png b/docs/docs/Images/IFTTT_button.png new file mode 100644 index 000000000..ee3a7f384 Binary files /dev/null and b/docs/docs/Images/IFTTT_button.png differ diff --git a/docs/docs/Images/IFTTT_buttonpress.png b/docs/docs/Images/IFTTT_buttonpress.png new file mode 100644 index 000000000..3c23c1d25 Binary files /dev/null and b/docs/docs/Images/IFTTT_buttonpress.png differ diff --git a/docs/docs/Images/IFTTT_connect1.png b/docs/docs/Images/IFTTT_connect1.png new file mode 100644 index 000000000..071ce6af0 Binary files /dev/null and b/docs/docs/Images/IFTTT_connect1.png differ diff --git a/docs/docs/Images/IFTTT_connect2.png b/docs/docs/Images/IFTTT_connect2.png new file mode 100644 index 000000000..3406b1439 Binary files /dev/null and b/docs/docs/Images/IFTTT_connect2.png differ diff --git a/docs/docs/Images/IFTTT_enable.png b/docs/docs/Images/IFTTT_enable.png new file mode 100644 index 000000000..a3963c40f Binary files /dev/null and b/docs/docs/Images/IFTTT_enable.png differ diff --git a/docs/docs/Images/IFTTT_finish.png b/docs/docs/Images/IFTTT_finish.png new file mode 100644 index 000000000..17db4919b Binary files /dev/null and b/docs/docs/Images/IFTTT_finish.png differ diff --git a/docs/docs/Images/IFTTT_homescreen.png b/docs/docs/Images/IFTTT_homescreen.png new file mode 100644 index 000000000..f5908bd53 Binary files /dev/null and b/docs/docs/Images/IFTTT_homescreen.png differ diff --git a/docs/docs/Images/IFTTT_maker-webhook.png b/docs/docs/Images/IFTTT_maker-webhook.png new file mode 100644 index 000000000..76ecffd64 Binary files /dev/null and b/docs/docs/Images/IFTTT_maker-webhook.png differ diff --git a/docs/docs/Images/IFTTT_maker.png b/docs/docs/Images/IFTTT_maker.png new file mode 100644 index 000000000..aad0b8493 Binary files /dev/null and b/docs/docs/Images/IFTTT_maker.png differ diff --git a/docs/docs/Images/IFTTT_makerkey.png b/docs/docs/Images/IFTTT_makerkey.png new file mode 100644 index 000000000..eadd37db1 Binary files /dev/null and b/docs/docs/Images/IFTTT_makerkey.png differ diff --git a/docs/docs/Images/IFTTT_newapplet.png b/docs/docs/Images/IFTTT_newapplet.png new file mode 100644 index 000000000..178e3ff87 Binary files /dev/null and b/docs/docs/Images/IFTTT_newapplet.png differ diff --git a/docs/docs/Images/IFTTT_pebble.jpeg b/docs/docs/Images/IFTTT_pebble.jpeg new file mode 100644 index 000000000..cd34c17ff Binary files /dev/null and b/docs/docs/Images/IFTTT_pebble.jpeg differ diff --git a/docs/docs/Images/IFTTT_reorder.png b/docs/docs/Images/IFTTT_reorder.png new file mode 100644 index 000000000..740888a93 Binary files /dev/null and b/docs/docs/Images/IFTTT_reorder.png differ diff --git a/docs/docs/Images/IFTTT_services.png b/docs/docs/Images/IFTTT_services.png new file mode 100644 index 000000000..23e03d116 Binary files /dev/null and b/docs/docs/Images/IFTTT_services.png differ diff --git a/docs/docs/Images/IFTTT_services2.png b/docs/docs/Images/IFTTT_services2.png new file mode 100644 index 000000000..58cfcb36b Binary files /dev/null and b/docs/docs/Images/IFTTT_services2.png differ diff --git a/docs/docs/Images/IFTTT_signup.png b/docs/docs/Images/IFTTT_signup.png new file mode 100644 index 000000000..fbac68913 Binary files /dev/null and b/docs/docs/Images/IFTTT_signup.png differ diff --git a/docs/docs/Images/IFTTT_that.png b/docs/docs/Images/IFTTT_that.png new file mode 100644 index 000000000..cfc89b796 Binary files /dev/null and b/docs/docs/Images/IFTTT_that.png differ diff --git a/docs/docs/Images/IFTTT_this.png b/docs/docs/Images/IFTTT_this.png new file mode 100644 index 000000000..8a96d9907 Binary files /dev/null and b/docs/docs/Images/IFTTT_this.png differ diff --git a/docs/docs/Images/IFTTT_today.png b/docs/docs/Images/IFTTT_today.png new file mode 100644 index 000000000..a418381b7 Binary files /dev/null and b/docs/docs/Images/IFTTT_today.png differ diff --git a/docs/docs/Images/IFTTT_webrequest.png b/docs/docs/Images/IFTTT_webrequest.png new file mode 100644 index 000000000..a2e9ceb1a Binary files /dev/null and b/docs/docs/Images/IFTTT_webrequest.png differ diff --git a/docs/docs/IMG_1112.jpg b/docs/docs/Images/IMG_1112.jpg similarity index 100% rename from docs/docs/IMG_1112.jpg rename to docs/docs/Images/IMG_1112.jpg diff --git a/docs/docs/Images/Iphone_rig_same_wifi.png b/docs/docs/Images/Iphone_rig_same_wifi.png new file mode 100644 index 000000000..9ea541f32 Binary files /dev/null and b/docs/docs/Images/Iphone_rig_same_wifi.png differ diff --git a/docs/docs/Images/Online_Offline_monitoring.jpg b/docs/docs/Images/Online_Offline_monitoring.jpg new file mode 100644 index 000000000..a1f11878c Binary files /dev/null and b/docs/docs/Images/Online_Offline_monitoring.jpg differ diff --git a/docs/docs/Images/OpenAPS_Data_Commons.png b/docs/docs/Images/OpenAPS_Data_Commons.png new file mode 100644 index 000000000..f780be33d Binary files /dev/null and b/docs/docs/Images/OpenAPS_Data_Commons.png differ diff --git a/docs/docs/Images/OpenAPS_activity_by_dia_2_8.png b/docs/docs/Images/OpenAPS_activity_by_dia_2_8.png new file mode 100644 index 000000000..b7ba64149 Binary files /dev/null and b/docs/docs/Images/OpenAPS_activity_by_dia_2_8.png differ diff --git a/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential.png b/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential.png new file mode 100644 index 000000000..35dc22f5b Binary files /dev/null and b/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential.png differ diff --git a/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential_dia_5.png b/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential_dia_5.png new file mode 100644 index 000000000..c87bd23ac Binary files /dev/null and b/docs/docs/Images/OpenAPS_activity_curves_bilinear_vs_exponential_dia_5.png differ diff --git a/docs/docs/Images/OpenAPS_activity_dia_3.png b/docs/docs/Images/OpenAPS_activity_dia_3.png new file mode 100644 index 000000000..4dda20b59 Binary files /dev/null and b/docs/docs/Images/OpenAPS_activity_dia_3.png differ diff --git a/docs/docs/Images/OpenAPS_activity_dia_3_area.png b/docs/docs/Images/OpenAPS_activity_dia_3_area.png new file mode 100644 index 000000000..8e36b8e16 Binary files /dev/null and b/docs/docs/Images/OpenAPS_activity_dia_3_area.png differ diff --git a/docs/docs/Images/OpenAPS_cum_activity_by_dia_2_8.png b/docs/docs/Images/OpenAPS_cum_activity_by_dia_2_8.png new file mode 100644 index 000000000..1bb6e8962 Binary files /dev/null and b/docs/docs/Images/OpenAPS_cum_activity_by_dia_2_8.png differ diff --git a/docs/docs/Images/OpenAPS_cum_activity_dia_3.png b/docs/docs/Images/OpenAPS_cum_activity_dia_3.png new file mode 100644 index 000000000..079b63e34 Binary files /dev/null and b/docs/docs/Images/OpenAPS_cum_activity_dia_3.png differ diff --git a/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75.png b/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75.png new file mode 100644 index 000000000..5d2954ead Binary files /dev/null and b/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75.png differ diff --git a/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75_area.png b/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75_area.png new file mode 100644 index 000000000..3de595bb0 Binary files /dev/null and b/docs/docs/Images/OpenAPS_exponential_activity_curve_dia_5_peak_75_area.png differ diff --git a/docs/docs/Images/OpenAPS_exponential_activity_curves_dia_5_peak_60_75_90.png b/docs/docs/Images/OpenAPS_exponential_activity_curves_dia_5_peak_60_75_90.png new file mode 100644 index 000000000..980e810de Binary files /dev/null and b/docs/docs/Images/OpenAPS_exponential_activity_curves_dia_5_peak_60_75_90.png differ diff --git a/docs/docs/Images/OpenAPS_exponential_cum_activity_curves_dia_5_peak_60_75_90.png b/docs/docs/Images/OpenAPS_exponential_cum_activity_curves_dia_5_peak_60_75_90.png new file mode 100644 index 000000000..874e8df84 Binary files /dev/null and b/docs/docs/Images/OpenAPS_exponential_cum_activity_curves_dia_5_peak_60_75_90.png differ diff --git a/docs/docs/Images/OpenAPS_exponential_iob_curves_dia_5_peak_60_75_90.png b/docs/docs/Images/OpenAPS_exponential_iob_curves_dia_5_peak_60_75_90.png new file mode 100644 index 000000000..775cc7529 Binary files /dev/null and b/docs/docs/Images/OpenAPS_exponential_iob_curves_dia_5_peak_60_75_90.png differ diff --git a/docs/docs/Images/OpenAPS_iob_curve_dia_3.png b/docs/docs/Images/OpenAPS_iob_curve_dia_3.png new file mode 100644 index 000000000..db8f84b67 Binary files /dev/null and b/docs/docs/Images/OpenAPS_iob_curve_dia_3.png differ diff --git a/docs/docs/Images/OpenAPS_iob_curves_bilinear_vs_exponential.png b/docs/docs/Images/OpenAPS_iob_curves_bilinear_vs_exponential.png new file mode 100644 index 000000000..a66b0219e Binary files /dev/null and b/docs/docs/Images/OpenAPS_iob_curves_bilinear_vs_exponential.png differ diff --git a/docs/docs/Images/OpenAPS_iob_curves_by_dia_2_8.png b/docs/docs/Images/OpenAPS_iob_curves_by_dia_2_8.png new file mode 100644 index 000000000..b80735d2a Binary files /dev/null and b/docs/docs/Images/OpenAPS_iob_curves_by_dia_2_8.png differ diff --git a/docs/docs/Images/PR0.png b/docs/docs/Images/PR0.png new file mode 100644 index 000000000..9d521866c Binary files /dev/null and b/docs/docs/Images/PR0.png differ diff --git a/docs/docs/Images/PR1.png b/docs/docs/Images/PR1.png new file mode 100644 index 000000000..fde1f7cae Binary files /dev/null and b/docs/docs/Images/PR1.png differ diff --git a/docs/docs/Images/PR2.png b/docs/docs/Images/PR2.png new file mode 100644 index 000000000..43b7ec97e Binary files /dev/null and b/docs/docs/Images/PR2.png differ diff --git a/docs/docs/Images/PR3.png b/docs/docs/Images/PR3.png new file mode 100644 index 000000000..cc62c4531 Binary files /dev/null and b/docs/docs/Images/PR3.png differ diff --git a/docs/docs/Images/PR4.png b/docs/docs/Images/PR4.png new file mode 100644 index 000000000..33343f006 Binary files /dev/null and b/docs/docs/Images/PR4.png differ diff --git a/docs/docs/Images/PR5.png b/docs/docs/Images/PR5.png new file mode 100644 index 000000000..724929599 Binary files /dev/null and b/docs/docs/Images/PR5.png differ diff --git a/docs/docs/Images/PR6.png b/docs/docs/Images/PR6.png new file mode 100644 index 000000000..58b79f927 Binary files /dev/null and b/docs/docs/Images/PR6.png differ diff --git a/docs/docs/Images/PR7.png b/docs/docs/Images/PR7.png new file mode 100644 index 000000000..d3bedae8b Binary files /dev/null and b/docs/docs/Images/PR7.png differ diff --git a/docs/docs/Images/Prediction_lines.jpg b/docs/docs/Images/Prediction_lines.jpg new file mode 100644 index 000000000..4da8a44e1 Binary files /dev/null and b/docs/docs/Images/Prediction_lines.jpg differ diff --git a/docs/docs/Images/Pushover_carbs needed.PNG b/docs/docs/Images/Pushover_carbs needed.PNG new file mode 100644 index 000000000..dec454118 Binary files /dev/null and b/docs/docs/Images/Pushover_carbs needed.PNG differ diff --git a/docs/docs/Images/Pushover_carbs_needed.PNG b/docs/docs/Images/Pushover_carbs_needed.PNG new file mode 100644 index 000000000..dec454118 Binary files /dev/null and b/docs/docs/Images/Pushover_carbs_needed.PNG differ diff --git a/docs/docs/Images/Pushover_insulinReq_SMB.PNG b/docs/docs/Images/Pushover_insulinReq_SMB.PNG new file mode 100644 index 000000000..a150f9b2e Binary files /dev/null and b/docs/docs/Images/Pushover_insulinReq_SMB.PNG differ diff --git a/docs/docs/Images/Remove_future_treatments.png b/docs/docs/Images/Remove_future_treatments.png new file mode 100644 index 000000000..e20153d49 Binary files /dev/null and b/docs/docs/Images/Remove_future_treatments.png differ diff --git a/docs/docs/Images/Rig-NS_troubleshooting.jpg b/docs/docs/Images/Rig-NS_troubleshooting.jpg new file mode 100644 index 000000000..6d9233a96 Binary files /dev/null and b/docs/docs/Images/Rig-NS_troubleshooting.jpg differ diff --git a/docs/docs/Images/Rig_login_time.png b/docs/docs/Images/Rig_login_time.png new file mode 100644 index 000000000..8eaa9c92a Binary files /dev/null and b/docs/docs/Images/Rig_login_time.png differ diff --git a/docs/docs/Images/Search_documentation.png b/docs/docs/Images/Search_documentation.png new file mode 100644 index 000000000..9a8b4e591 Binary files /dev/null and b/docs/docs/Images/Search_documentation.png differ diff --git a/docs/docs/Images/Show_nav_expand.png b/docs/docs/Images/Show_nav_expand.png new file mode 100644 index 000000000..7489ac3b2 Binary files /dev/null and b/docs/docs/Images/Show_nav_expand.png differ diff --git a/docs/docs/Images/Successful_data_transfer_complete_screen_in_OpenHumans.png b/docs/docs/Images/Successful_data_transfer_complete_screen_in_OpenHumans.png new file mode 100644 index 000000000..88659452d Binary files /dev/null and b/docs/docs/Images/Successful_data_transfer_complete_screen_in_OpenHumans.png differ diff --git a/docs/docs/Images/Terminus_add_new_host.png b/docs/docs/Images/Terminus_add_new_host.png new file mode 100644 index 000000000..ff9a8e175 Binary files /dev/null and b/docs/docs/Images/Terminus_add_new_host.png differ diff --git a/docs/docs/Images/Terminus_with_hosts.png b/docs/docs/Images/Terminus_with_hosts.png new file mode 100644 index 000000000..8d2e565aa Binary files /dev/null and b/docs/docs/Images/Terminus_with_hosts.png differ diff --git a/docs/docs/Images/Troublshooting_docs_section.png b/docs/docs/Images/Troublshooting_docs_section.png new file mode 100644 index 000000000..52c7d4915 Binary files /dev/null and b/docs/docs/Images/Troublshooting_docs_section.png differ diff --git a/docs/docs/Images/Understand_documentation_basic_1.png b/docs/docs/Images/Understand_documentation_basic_1.png new file mode 100644 index 000000000..3f5fd96d3 Binary files /dev/null and b/docs/docs/Images/Understand_documentation_basic_1.png differ diff --git a/docs/docs/Images/Understand_documentation_basic_2.png b/docs/docs/Images/Understand_documentation_basic_2.png new file mode 100644 index 000000000..9d657306e Binary files /dev/null and b/docs/docs/Images/Understand_documentation_basic_2.png differ diff --git a/docs/docs/Images/WorkflowIFTTTdg01.png b/docs/docs/Images/WorkflowIFTTTdg01.png new file mode 100644 index 000000000..6bf60ccbb Binary files /dev/null and b/docs/docs/Images/WorkflowIFTTTdg01.png differ diff --git a/docs/docs/Images/WorkflowIFTTTdg02.png b/docs/docs/Images/WorkflowIFTTTdg02.png new file mode 100644 index 000000000..e3c75121c Binary files /dev/null and b/docs/docs/Images/WorkflowIFTTTdg02.png differ diff --git a/docs/docs/Images/WorkflowIFTTTdg03.png b/docs/docs/Images/WorkflowIFTTTdg03.png new file mode 100644 index 000000000..3411451aa Binary files /dev/null and b/docs/docs/Images/WorkflowIFTTTdg03.png differ diff --git a/docs/docs/Images/Workflow_TempTarget.jpg b/docs/docs/Images/Workflow_TempTarget.jpg new file mode 100644 index 000000000..96e52eeca Binary files /dev/null and b/docs/docs/Images/Workflow_TempTarget.jpg differ diff --git a/docs/docs/Images/Workflow_TodayWidget_carbs_targets.jpg b/docs/docs/Images/Workflow_TodayWidget_carbs_targets.jpg new file mode 100644 index 000000000..72e7471e5 Binary files /dev/null and b/docs/docs/Images/Workflow_TodayWidget_carbs_targets.jpg differ diff --git a/docs/docs/Images/Workflow_carbs_example.PNG b/docs/docs/Images/Workflow_carbs_example.PNG new file mode 100644 index 000000000..1a74cae90 Binary files /dev/null and b/docs/docs/Images/Workflow_carbs_example.PNG differ diff --git a/docs/docs/Images/Workflow_examples.png b/docs/docs/Images/Workflow_examples.png new file mode 100644 index 000000000..a8787bb2f Binary files /dev/null and b/docs/docs/Images/Workflow_examples.png differ diff --git a/docs/docs/Images/access_1.png b/docs/docs/Images/access_1.png new file mode 100644 index 000000000..acf2f5243 Binary files /dev/null and b/docs/docs/Images/access_1.png differ diff --git a/docs/docs/Images/access_2.png b/docs/docs/Images/access_2.png new file mode 100644 index 000000000..24ce6f5eb Binary files /dev/null and b/docs/docs/Images/access_2.png differ diff --git a/docs/docs/Images/access_3.png b/docs/docs/Images/access_3.png new file mode 100644 index 000000000..5d79802b2 Binary files /dev/null and b/docs/docs/Images/access_3.png differ diff --git a/docs/docs/Images/access_4.png b/docs/docs/Images/access_4.png new file mode 100644 index 000000000..defcd5dd6 Binary files /dev/null and b/docs/docs/Images/access_4.png differ diff --git a/docs/docs/Images/access_5.png b/docs/docs/Images/access_5.png new file mode 100644 index 000000000..f5def4663 Binary files /dev/null and b/docs/docs/Images/access_5.png differ diff --git a/docs/docs/Images/access_6.png b/docs/docs/Images/access_6.png new file mode 100644 index 000000000..f193ed7f9 Binary files /dev/null and b/docs/docs/Images/access_6.png differ diff --git a/docs/docs/Images/access_7.png b/docs/docs/Images/access_7.png new file mode 100644 index 000000000..507e5ff64 Binary files /dev/null and b/docs/docs/Images/access_7.png differ diff --git a/docs/docs/Images/access_8.png b/docs/docs/Images/access_8.png new file mode 100644 index 000000000..922a2355a Binary files /dev/null and b/docs/docs/Images/access_8.png differ diff --git a/docs/docs/Images/access_ip.png b/docs/docs/Images/access_ip.png new file mode 100644 index 000000000..f8b88ba35 Binary files /dev/null and b/docs/docs/Images/access_ip.png differ diff --git a/docs/docs/Images/access_mac1.png b/docs/docs/Images/access_mac1.png new file mode 100644 index 000000000..c1282af09 Binary files /dev/null and b/docs/docs/Images/access_mac1.png differ diff --git a/docs/docs/Images/access_mac2.png b/docs/docs/Images/access_mac2.png new file mode 100644 index 000000000..67b09884d Binary files /dev/null and b/docs/docs/Images/access_mac2.png differ diff --git a/docs/docs/Images/access_mac3.png b/docs/docs/Images/access_mac3.png new file mode 100644 index 000000000..25de29597 Binary files /dev/null and b/docs/docs/Images/access_mac3.png differ diff --git a/docs/docs/Images/access_mac_no_exec.png b/docs/docs/Images/access_mac_no_exec.png new file mode 100644 index 000000000..35146b401 Binary files /dev/null and b/docs/docs/Images/access_mac_no_exec.png differ diff --git a/docs/docs/Images/access_mac_password.png b/docs/docs/Images/access_mac_password.png new file mode 100644 index 000000000..06825be59 Binary files /dev/null and b/docs/docs/Images/access_mac_password.png differ diff --git a/docs/docs/Images/access_mac_screen.png b/docs/docs/Images/access_mac_screen.png new file mode 100644 index 000000000..3038e917d Binary files /dev/null and b/docs/docs/Images/access_mac_screen.png differ diff --git a/docs/docs/Images/access_mac_sorry.png b/docs/docs/Images/access_mac_sorry.png new file mode 100644 index 000000000..94c284649 Binary files /dev/null and b/docs/docs/Images/access_mac_sorry.png differ diff --git a/docs/docs/Images/add_new_wifi.png b/docs/docs/Images/add_new_wifi.png new file mode 100644 index 000000000..b7cb124e9 Binary files /dev/null and b/docs/docs/Images/add_new_wifi.png differ diff --git a/docs/docs/Images/add_widget_workflow.png b/docs/docs/Images/add_widget_workflow.png new file mode 100644 index 000000000..4654248de Binary files /dev/null and b/docs/docs/Images/add_widget_workflow.png differ diff --git a/docs/docs/Images/admin_tools.jpg b/docs/docs/Images/admin_tools.jpg new file mode 100644 index 000000000..b1767fcfd Binary files /dev/null and b/docs/docs/Images/admin_tools.jpg differ diff --git a/docs/docs/Images/aggregating_logs.png b/docs/docs/Images/aggregating_logs.png new file mode 100644 index 000000000..5775cae74 Binary files /dev/null and b/docs/docs/Images/aggregating_logs.png differ diff --git a/docs/docs/Images/antenna0.jpg b/docs/docs/Images/antenna0.jpg new file mode 100644 index 000000000..d1f723848 Binary files /dev/null and b/docs/docs/Images/antenna0.jpg differ diff --git a/docs/docs/Images/antenna1.jpg b/docs/docs/Images/antenna1.jpg new file mode 100644 index 000000000..12c917fdb Binary files /dev/null and b/docs/docs/Images/antenna1.jpg differ diff --git a/docs/docs/Images/apache_chainsaw.jpg b/docs/docs/Images/apache_chainsaw.jpg new file mode 100644 index 000000000..51a217699 Binary files /dev/null and b/docs/docs/Images/apache_chainsaw.jpg differ diff --git a/docs/docs/Images/avahi-fix.png b/docs/docs/Images/avahi-fix.png new file mode 100644 index 000000000..ec8f8b4fb Binary files /dev/null and b/docs/docs/Images/avahi-fix.png differ diff --git a/docs/docs/Images/avahi-fix2.png b/docs/docs/Images/avahi-fix2.png new file mode 100644 index 000000000..4db58b633 Binary files /dev/null and b/docs/docs/Images/avahi-fix2.png differ diff --git a/docs/docs/Images/avahi.png b/docs/docs/Images/avahi.png new file mode 100644 index 000000000..b95667ad5 Binary files /dev/null and b/docs/docs/Images/avahi.png differ diff --git a/docs/docs/Images/avahi2.png b/docs/docs/Images/avahi2.png new file mode 100644 index 000000000..9dba2bb91 Binary files /dev/null and b/docs/docs/Images/avahi2.png differ diff --git a/docs/docs/Images/build-your-rig/RPi_RFM69HCW_case_ports_view.jpg b/docs/docs/Images/build-your-rig/RPi_RFM69HCW_case_ports_view.jpg new file mode 100644 index 000000000..93002869c Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_RFM69HCW_case_ports_view.jpg differ diff --git a/docs/docs/Images/build-your-rig/RPi_breadboard_connected_to_RFM69HCW.jpg b/docs/docs/Images/build-your-rig/RPi_breadboard_connected_to_RFM69HCW.jpg new file mode 100644 index 000000000..97fc7eeaa Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_breadboard_connected_to_RFM69HCW.jpg differ diff --git a/docs/docs/Images/build-your-rig/RPi_open_case_with_Pi_on_top.jpg b/docs/docs/Images/build-your-rig/RPi_open_case_with_Pi_on_top.jpg new file mode 100644 index 000000000..5a46191e7 Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_open_case_with_Pi_on_top.jpg differ diff --git a/docs/docs/Images/build-your-rig/RPi_open_case_with_battery_view_on_RFM69HCW.jpg b/docs/docs/Images/build-your-rig/RPi_open_case_with_battery_view_on_RFM69HCW.jpg new file mode 100644 index 000000000..3d67fe22d Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_open_case_with_battery_view_on_RFM69HCW.jpg differ diff --git a/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW.jpg b/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW.jpg new file mode 100644 index 000000000..4702a26ae Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW.jpg differ diff --git a/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW_top_view.jpg b/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW_top_view.jpg new file mode 100644 index 000000000..8b9c286f8 Binary files /dev/null and b/docs/docs/Images/build-your-rig/RPi_soldered_RFM69HCW_top_view.jpg differ diff --git a/docs/docs/Images/build-your-rig/Rig_case_with_pump.jpg b/docs/docs/Images/build-your-rig/Rig_case_with_pump.jpg new file mode 100644 index 000000000..8f561e08c Binary files /dev/null and b/docs/docs/Images/build-your-rig/Rig_case_with_pump.jpg differ diff --git a/docs/docs/Images/build-your-rig/fat32.png b/docs/docs/Images/build-your-rig/fat32.png new file mode 100644 index 000000000..5f8c0ab89 Binary files /dev/null and b/docs/docs/Images/build-your-rig/fat32.png differ diff --git a/docs/docs/Images/build-your-rig/first-loop.png b/docs/docs/Images/build-your-rig/first-loop.png new file mode 100644 index 000000000..1402fbf94 Binary files /dev/null and b/docs/docs/Images/build-your-rig/first-loop.png differ diff --git a/docs/docs/Images/build-your-rig/loop-success.png b/docs/docs/Images/build-your-rig/loop-success.png new file mode 100644 index 000000000..d34877b12 Binary files /dev/null and b/docs/docs/Images/build-your-rig/loop-success.png differ diff --git a/docs/docs/Images/build-your-rig/pi-curl-fail.png b/docs/docs/Images/build-your-rig/pi-curl-fail.png new file mode 100644 index 000000000..47a25028b Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-curl-fail.png differ diff --git a/docs/docs/Images/build-your-rig/pi-curl-success.png b/docs/docs/Images/build-your-rig/pi-curl-success.png new file mode 100644 index 000000000..966ae28aa Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-curl-success.png differ diff --git a/docs/docs/Images/build-your-rig/pi-insert.jpg b/docs/docs/Images/build-your-rig/pi-insert.jpg new file mode 100644 index 000000000..7139bb3fb Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-insert.jpg differ diff --git a/docs/docs/Images/build-your-rig/pi-install-success.png b/docs/docs/Images/build-your-rig/pi-install-success.png new file mode 100644 index 000000000..f84e99397 Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-install-success.png differ diff --git a/docs/docs/Images/build-your-rig/pi-loop-install.png b/docs/docs/Images/build-your-rig/pi-loop-install.png new file mode 100644 index 000000000..9463b487c Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-loop-install.png differ diff --git a/docs/docs/Images/build-your-rig/pi-pibakery.png b/docs/docs/Images/build-your-rig/pi-pibakery.png new file mode 100644 index 000000000..11ab1456e Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-pibakery.png differ diff --git a/docs/docs/Images/build-your-rig/pi-raspian-lite.png b/docs/docs/Images/build-your-rig/pi-raspian-lite.png new file mode 100644 index 000000000..27c31549f Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-raspian-lite.png differ diff --git a/docs/docs/Images/build-your-rig/pi-setup-stuck.png b/docs/docs/Images/build-your-rig/pi-setup-stuck.png new file mode 100644 index 000000000..c1dd4cb88 Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-setup-stuck.png differ diff --git a/docs/docs/Images/build-your-rig/pi-step1.png b/docs/docs/Images/build-your-rig/pi-step1.png new file mode 100644 index 000000000..ec78863bd Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-step1.png differ diff --git a/docs/docs/Images/build-your-rig/pi-step2.png b/docs/docs/Images/build-your-rig/pi-step2.png new file mode 100644 index 000000000..fd9dd3719 Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-step2.png differ diff --git a/docs/docs/Images/build-your-rig/pi-step3.png b/docs/docs/Images/build-your-rig/pi-step3.png new file mode 100644 index 000000000..8a4abf3fe Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-step3.png differ diff --git a/docs/docs/Images/build-your-rig/pi-step4.png b/docs/docs/Images/build-your-rig/pi-step4.png new file mode 100644 index 000000000..070a5cb99 Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-step4.png differ diff --git a/docs/docs/Images/build-your-rig/pi-step5.png b/docs/docs/Images/build-your-rig/pi-step5.png new file mode 100644 index 000000000..938aeb113 Binary files /dev/null and b/docs/docs/Images/build-your-rig/pi-step5.png differ diff --git a/docs/docs/Images/build-your-rig/rpii2RFM69HCW.JPG b/docs/docs/Images/build-your-rig/rpii2RFM69HCW.JPG new file mode 100644 index 000000000..d7dd5a346 Binary files /dev/null and b/docs/docs/Images/build-your-rig/rpii2RFM69HCW.JPG differ diff --git a/docs/docs/Images/build-your-rig/sample-setup.png b/docs/docs/Images/build-your-rig/sample-setup.png new file mode 100644 index 000000000..96e0d8963 Binary files /dev/null and b/docs/docs/Images/build-your-rig/sample-setup.png differ diff --git a/docs/docs/Images/carbs-only.PNG b/docs/docs/Images/carbs-only.PNG new file mode 100644 index 000000000..f65402571 Binary files /dev/null and b/docs/docs/Images/carbs-only.PNG differ diff --git a/docs/docs/Images/carbs-with-insulin.PNG b/docs/docs/Images/carbs-with-insulin.PNG new file mode 100644 index 000000000..8ef3a6a7a Binary files /dev/null and b/docs/docs/Images/carbs-with-insulin.PNG differ diff --git a/docs/docs/Images/clone_oref0.png b/docs/docs/Images/clone_oref0.png new file mode 100644 index 000000000..c364f5865 Binary files /dev/null and b/docs/docs/Images/clone_oref0.png differ diff --git a/docs/docs/Images/collection-name.png b/docs/docs/Images/collection-name.png new file mode 100644 index 000000000..3fdcba7ae Binary files /dev/null and b/docs/docs/Images/collection-name.png differ diff --git a/docs/docs/Images/command-add.png b/docs/docs/Images/command-add.png new file mode 100644 index 000000000..d8c443138 Binary files /dev/null and b/docs/docs/Images/command-add.png differ diff --git a/docs/docs/Images/command-results.png b/docs/docs/Images/command-results.png new file mode 100644 index 000000000..ae3cc6225 Binary files /dev/null and b/docs/docs/Images/command-results.png differ diff --git a/docs/docs/Images/create_applet_workflow.png b/docs/docs/Images/create_applet_workflow.png new file mode 100644 index 000000000..a2effe933 Binary files /dev/null and b/docs/docs/Images/create_applet_workflow.png differ diff --git a/docs/docs/Images/create_carbs_recipe.png b/docs/docs/Images/create_carbs_recipe.png new file mode 100644 index 000000000..c4bd0b2dd Binary files /dev/null and b/docs/docs/Images/create_carbs_recipe.png differ diff --git a/docs/docs/Images/cron_reboot.png b/docs/docs/Images/cron_reboot.png new file mode 100644 index 000000000..9e8997be6 Binary files /dev/null and b/docs/docs/Images/cron_reboot.png differ diff --git a/docs/docs/Images/custom-commands.png b/docs/docs/Images/custom-commands.png new file mode 100644 index 000000000..86a894f55 Binary files /dev/null and b/docs/docs/Images/custom-commands.png differ diff --git a/docs/docs/Images/customize-iterate/HRS-Carb.jpg b/docs/docs/Images/customize-iterate/HRS-Carb.jpg new file mode 100644 index 000000000..3c4fd9ca5 Binary files /dev/null and b/docs/docs/Images/customize-iterate/HRS-Carb.jpg differ diff --git a/docs/docs/Images/customize-iterate/HRS-New.jpg b/docs/docs/Images/customize-iterate/HRS-New.jpg new file mode 100644 index 000000000..15b1023df Binary files /dev/null and b/docs/docs/Images/customize-iterate/HRS-New.jpg differ diff --git a/docs/docs/Images/customize-iterate/HRS-Start.jpg b/docs/docs/Images/customize-iterate/HRS-Start.jpg new file mode 100644 index 000000000..540a471e6 Binary files /dev/null and b/docs/docs/Images/customize-iterate/HRS-Start.jpg differ diff --git a/docs/docs/Images/customize-iterate/HRS-Variables-1.jpg b/docs/docs/Images/customize-iterate/HRS-Variables-1.jpg new file mode 100644 index 000000000..8c140f339 Binary files /dev/null and b/docs/docs/Images/customize-iterate/HRS-Variables-1.jpg differ diff --git a/docs/docs/Images/customize-iterate/HRS-Variables-2.jpg b/docs/docs/Images/customize-iterate/HRS-Variables-2.jpg new file mode 100644 index 000000000..892728883 Binary files /dev/null and b/docs/docs/Images/customize-iterate/HRS-Variables-2.jpg differ diff --git a/docs/docs/Images/customize-iterate/autosens-adjust.png b/docs/docs/Images/customize-iterate/autosens-adjust.png new file mode 100644 index 000000000..9a144361f Binary files /dev/null and b/docs/docs/Images/customize-iterate/autosens-adjust.png differ diff --git a/docs/docs/Images/delete-docs.png b/docs/docs/Images/delete-docs.png new file mode 100644 index 000000000..5755334e7 Binary files /dev/null and b/docs/docs/Images/delete-docs.png differ diff --git a/docs/docs/Images/dependencies_success.png b/docs/docs/Images/dependencies_success.png new file mode 100644 index 000000000..07136162f Binary files /dev/null and b/docs/docs/Images/dependencies_success.png differ diff --git a/docs/docs/Images/edison_driver_121.png b/docs/docs/Images/edison_driver_121.png new file mode 100644 index 000000000..def56eab7 Binary files /dev/null and b/docs/docs/Images/edison_driver_121.png differ diff --git a/docs/docs/Images/edit_network_scanner.png b/docs/docs/Images/edit_network_scanner.png new file mode 100644 index 000000000..f330e4839 Binary files /dev/null and b/docs/docs/Images/edit_network_scanner.png differ diff --git a/docs/docs/Images/error-messages.png b/docs/docs/Images/error-messages.png new file mode 100644 index 000000000..716da23b3 Binary files /dev/null and b/docs/docs/Images/error-messages.png differ diff --git a/docs/docs/Images/example_exponential_growth_and_decay.png b/docs/docs/Images/example_exponential_growth_and_decay.png new file mode 100644 index 000000000..f18be33fd Binary files /dev/null and b/docs/docs/Images/example_exponential_growth_and_decay.png differ diff --git a/docs/docs/Images/explorerhat.png b/docs/docs/Images/explorerhat.png new file mode 100644 index 000000000..56281e884 Binary files /dev/null and b/docs/docs/Images/explorerhat.png differ diff --git a/docs/docs/Images/extra-insulin.PNG b/docs/docs/Images/extra-insulin.PNG new file mode 100644 index 000000000..42f911732 Binary files /dev/null and b/docs/docs/Images/extra-insulin.PNG differ diff --git a/docs/docs/Images/git-lock.png b/docs/docs/Images/git-lock.png new file mode 100644 index 000000000..e072323c2 Binary files /dev/null and b/docs/docs/Images/git-lock.png differ diff --git a/docs/docs/Images/gitter_marks.jpg b/docs/docs/Images/gitter_marks.jpg new file mode 100644 index 000000000..bba94a98e Binary files /dev/null and b/docs/docs/Images/gitter_marks.jpg differ diff --git a/docs/docs/Images/gitter_pm.jpg b/docs/docs/Images/gitter_pm.jpg new file mode 100644 index 000000000..85c655352 Binary files /dev/null and b/docs/docs/Images/gitter_pm.jpg differ diff --git a/docs/docs/Images/hashed_API.png b/docs/docs/Images/hashed_API.png new file mode 100644 index 000000000..3ea1d2b1f Binary files /dev/null and b/docs/docs/Images/hashed_API.png differ diff --git a/docs/docs/Images/hotspot_running.png b/docs/docs/Images/hotspot_running.png new file mode 100644 index 000000000..0dbc738ab Binary files /dev/null and b/docs/docs/Images/hotspot_running.png differ diff --git a/docs/docs/Images/iPhone-Shortcuts-AskForInput.jpeg b/docs/docs/Images/iPhone-Shortcuts-AskForInput.jpeg new file mode 100644 index 000000000..1060a6e89 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-AskForInput.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-GetContentsOfUrl.jpeg b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-GetContentsOfUrl.jpeg new file mode 100644 index 000000000..557065479 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-GetContentsOfUrl.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-Text.jpeg b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-Text.jpeg new file mode 100644 index 000000000..d3dba281f Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-Text.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-if.jpeg b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-if.jpeg new file mode 100644 index 000000000..9963c34f6 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget-if.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget.png b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget.png new file mode 100644 index 000000000..360bff505 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-CancelTempTarget.png differ diff --git a/docs/docs/Images/iPhone-Shortcuts-an-example-bad-secret.png b/docs/docs/Images/iPhone-Shortcuts-an-example-bad-secret.png new file mode 100644 index 000000000..2782fcf7d Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-an-example-bad-secret.png differ diff --git a/docs/docs/Images/iPhone-Shortcuts-an-example-bad-url.png b/docs/docs/Images/iPhone-Shortcuts-an-example-bad-url.png new file mode 100644 index 000000000..5a0997adc Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-an-example-bad-url.png differ diff --git a/docs/docs/Images/iPhone-Shortcuts-example-bad-secret.jpeg b/docs/docs/Images/iPhone-Shortcuts-example-bad-secret.jpeg new file mode 100644 index 000000000..deff761dd Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-example-bad-secret.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-example-bad-url.jpeg b/docs/docs/Images/iPhone-Shortcuts-example-bad-url.jpeg new file mode 100644 index 000000000..c6fb440f3 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-example-bad-url.jpeg differ diff --git a/docs/docs/Images/iPhone-Shortcuts-example-bad-url.png b/docs/docs/Images/iPhone-Shortcuts-example-bad-url.png new file mode 100644 index 000000000..1f2a29825 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-example-bad-url.png differ diff --git a/docs/docs/Images/iPhone-Shortcuts-in-appstore.jpeg b/docs/docs/Images/iPhone-Shortcuts-in-appstore.jpeg new file mode 100644 index 000000000..aac0f8e84 Binary files /dev/null and b/docs/docs/Images/iPhone-Shortcuts-in-appstore.jpeg differ diff --git a/docs/docs/Images/ifconfig_example.png b/docs/docs/Images/ifconfig_example.png new file mode 100644 index 000000000..ca0979e90 Binary files /dev/null and b/docs/docs/Images/ifconfig_example.png differ diff --git a/docs/docs/Images/insulin-only.PNG b/docs/docs/Images/insulin-only.PNG new file mode 100644 index 000000000..718965e5e Binary files /dev/null and b/docs/docs/Images/insulin-only.PNG differ diff --git a/docs/docs/Images/late-meal.PNG b/docs/docs/Images/late-meal.PNG new file mode 100644 index 000000000..882ca3f67 Binary files /dev/null and b/docs/docs/Images/late-meal.PNG differ diff --git a/docs/docs/Images/localhost.png b/docs/docs/Images/localhost.png new file mode 100644 index 000000000..31850c380 Binary files /dev/null and b/docs/docs/Images/localhost.png differ diff --git a/docs/docs/Images/log_destinations.png b/docs/docs/Images/log_destinations.png new file mode 100644 index 000000000..9daacf07c Binary files /dev/null and b/docs/docs/Images/log_destinations.png differ diff --git a/docs/docs/Images/log_filters.png b/docs/docs/Images/log_filters.png new file mode 100644 index 000000000..003137183 Binary files /dev/null and b/docs/docs/Images/log_filters.png differ diff --git a/docs/docs/Images/looped.jpg b/docs/docs/Images/looped.jpg new file mode 100644 index 000000000..a72968117 Binary files /dev/null and b/docs/docs/Images/looped.jpg differ diff --git a/docs/docs/Images/max-safe-basal.jpg b/docs/docs/Images/max-safe-basal.jpg new file mode 100644 index 000000000..1df5b57a6 Binary files /dev/null and b/docs/docs/Images/max-safe-basal.jpg differ diff --git a/docs/docs/Images/mlab-home.png b/docs/docs/Images/mlab-home.png new file mode 100644 index 000000000..49634e517 Binary files /dev/null and b/docs/docs/Images/mlab-home.png differ diff --git a/docs/docs/Images/mlab_compact1.png b/docs/docs/Images/mlab_compact1.png new file mode 100644 index 000000000..a2d8203e9 Binary files /dev/null and b/docs/docs/Images/mlab_compact1.png differ diff --git a/docs/docs/Images/mlab_compact2.png b/docs/docs/Images/mlab_compact2.png new file mode 100644 index 000000000..1491927fc Binary files /dev/null and b/docs/docs/Images/mlab_compact2.png differ diff --git a/docs/docs/Images/mlab_compact3.png b/docs/docs/Images/mlab_compact3.png new file mode 100644 index 000000000..c655a6045 Binary files /dev/null and b/docs/docs/Images/mlab_compact3.png differ diff --git a/docs/docs/Images/mlab_link.jpg b/docs/docs/Images/mlab_link.jpg new file mode 100644 index 000000000..50335e8b5 Binary files /dev/null and b/docs/docs/Images/mlab_link.jpg differ diff --git a/docs/docs/Images/mlab_size.jpg b/docs/docs/Images/mlab_size.jpg new file mode 100644 index 000000000..ea2aed5a6 Binary files /dev/null and b/docs/docs/Images/mlab_size.jpg differ diff --git a/docs/docs/Images/mlab_size2.jpg b/docs/docs/Images/mlab_size2.jpg new file mode 100644 index 000000000..31b74a3be Binary files /dev/null and b/docs/docs/Images/mlab_size2.jpg differ diff --git a/docs/docs/Images/mmtune.png b/docs/docs/Images/mmtune.png new file mode 100644 index 000000000..c0964bcf8 Binary files /dev/null and b/docs/docs/Images/mmtune.png differ diff --git a/docs/docs/Images/navigate.png b/docs/docs/Images/navigate.png new file mode 100644 index 000000000..218764ef7 Binary files /dev/null and b/docs/docs/Images/navigate.png differ diff --git a/docs/docs/Images/network-filter.png b/docs/docs/Images/network-filter.png new file mode 100644 index 000000000..c4f1a14bf Binary files /dev/null and b/docs/docs/Images/network-filter.png differ diff --git a/docs/docs/Images/network_list_in_rig.png b/docs/docs/Images/network_list_in_rig.png new file mode 100644 index 000000000..b1bfe7838 Binary files /dev/null and b/docs/docs/Images/network_list_in_rig.png differ diff --git a/docs/docs/Images/network_scanner.jpg b/docs/docs/Images/network_scanner.jpg new file mode 100644 index 000000000..1158d01fd Binary files /dev/null and b/docs/docs/Images/network_scanner.jpg differ diff --git a/docs/docs/Images/network_scanner.png b/docs/docs/Images/network_scanner.png new file mode 100644 index 000000000..28191f976 Binary files /dev/null and b/docs/docs/Images/network_scanner.png differ diff --git a/docs/docs/Images/nightscout/add_vars.jpg b/docs/docs/Images/nightscout/add_vars.jpg new file mode 100644 index 000000000..6a55e2df2 Binary files /dev/null and b/docs/docs/Images/nightscout/add_vars.jpg differ diff --git a/docs/docs/Images/nightscout/deploy_branch.jpg b/docs/docs/Images/nightscout/deploy_branch.jpg new file mode 100644 index 000000000..0696f96a0 Binary files /dev/null and b/docs/docs/Images/nightscout/deploy_branch.jpg differ diff --git a/docs/docs/Images/nightscout/deploy_button.jpg b/docs/docs/Images/nightscout/deploy_button.jpg new file mode 100644 index 000000000..fbbc4802b Binary files /dev/null and b/docs/docs/Images/nightscout/deploy_button.jpg differ diff --git a/docs/docs/Images/nightscout/deploy_heroku.jpg b/docs/docs/Images/nightscout/deploy_heroku.jpg new file mode 100644 index 000000000..757343eb4 Binary files /dev/null and b/docs/docs/Images/nightscout/deploy_heroku.jpg differ diff --git a/docs/docs/Images/nightscout/deploy_success.jpg b/docs/docs/Images/nightscout/deploy_success.jpg new file mode 100644 index 000000000..ed7311ddf Binary files /dev/null and b/docs/docs/Images/nightscout/deploy_success.jpg differ diff --git a/docs/docs/Images/nightscout/heroku_signup.jpg b/docs/docs/Images/nightscout/heroku_signup.jpg new file mode 100644 index 000000000..6b7739280 Binary files /dev/null and b/docs/docs/Images/nightscout/heroku_signup.jpg differ diff --git a/docs/docs/Images/nightscout/no_profile.jpg b/docs/docs/Images/nightscout/no_profile.jpg new file mode 100644 index 000000000..b143ae95d Binary files /dev/null and b/docs/docs/Images/nightscout/no_profile.jpg differ diff --git a/docs/docs/Images/nightscout/ns_deploybranch.png b/docs/docs/Images/nightscout/ns_deploybranch.png new file mode 100644 index 000000000..0ddf2bae7 --- /dev/null +++ b/docs/docs/Images/nightscout/ns_deploybranch.png @@ -0,0 +1 @@ +i diff --git a/docs/docs/Images/nightscout/ns_fork.jpg b/docs/docs/Images/nightscout/ns_fork.jpg new file mode 100644 index 000000000..b2eb4d101 Binary files /dev/null and b/docs/docs/Images/nightscout/ns_fork.jpg differ diff --git a/docs/docs/Images/nightscout/open_app.jpg b/docs/docs/Images/nightscout/open_app.jpg new file mode 100644 index 000000000..0dd142992 Binary files /dev/null and b/docs/docs/Images/nightscout/open_app.jpg differ diff --git a/docs/docs/Images/nightscout/profile.jpg b/docs/docs/Images/nightscout/profile.jpg new file mode 100644 index 000000000..ec4def0ea Binary files /dev/null and b/docs/docs/Images/nightscout/profile.jpg differ diff --git a/docs/docs/Images/nightscout/role-oref0rig.png b/docs/docs/Images/nightscout/role-oref0rig.png new file mode 100644 index 000000000..e834c2eda Binary files /dev/null and b/docs/docs/Images/nightscout/role-oref0rig.png differ diff --git a/docs/docs/Images/nightscout/settings_heroku.jpg b/docs/docs/Images/nightscout/settings_heroku.jpg new file mode 100644 index 000000000..fb5b87bea Binary files /dev/null and b/docs/docs/Images/nightscout/settings_heroku.jpg differ diff --git a/docs/docs/Images/nightscout/settings_ns.jpg b/docs/docs/Images/nightscout/settings_ns.jpg new file mode 100644 index 000000000..b93a24445 Binary files /dev/null and b/docs/docs/Images/nightscout/settings_ns.jpg differ diff --git a/docs/docs/Images/nightscout/subject-oref0rig.png b/docs/docs/Images/nightscout/subject-oref0rig.png new file mode 100644 index 000000000..0a4807f0e Binary files /dev/null and b/docs/docs/Images/nightscout/subject-oref0rig.png differ diff --git a/docs/docs/Images/npm_screenshot.png b/docs/docs/Images/npm_screenshot.png new file mode 100644 index 000000000..7f770a919 Binary files /dev/null and b/docs/docs/Images/npm_screenshot.png differ diff --git a/docs/docs/Images/offline_webpage_1.png b/docs/docs/Images/offline_webpage_1.png new file mode 100644 index 000000000..08e4e8e5d Binary files /dev/null and b/docs/docs/Images/offline_webpage_1.png differ diff --git a/docs/docs/Images/offline_webpage_2.png b/docs/docs/Images/offline_webpage_2.png new file mode 100644 index 000000000..2ff84cb48 Binary files /dev/null and b/docs/docs/Images/offline_webpage_2.png differ diff --git a/docs/docs/Images/offline_webpage_3.png b/docs/docs/Images/offline_webpage_3.png new file mode 100644 index 000000000..ab01d15a3 Binary files /dev/null and b/docs/docs/Images/offline_webpage_3.png differ diff --git a/docs/docs/Images/oh_your_data.png b/docs/docs/Images/oh_your_data.png new file mode 100644 index 000000000..2f1ca373d Binary files /dev/null and b/docs/docs/Images/oh_your_data.png differ diff --git a/docs/docs/Images/otg.jpg b/docs/docs/Images/otg.jpg new file mode 100644 index 000000000..d723d64dd Binary files /dev/null and b/docs/docs/Images/otg.jpg differ diff --git a/docs/docs/Images/papertrail-mmtune-sample.png b/docs/docs/Images/papertrail-mmtune-sample.png new file mode 100644 index 000000000..1e40c1a69 Binary files /dev/null and b/docs/docs/Images/papertrail-mmtune-sample.png differ diff --git a/docs/docs/Images/papertrail.png b/docs/docs/Images/papertrail.png new file mode 100644 index 000000000..40885c5a0 Binary files /dev/null and b/docs/docs/Images/papertrail.png differ diff --git a/docs/docs/Images/papertrail_home_buttons.png b/docs/docs/Images/papertrail_home_buttons.png new file mode 100644 index 000000000..0cc984298 Binary files /dev/null and b/docs/docs/Images/papertrail_home_buttons.png differ diff --git a/docs/docs/Images/papertrail_host.png b/docs/docs/Images/papertrail_host.png new file mode 100644 index 000000000..10e709d4d Binary files /dev/null and b/docs/docs/Images/papertrail_host.png differ diff --git a/docs/docs/Images/personal_hotspot.png b/docs/docs/Images/personal_hotspot.png new file mode 100644 index 000000000..fe08fecb0 Binary files /dev/null and b/docs/docs/Images/personal_hotspot.png differ diff --git a/docs/docs/Images/pill_example_SMB_issuing_SMB.png b/docs/docs/Images/pill_example_SMB_issuing_SMB.png new file mode 100644 index 000000000..6292d388e Binary files /dev/null and b/docs/docs/Images/pill_example_SMB_issuing_SMB.png differ diff --git a/docs/docs/Images/pill_example_SMB_low_temp.png b/docs/docs/Images/pill_example_SMB_low_temp.png new file mode 100644 index 000000000..9c48bdbea Binary files /dev/null and b/docs/docs/Images/pill_example_SMB_low_temp.png differ diff --git a/docs/docs/Images/pill_example_temp_basal.png b/docs/docs/Images/pill_example_temp_basal.png new file mode 100644 index 000000000..cbb1c4182 Binary files /dev/null and b/docs/docs/Images/pill_example_temp_basal.png differ diff --git a/docs/docs/Images/poor_tuning.png b/docs/docs/Images/poor_tuning.png new file mode 100644 index 000000000..3de187509 Binary files /dev/null and b/docs/docs/Images/poor_tuning.png differ diff --git a/docs/docs/Images/sample-wifi-file.png b/docs/docs/Images/sample-wifi-file.png new file mode 100644 index 000000000..a1e2012e0 Binary files /dev/null and b/docs/docs/Images/sample-wifi-file.png differ diff --git a/docs/docs/Images/save_filter.png b/docs/docs/Images/save_filter.png new file mode 100644 index 000000000..170d6c76f Binary files /dev/null and b/docs/docs/Images/save_filter.png differ diff --git a/docs/docs/Images/scan_settings.png b/docs/docs/Images/scan_settings.png new file mode 100644 index 000000000..8ff35c126 Binary files /dev/null and b/docs/docs/Images/scan_settings.png differ diff --git a/docs/docs/Images/setup_entries.png b/docs/docs/Images/setup_entries.png new file mode 100644 index 000000000..eee7bb497 Binary files /dev/null and b/docs/docs/Images/setup_entries.png differ diff --git a/docs/docs/Images/simplified-carbs-plus-insulin.PNG b/docs/docs/Images/simplified-carbs-plus-insulin.PNG new file mode 100644 index 000000000..53b01b0d7 Binary files /dev/null and b/docs/docs/Images/simplified-carbs-plus-insulin.PNG differ diff --git a/docs/docs/Images/simplified-carbs-to-BG.PNG b/docs/docs/Images/simplified-carbs-to-BG.PNG new file mode 100644 index 000000000..fe27b5f46 Binary files /dev/null and b/docs/docs/Images/simplified-carbs-to-BG.PNG differ diff --git a/docs/docs/Images/simplified-insulin-to-BG.PNG b/docs/docs/Images/simplified-insulin-to-BG.PNG new file mode 100644 index 000000000..b1c45f8a1 Binary files /dev/null and b/docs/docs/Images/simplified-insulin-to-BG.PNG differ diff --git a/docs/docs/Images/spoof-no-box.png b/docs/docs/Images/spoof-no-box.png new file mode 100644 index 000000000..8f8bdd2f1 Binary files /dev/null and b/docs/docs/Images/spoof-no-box.png differ diff --git a/docs/docs/Images/subg_rfspy.png b/docs/docs/Images/subg_rfspy.png new file mode 100644 index 000000000..a8c199bd4 Binary files /dev/null and b/docs/docs/Images/subg_rfspy.png differ diff --git a/docs/docs/Images/subg_rfspy2.jpg b/docs/docs/Images/subg_rfspy2.jpg new file mode 100644 index 000000000..8728fae32 Binary files /dev/null and b/docs/docs/Images/subg_rfspy2.jpg differ diff --git a/docs/docs/Images/successful_network_scanner.png b/docs/docs/Images/successful_network_scanner.png new file mode 100644 index 000000000..e7a3ea36e Binary files /dev/null and b/docs/docs/Images/successful_network_scanner.png differ diff --git a/docs/docs/Images/terminus.png b/docs/docs/Images/terminus.png new file mode 100644 index 000000000..940b57ded Binary files /dev/null and b/docs/docs/Images/terminus.png differ diff --git a/docs/docs/Images/termius.jpg b/docs/docs/Images/termius.jpg new file mode 100644 index 000000000..0671cf0c5 Binary files /dev/null and b/docs/docs/Images/termius.jpg differ diff --git a/docs/docs/Images/transfer_complete.png b/docs/docs/Images/transfer_complete.png new file mode 100644 index 000000000..c1796ce81 Binary files /dev/null and b/docs/docs/Images/transfer_complete.png differ diff --git a/docs/docs/Images/update_config_adjustment.png b/docs/docs/Images/update_config_adjustment.png new file mode 100644 index 000000000..1a250716e Binary files /dev/null and b/docs/docs/Images/update_config_adjustment.png differ diff --git a/docs/docs/Images/versions.jpg b/docs/docs/Images/versions.jpg new file mode 100644 index 000000000..bae33d3c3 Binary files /dev/null and b/docs/docs/Images/versions.jpg differ diff --git a/docs/docs/Images/wifi-scan.jpg b/docs/docs/Images/wifi-scan.jpg new file mode 100644 index 000000000..9865a01dd Binary files /dev/null and b/docs/docs/Images/wifi-scan.jpg differ diff --git a/docs/docs/Images/workflow_sync.png b/docs/docs/Images/workflow_sync.png new file mode 100644 index 000000000..a716520ec Binary files /dev/null and b/docs/docs/Images/workflow_sync.png differ diff --git a/docs/docs/Images/xDrip_REST_API_cropped.png b/docs/docs/Images/xDrip_REST_API_cropped.png new file mode 100644 index 000000000..e062495be Binary files /dev/null and b/docs/docs/Images/xDrip_REST_API_cropped.png differ diff --git a/docs/docs/Images/xDrip_offline_1.png b/docs/docs/Images/xDrip_offline_1.png new file mode 100644 index 000000000..2d92147dc Binary files /dev/null and b/docs/docs/Images/xDrip_offline_1.png differ diff --git a/docs/docs/Images/xDrip_offline_2.png b/docs/docs/Images/xDrip_offline_2.png new file mode 100644 index 000000000..75a3bf321 Binary files /dev/null and b/docs/docs/Images/xDrip_offline_2.png differ diff --git a/docs/docs/Images/xml/Building_OpenAPS_steps.xml b/docs/docs/Images/xml/Building_OpenAPS_steps.xml new file mode 100644 index 000000000..0871d98a3 --- /dev/null +++ b/docs/docs/Images/xml/Building_OpenAPS_steps.xml @@ -0,0 +1 @@ +
-A custom designed Bluetooth Smart (BLE) to 916MHz module. It can be used to bridge any BLE capable smartphone to the world of 916Mhz based devices. This project is focused on talking to Medtronic insulin pumps and sensors. There is also a Gitter channel dedicated to discussion on the RileyLink [here](https://gitter.im/ps2/rileylink). - -* **Tidepool** (http://tidepool.org/ and https://github.com/tidepool-org)
-Notably, work on Boston University iLet UI (https://github.com/tidepool-org/bionicpancreas) and open-source tools for visualization. - -* **Perceptus** (http://perceptus.org) - more data visualization tools - - -# Commercial APS Efforts - -There are currently several commercial closed-loop products in development by old and new companies in the diabetes treatment space. These include: - -* [Medtronic MiniMed 640G](https://www.medtronic-diabetes.com.au/pump-therapy/640g) -* [Medtronic MiniMed 670G](http://diatribe.org/drugdevice-name/medtronic-minimed-670g) -* [TypeZero Technologies](http://www.typezero.com/) -* [Bigfoot Biomedical](http://www.bigfootbiomedical.com/) -* [Boston University's iLet, formerly known as the "Bionic Pancreas"](http://sites.bu.edu/bionicpancreas/) - diff --git a/docs/docs/Resources/switching-between-DIY-systems.md b/docs/docs/Resources/switching-between-DIY-systems.md new file mode 100644 index 000000000..b050764e3 --- /dev/null +++ b/docs/docs/Resources/switching-between-DIY-systems.md @@ -0,0 +1,162 @@ +# Tips for switching from another DIY closed loop system to OpenAPS rig (or running both) + +**Note:** This is a high level switchover cheat sheet, and will primarily discuss Loop and OpenAPS comparisons (but may be relevant for helping you understand the differences of OpenAPS from other DIY systems as well). For the purposes of this Loop-to-OpenAPS switchover cheat sheet, we’re going to assume a few things and therefore are not covering all the possible options for setting up an OpenAPS rig. If you want to find out options that exist beyond the assumptions in this page, please refer back to the [main OpenAPS documentation pages](http://openaps.readthedocs.org/en/latest/). In fact, please refer back to the main documentation sections anyway. They really have a lot of information you’ll find helpful. This page is more of a quick cheat sheet to help you get the high levels rather than a thorough setup guide (that’s what the OpenAPS documentation is for). There will be links throughout to the relevant OpenAPS documentation for more details when referenced. + +### Other things you should know before starting: + +* OpenAPS is similar to Loop (they’re both temp basal-based DIY closed loops), but different, even beyond the hardware. The algorithm (looping code) of OpenAPS is referred to as “[oref0](https://github.com/openaps/oref0/)”. You can look at that code (it’s written to be pretty straight forward - [see this example](https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js#L346), and the [glossary](http://openaps.readthedocs.io/en/latest/docs/Resources/glossary.html) may be helpful as well), but you can also read this plain language “[reference design](https://openaps.org/reference-design/)” that guides how OpenAPS was built. +* _Paying it forward_: OpenAPS is part of the #WeAreNotWaiting movement...built 100% by volunteers...and that also includes the documentation! If you spot something in the documentation that needs fixing or improving, please flag it and/or submit an edit yourself to fix the documentation then and there! + * This is called “making a pull request” or “making a PR”, which presents your edit for someone to review, approve, and update the overall documentation - which means everyone can use your fix moving forward! We all have a responsibility to keep adding to and improving the documentation. You can find [a guide to creating a pull request/submitting your edit here](http://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html), and if you ask, we’re happy to help answer questions as you do your first pull request. +* **You can do this**. + * One user estimates setting up OpenAPS takes only 20 mouse clicks; 29 copy and paste lines of code; 10 entries of passwords or logins; and probably about 15-20 random small entries at prompts (like your NS site address or your email address or wifi addresses). So if you can copy and paste, you’ll be able to do this! + +--- + +If you’re coming to try OpenAPS from a Loop system, there’s going to be some pretty obvious differences. And it starts with “building” the system. + +### Main Hardware Differences: + +
| + | Built using | +Brains sit | +Communications reside | +
|---|---|---|---|
| Loop | +xCode on an Apple computer | +on your iPhone | +on the Rileylink | +
| OpenAPS | +any computer | +on the “rig” (can be multiple kinds of rigs) | +on the rig (usually with a built-in radio stick) | +
+To start cron: `sudo service cron start` or reboot your rig. + +To prevent cron running on initial boot, either clear the `crontab -e` file or "comment out" (`#`) each line of the crontab file. If you've cleared the crontab file, but would like to enable cron'd tasks, rerun the initial setup script (step 2) and indicate you'd like to use cron. This will regenerate the configuration. + +## How do I know if it is working? + +Please be patient. We can not emphasize this enough. + +* Check your pump to see if it is setting temp basals. +* "Tail" the pump log to see what is is doing: `tail -F /var/log/openaps/pump-loop.log` +* Check Nightscout to see if it is updating with your information. Note: that if Nightscout is not showing your loop is running, it might be running but unable to communicate with Nightscout. In those cases check the pump-loop.log on your rig. + +## It's not working yet: + +Make sure to check through the following list before asking on Gitter if your setup is not working (yet). Remember if you just ran oref0-setup.sh, wait a good ~20 minutes as mentioned above before seeking help. Time, and the below list of steps, resolves 99% of problems. Also check out [this blog post for tips if asking for help online](https://diyps.org/2017/03/19/tips-for-troubleshooting-diy-diabetes-devices-openaps-or-otherwise/). + +* **Check to make sure that your pump is in absolute and not % mode for temp basals.** +* Did you put in the right SN for the pump? Should be numbers only... +* Check and make sure your pump is near your rig. Closer is better, e.g. check if it works when the pump and rig are at most 20 inches (50 cm) apart. +* Check that your pump battery is not empty. +* Check and make sure your pump is not suspended or stuck in rewind or prime screens. If it's a test pump, you don't even have to fill a reservoir, but put your pinky finger or eraser-end of a pencil in for slight pressure when priming so the pump will "sense" it and stop. Make sure to back out of the prime screen. +* If using a pump that has been without power for some time, it is a good practice to set a small temporary basal rate and bolus before trying to loop with that pump. Otherwise, you could see seemingly-unrelated errors in your log files as OpenAPS attempts to loop with missing information from the history. ([Best practice is to use the pump before you start looping with it](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/collect-data-and-prepare.html#use-your-gear), regardless, so this is likely to be an issue for a "test" pump setup rather than one you have been using.) +* Check to make sure you have a carb ratio set manually in your Medtronic insulin pump, if it is not done, the following display will appear in your pump.log: Could not parse input data: [SyntaxError: /root/myopenaps/monitor/iob.json: Unexpected end of input] +* Check to make sure your carelink and/or radio stick is plugged in. +* Check to make sure your receiver is plugged in, if you're plugging a receiver in. +* Don't have data in Nightscout? Make sure there is no trailing slash `/` on the URL that you are entering and that the API secret is correct. Check your Nightscout URL, too - it's one of the most common errors to mistype that. (And FWIW, you shouldn't be typing things like that in the first place: that's what copy and paste are for.) +* Check and make sure your receiver is >50% charged (if battery low, it may drain the rig battery and prevent it from operating). +* A reboot may be required after running oref0-setup if the Carelink is unable to communicate with the pump (e.g. you see "Attempting to use a port that is not open" errors in pump-loop.log). Additional Carelink troubleshooting steps can be found in [Dealing with the CareLink USB Stick](http://openaps.readthedocs.io/en/latest/docs/Resources/troubleshooting.html#dealing-with-the-carelink-usb-stick). +* If you see the error `failed to get string preference .pump_serial`, that usually means you copied your preferences over or ran runagain, instead of following the directions and using the full interactive setup script, when upgrading to a new version/installing a new version (such as going from 0.6.x to 0.7.0). To resolve, run `oref0-setup.sh` manually per the [directions](https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/update-your-rig.html#step-2-re-run-oref0-setup). (*This means you'll enter your responses into the interactive setup script again*.) + + +## Running commands manually to see what's not working from an oref0-setup.sh setup process + +You've probably run into an error in your setup where someone has recommended "running commands manually" to drill down on an error. What to do? Some of the following if you are running oref0 version prior to 0.7.0: + + * Start by killing anything that's currently running. ` killall-g oref0-pump-loop` + * Look and see what's running in your cron. `crontab -l` + * If you want to do more than one command of debugging, it's best to disable your cronjobs, use `/etc/init.d/cron stop`. Don't forget to start the cronjobs afterwards or reboot your rig to make sure the cronjobs will be running. + * Run whichever alias is failing to see what commands it is running. I.e. if the pump loop is failing, it's `openaps pump-loop`, which you can run to show what's inside it by `openaps alias show pump-loop`. + * Run each of those commands next individually, and that should give you a better idea of where it's failing or getting stuck. Do this, and share back (if needed) with your troubleshooter about where you think it's getting stuck. If that still doesn't give you or your troubleshooter enough info, keep drilling down further: + * **For example**, if your pump-loop.log always shows `Error, retrying` after `Old pumphistory:`, then you'd want to run `openaps refresh-old-pumphistory` manually to reproduce the problem and see if you can get more error details. + * If necessary, you can drill down further. So in this example, you might want to run `openaps alias show refresh-old-pumphistory` to see what *that* alias does, and then `openaps gather` to drill down further. + * Don't use `2>/dev/null` or `>/dev/null ` parts of commands, because they will hide output of commands + * If a command does not return output, check with `echo $?` if the exit code returns `0`. That means OK (no error). If it returns non-zero (e.g. `1`) then the command failed and you need to drill down further. + * You can keep drilling down until you get through all the aliases to the actual reports, which can be run manually using a command like `openaps report invoke monitor/status.json` to see the raw unfiltered output with full error details. + +If you are running oref0 version 0.7.0 or later, do the following: + + * Look and see what's running in your cron. Execute `crontab -l` and ensure it contains entries for `oref0-cron-every-minute`, `oref0-cron-post-reboot`, `oref0-cron-nightly`, and `oref0-cron-every-15min` + * Manually run oref0-pump-loop with debug enabled. `cd ~/myopenaps; killall-g oref0-pump-loop; OREF0_DEBUG=1 oref0-pump-loop` + diff --git a/docs/docs/Understanding OpenAPS-Overview/communication-support-channels.md b/docs/docs/Understanding OpenAPS-Overview/communication-support-channels.md new file mode 100644 index 000000000..a8b7d3397 --- /dev/null +++ b/docs/docs/Understanding OpenAPS-Overview/communication-support-channels.md @@ -0,0 +1,102 @@ +# Where to go for help + +There are several ways to communicate with other participants and contributors in the #OpenAPS project. See also the [Resources](../Resources/index.rst) section for additional assistance. + +**Note:** It's best practice not to share your pump's serial number, so make sure not to include it in pictures or pasted text output when seeking help on pump communication. Ditto for Nightscout URL and API secret and other private information that could enable someone to access your setup. + +**Related**: You may want to read [this blog post for tips on how to best seek help when troubleshooting online](https://diyps.org/2017/03/19/tips-for-troubleshooting-diy-diabetes-devices-openaps-or-otherwise/) - there is a lot of information you can provide proactively when seeking help that will aid in getting your issue resolved more quickly. + +### Read the documentation! + +One huge resource is this documentation. We recommend bookmarking the [link](http://openaps.readthedocs.org/en/latest/) to the docs, as they are frequently updated (sometimes daily!) as we add more information, troubleshooting tips, and more. Anytime we are asked a question on one of the below channels, we try to add it to the documentation. So chances are, your question may already be answered here! + +#### Tips for navigating the documentation + +You may notice that the left hand side of the documentation has navigation. It is organized in order of setting up OpenAPS, and has various sections on finding your gear; what you should do before you build a rig; how to setup up your rig; and additional features and tips and tricks for optimizing your looping setup. This navigation is long, you can mouse over the section and scroll down to see all the pages listed in the top-level navigation! + +
+
+
+You'll also notice that there is more content than just these high-level pages! If you click on a link in the left, many of them expand to show the sub-sections include, which make it easy to jump directly to the section you're looking for. If there is a `+`, that means there is more content you can expand.
+
+
+
+#### The docs also have their own search function!
+
+See the top left of the docs for the search box. It's helpful to search *inside* the documentation itself, rather than Google, because you'll stay inside the most up to date version of the documentation. You may want to try a different word or shorter phrase if you don't get any results for your search phrase, as we may have worded a section differently.
+
+
+
+### Slack
+There is a [Slack channel](https://omniapsslack.azurewebsites.net/) that you can add yourself to - then look for the `#OpenAPS` channel to post questions. That slack can also be used to stay up to date on other, broader DIY diabetes projects such as communication around other pumps that are being explored and worked on, but aren't yet DIY loopable.
+
+### Gitter
+[Gitter](https://gitter.im/) is a messaging/chat service similar to IRC. It provides integration with GitHub and several other services. It's the best place to get real-time support with anything related to OpenAPS. (Here's [why we often recommend asking questions on Gitter](https://diyps.org/2016/08/17/why-you-should-post-questions-in-gitter/).)
+
+* The [nightscout/intend-to-bolus]( https://gitter.im/nightscout/intend-to-bolus) channel is where you will find active #OpenAPS discussions ranging from technical issues with openaps tools to control theory to general information. It is a great place to introduce yourself and get some help from those who are a few steps further down the road.
+* For Autotune conversations, use the [openaps/autotune channel](https://gitter.im/openaps/autotune)
+
+Click here to expand some pictures that shows you the left hand navigation
+ + + + + + +
+
+ +**Search** +Gitter has a search function to find old information, but since it isn't threaded conversations, you may need to spend some time reading the posts after the search result to find the ultimate resolution to the question. So, if you find a particularly useful bit of information that you couldn't find in the docs...please make a [PR to the docs](http://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html) so that the information is permanently stored for others to find. + +**Tag/mention someone** +Tag someone! You can tag particular people if you are responding to them directly by using the `@` symbol and then typing their username. This will help notify the person that you are "speaking to them". If someone asks you for information that shouldn't be shared in the public channel, you can also private message people by hovering over their profile picture and choosing the "chat privately" button. Please do not abuse the tagging or PM features: most questions are best asked untagged in the appropriate channel, so that anyone can respond to them as soon as they read Gitter and see the question. There are people from all over the world online at all hours who can help with most kinds of questions, and the core developers usually read every message in Gitter a few times per day and try to answer any questions that got missed. + + + +**Posting photos or screenshots in Gitter** + +Gitter has a mobile app which works great for posting text, but does not allow for posting images directly. If you need to post a photo using the mobile app, you'll have to host your photo file somewhere like Dropbox and post the link to the file location. + +Using the desktop application, you can simply drag and drop the file into the Gitter chat window. The file will upload and then display in the chat thread after a short period of time to upload. + +**Posting logs** + +Posting copy-paste code from your rig is also another valuable activity for troubleshooting. To post a single line of information, you can use the single-backtick-quote that is found on the key to the left of the number 1 key on the keyboard. (hint: it is under the ~ on the same key). You can also long-press the single quote key on your iPhone keypad to bring up the single-backtick-quote that will work in Gitter. If you start and stop a portion of your text with those single quotes, it will `look like this`. + +Posting multiple lines of copy-paste from your rig will also sometimes be needed. You can do that by: + +* start a single line of 3 single quotes (the same one we used in the example above) +* press `control-enter` to get a new line started +* paste the lines of code that you want to post +* press `control-enter` again to get another new line +* enter 3 single quotes to end the section + +The copy-pasted lines should have 3 backticks on the line above and the line below. The example below shows, on the bottom, how the formatted text yielded the black box of text in Gitter. Using this format helps troubleshooters read your information easier than unformatted copy and paste. + + + +
+
+### Facebook
+
+There are multiple DIY closed loop groups on Facebook.
+
+* Everyone in the community is welcome to join the [Looped Group](https://www.facebook.com/groups/TheLoopedGroup/?fref=nf). All DIY closed loop users (OpenAPS, AndroidAPS, etc.) chat here. You will need to request membership for the group and respond to a message from the group administrators prior to joining.
+
+There are also numerous country-specific Facebook groups. You will still want to join the main Looped group, but country-specific groups may be helpful regarding local-specific details about access to hardware, supplies, etc. Similar to Looped, you will need to request membership for the group and respond to a message from the group administrators prior to joining any of these groups.
+
+* UK, join [Looped UK](https://www.facebook.com/groups/LoopedUK/).
+* Germany, join [Looped-DE](https://www.facebook.com/groups/loopedDE/).
+* Australia, join [Aussie, Aussie, Aussie, Loop, Loop, Loop](https://www.facebook.com/groups/1558147697576040/).
+* New Zealand, join [Aotearoa DIY Artificial Pancreas Society](https://www.facebook.com/groups/1405899059555406/).
+
+### Issues on GitHub
+One of the above channels is the best place for real-time or near-time troubleshooting. However, you may occasionally stumble across a new bug or edge case that we want to work on resolving. If you're asked to "create an issue", that usually means going to [the oref0 repository on Github and logging an issue there](https://github.com/openaps/oref0/issues). (You may also be asked to create issues for the openaps toolkit or decocare, etc. but usually it's oref0 related.)
+
+### Other online forums
+Those in the #OpenAPS community are frequently found in other forums, such as on Twitter (using [the #OpenAPS hashtag](https://twitter.com/search?f=tweets&vertical=default&q=%23OpenAPS&src=typd), as well as [#WeAreNotWaiting](https://twitter.com/search?f=tweets&vertical=default&q=%23WeAreNotWaiting&src=typd)) and on Facebook in the ["CGM In The Cloud"](https://www.facebook.com/groups/cgminthecloud/) and ["Looped"](https://www.facebook.com/groups/TheLoopedGroup/)group.
+
+### Google Group - everyone is welcome to join!
+A google group focused on #OpenAPS development work can be found [here](https://groups.google.com/d/forum/openaps-dev). You can add yourself directly to the group. It's worth setting your preferences to receive all email from the group; there's not a huge volume. However, please note that troubleshooting questions about rig setups are best posted to Slack or Gitter - email tends to be slower and you will likely be redirected to another channel if you're actively working to resolve a setup problem.
diff --git a/docs/docs/Understanding OpenAPS-Overview/how-openaps-works-overview.md b/docs/docs/Understanding OpenAPS-Overview/how-openaps-works-overview.md
new file mode 100644
index 000000000..8f0e54d0f
--- /dev/null
+++ b/docs/docs/Understanding OpenAPS-Overview/how-openaps-works-overview.md
@@ -0,0 +1,29 @@
+# How A DIY Open Source Closed Loop “Artificial Pancreas” Works
+
+How do you make decisions about your diabetes? You gather data, crunch the numbers, and take action.
+
+A DIY loop is no different. It gathers data from:
+* [your pump](https://openaps.readthedocs.io/en/latest/docs/Gear%20Up/pump.html)
+* [your CGM](https://openaps.readthedocs.io/en/latest/docs/Gear%20Up/CGM.html)
+* any other place you log information, like [Nightscout](https://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/nightscout-setup.html)
+
+It then uses this information to do the math and decide how your basal rates might need to be adjusted (above or below your underlying basal rate), to adjust and eventually keep or bring your BGs into your target range.
+
+## How does your closed loop gather data?
+
+With OpenAPS, there is a “rig” that is a physical piece of hardware. It has “brains” on the computer chip to do the math; plus a radio stick to communicate with your pump; plus it can talk to your phone and to the cloud via wifi to gather additional information, plus report to the world about what it’s doing.
+
+The rig needs to:
+* communicate with the pump and read history - what insulin has been delivered
+* communicate with the CGM (either directly, or via the cloud) - to see what BGs are/have been doing
+
+The rig runs a series of commands to collect this data, runs it through the algorithm and does the decision-making math based on the settings (ISF, carb ratio, DIA, target, etc.) in your pump.
+
+## But how does it do everything it needs to do to gather data and make decisions and tell the pump what to do?
+
+When you build an OpenAPS rig, you run through the setup described in this documentation, and:
+* physically put the pieces of your rig together
+* [load the open source software on it](https://openaps.readthedocs.io/en/latest/docs/Build%20Your%20Rig/OpenAPS-install.html)
+* configure it to talk to YOUR devices and have your information and safety settings on it (based on your preferences)
+
+The open source software is designed to make it easy for the computer to do the work you used to do to calculate what needs to be done. It runs a series of reports to collect data from all the devices and places. Then it prepares the data and runs the calculations. Then it attempts to communicate and send any necessary adjustments to your pump. Then it reads the data back, and does it over and over again. You can see what it's doing in the logs of the rig, or by viewing the information on your watch or on Nightscout.
diff --git a/docs/docs/Understanding OpenAPS-Overview/index.rst b/docs/docs/Understanding OpenAPS-Overview/index.rst
new file mode 100644
index 000000000..61fb3bf9e
--- /dev/null
+++ b/docs/docs/Understanding OpenAPS-Overview/index.rst
@@ -0,0 +1,10 @@
+Understanding OpenAPS/Overview
+----------------------
+
+.. toctree::
+ :maxdepth: 4
+
+
+ how-openaps-works-overview
+ overview-of-build-process
+ communication-support-channels
diff --git a/docs/docs/Understanding OpenAPS-Overview/overview-of-build-process.md b/docs/docs/Understanding OpenAPS-Overview/overview-of-build-process.md
new file mode 100644
index 000000000..7ee1e2bad
--- /dev/null
+++ b/docs/docs/Understanding OpenAPS-Overview/overview-of-build-process.md
@@ -0,0 +1,15 @@
+# How you will build your rig
+
+The OpenAPS setup process can be broken up into several parts:
+
+
+
+As with all things new, there is a little bit of a learning curve to building your first OpenAPS rig. Read slowly, double-check your spelling and make sure you don't skip steps. If you get stuck or are unsure, you can use the screenshots to compare how the resulting screens should look. You can also post to Gitter or Facebook to ask for specific help if you find yourself stuck.
+
+Over time, you may also choose to enable advanced features or update your rig, as more features and algorithm improvements become available. You should make sure to stay plugged in to key channels (like openaps-dev google group; Looped on Facebook; and on Twitter by following @OpenAPS) so you can be aware when updates become available. You should also make sure to tell us when you’ve closed your loop, which includes notes on how to join the safety-critical announcement list in case we need to alert you to any safety-related changes or updates.
+
+## What you’ll see in this guide
+
+* Wherever you see text that is formatted `like this`, it is usually a code snippet. You should copy and paste instead of attempting to type this out; this will save you debugging time for finding your typos.
+
+* Wherever there are `Click here to expand a list of tips for using Gitter, from using the search function to tagging someone to posting screenshots or posting logs
++ +**Search** +Gitter has a search function to find old information, but since it isn't threaded conversations, you may need to spend some time reading the posts after the search result to find the ultimate resolution to the question. So, if you find a particularly useful bit of information that you couldn't find in the docs...please make a [PR to the docs](http://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html) so that the information is permanently stored for others to find. + +**Tag/mention someone** +Tag someone! You can tag particular people if you are responding to them directly by using the `@` symbol and then typing their username. This will help notify the person that you are "speaking to them". If someone asks you for information that shouldn't be shared in the public channel, you can also private message people by hovering over their profile picture and choosing the "chat privately" button. Please do not abuse the tagging or PM features: most questions are best asked untagged in the appropriate channel, so that anyone can respond to them as soon as they read Gitter and see the question. There are people from all over the world online at all hours who can help with most kinds of questions, and the core developers usually read every message in Gitter a few times per day and try to answer any questions that got missed. + + + +**Posting photos or screenshots in Gitter** + +Gitter has a mobile app which works great for posting text, but does not allow for posting images directly. If you need to post a photo using the mobile app, you'll have to host your photo file somewhere like Dropbox and post the link to the file location. + +Using the desktop application, you can simply drag and drop the file into the Gitter chat window. The file will upload and then display in the chat thread after a short period of time to upload. + +**Posting logs** + +Posting copy-paste code from your rig is also another valuable activity for troubleshooting. To post a single line of information, you can use the single-backtick-quote that is found on the key to the left of the number 1 key on the keyboard. (hint: it is under the ~ on the same key). You can also long-press the single quote key on your iPhone keypad to bring up the single-backtick-quote that will work in Gitter. If you start and stop a portion of your text with those single quotes, it will `look like this`. + +Posting multiple lines of copy-paste from your rig will also sometimes be needed. You can do that by: + +* start a single line of 3 single quotes (the same one we used in the example above) +* press `control-enter` to get a new line started +* paste the lines of code that you want to post +* press `control-enter` again to get another new line +* enter 3 single quotes to end the section + +The copy-pasted lines should have 3 backticks on the line above and the line below. The example below shows, on the bottom, how the formatted text yielded the black box of text in Gitter. Using this format helps troubleshooters read your information easier than unformatted copy and paste. + + + +
+
+
+#### IOBpredBGs
+
+Click here to expand the eventualBG description
+The simplest and oldest prediction, called eventualBG, uses traditional bolus calculator math. + +Specifically, the naive_eventualBG is set to current BG - IOB*ISF. + +It also calculates a “deviation” term, which represents how much BG is currently rising or falling relative to what it should be doing based solely on insulin activity. These deviations are projected to continue for the next 30 minutes (or, equivalently, to linearly decrease from the current value to zero over the next 60 minutes). + +Then, eventualBG = naive_eventualBG + deviation +
+
+
+#### ZTpredBGs
+
+Click here to expand the IOBpredBGs description
+The eventualBG, by its nature, predicts only an eventual BG value, once all insulin activity takes effect. + +In order to make predictions about what BGs will do between now and then, oref0 performs a calculation similar to the eventualBG calculation, but every 5 minutes (for 4 hours). In that calculation, the predicted blood glucose impact of insulin (predBGI) and predicted deviation (predDev) are calculated for every 5-minute interval, allowing us to predict a BG value for each interval, which are stored in the IOBpredBGs array. As with the eventualBG calculation, deviations are projected to linearly decrease from the current value to zero over the next 60 minutes, thereby predicting an element of “momentum”. +
+
+
+#### COBpredBGs
+
+Click here to expand the ZTpredBGs description
+ Another fairly simple prediction is for what will happen in the “worst likely case,” if observed carb absorption suddenly ceases, and a zero-temp is applied until BG begins rising at/above target. + +To do so, oref0 simply calculates what BGI will be every 5 minutes if it sets a long zero-temp immediately, and use those BGIs (without any deviations) to predict a BG value for each interval, which are stored in the ZTpredBGs array. +
+
+
+#### UAMpredBGs
+
+Click here to expand the COBpredBGs description
+The calculation of predicted BG in the COB-based scenario depends on a calculation of COB. In oref0, the COB is calculated based on observed deviations since carb entry, based on the assumptions that positive deviations were caused by carb absorption, and any low or negative deviations were caused by something else (like physical activity), but that carbs would continue to be digested/absorbed over that time at a configurable minimum rate. + +If a user chooses to bolus for their meal, then oref0 can simply wait to observe positive deviations indicating carb absorption and can assume that those deviations will gradually decrease to zero over a timeframe long enough to “use up” all remaining COB. In this scenario, oref0 can simply perform the same calculation as for IOBpredBGs, but use the gradually decreasing predicted carb impact (predCI) value instead of the predDev. + +Before such carb absorption is observed, oref0 must make a prediction about how quickly carbs are likely to begin absorbing, so that it can make sure at least some of the insulin needed for the meal is delivered via SMB if the user didn’t already bolus (sufficiently). One of the design goals of oref0 was that users should *not* have to enter a guess as to the absorption speed of their meal. Instead, oref0 makes a conservative estimate of likely carb absorption, based on the size of the meal, how long ago it was entered, the current sensitivityRatio (from autosens or temp target overrides). For meals <= 60g, the initial absorption time estimate starts at 3 hours, and for >= 90g, the first 90g is assumed to absorb in 4.5 hours. Anything > 90g is ignored until actual carb absorption is observed by capping COB at 90g. + +If carb absorption remains low or drops low at some later time, oref0 predicts that remaining COB will be absorbed more slowly than when carbs were just entered. This is calculated as 1.5x the lastCarbAge, so any carbs not observed to be absorbing after 1 hour are assumed to take 1.5 additional hours to absorb, which means 4.5h for <=60g COB, and 6h for >= 90g. + +Once the absorption time is calculated for carbs not yet being absorbed, that is translated into a /\ shaped carb absorption curve that increases from the current level of absorption up to a peak value halfway to the assumed absorption time, and then decreases linearly to zero at the assumed absorption time (remainingCATime). The rate of carb absorption predicted at the remainingCIpeak is calculated to ensure that all COB (up to the 90g cap) is absorbed over the remainingCATime. + +  +
+
+
+### Blending relevant predictions
+
+After oref0 generates all relevant predictions (the different predBG arrays, depending on the presence or absence of COB and positive deviations), it:
+* blends and combines them to produce estimates of the lowest predicted BGs likely to be observed over the timeframe relevant for dosing,
+* calculates how much insulin is required (insulinReq) to bring the minimum predicted BG down toward the target,
+* and then uses the insulinReq to calculate an appropriate microbolus or temp basal.
+
+ **If no carb announcement is present**, minPredBG is generally set to the higher of minIOBPredBG, the lowest IOBpredBG (starting 90m in the future), and minZTUAMPredBG, which is the average of the lowest UAMpredBG (starting ~60m in the future, minUAMPredBG) and the lowest ZTpredBG (starting immediately, minZTGuardBG).
+
+ **When COB from a meal announcement is present**, oref0 sets minPredBG by blending the UAM-and-ZT-based minPredBG described above (minZTUAMPredBG) with the lowest COBpredBG (starting ~90m in the future, minCOBPredBG), according to the fraction of carbs remaining as COB (fractionCarbsLeft).
+
+insulinReq is then set to the difference between the minPredBG and target BG, divided by ISF. Each loop, half of the insulinReq is delivered as a microbolus, and on each subsequent loop the minPredBG is recalculated to calculate a new insulinReq and microbolus.
+
+## OpenAPS algorithm examples
+
+### Scenario 1 - Zero Temp for safety
+
+In this example, BG is rising in the near-term time frame; however, it is predicted to be low over a longer time frame. In fact, it is predicted to go below target *and* the safety threshold. For safety to prevent the low, OpenAPS will issue a zero temp, until the minimum predicted BG is above threshold.
+
+
+
+### Scenario 2 - Zero temp for safety
+
+In this example, BG is predicted to go low in the near-term, although you are predicted to eventually be above target. However, because the near-term low is actually below the safety threshold, OpenAPS will issue a zero temp, until there is no longer any point of the prediction line that is below threshold.
+
+
+
+### Scenario 3 - More insulin needed
+
+In this example, a near-term prediction shows a dip below target. However, it is not predicted to be below the safety threshold. The eventual BG is above target. Therefore, OpenAPS will restrain from adding any insulin that would contribute to a near-term low (by adding insulin that would make the prediction go below threshold). It will then assess adding insulin to bring the lowest level of the eventual predicted BG down to target, once it is safe to do so. *(Depending on your settings and the amount and timing of insulin required, this insulin may be delivered via temp basals or SMB's).*
+
+
+
+### Scenario 4 - Low temping for safety
+
+In this example, OpenAPS sees that you are spiking well above your target. However, due to the timing of insulin, you already have enough in your body to bring you into range eventually. In fact, you are predicted to eventually be below target. Therefore, OpenAPS will not provide extra insulin so it will not contribute to a longer-timeframe low. Although you are high/rising, a low temporary basal rate is likely here.
+
+
+
+## Exploring further
+
+For each different situation, the determine-basal output will be slightly different, but it should always provide a reasonable recommendation and list any temp basal that would be needed to start bringing BG back to target. If you are unclear on why it is making a particular recommendation, you can explore further by searching lib/determine-basal/determine-basal.js (the library with the core decision tree logic) for the keywords in the reason field (for example, "setting" in this case would find a line (`rT.reason += ", setting " + rate + "U/hr";`) matching the output above, and from there you could read up and see what `if` clauses resulted in making that decision. In this case, it was because (working backwards) `if (snoozeBG > profile.min_bg)` was false (so we took the `else`), but `if (eventualBG < profile.min_bg)` was true (with the explanatory comment to tell you that means "if eventual BG is below target").
+
+If after reading through the code you are still unclear as to why determine-basal made a given decision (or think it may be the wrong decision for the situation), please join the [#intend-to-bolus channel on Gitter](https://gitter.im/nightscout/intend-to-bolus) or another support channel, paste your output and any other context, and we'll be happy to discuss with you what it was doing and why, and whether that's the best thing to do in that and similar situations.
diff --git a/docs/docs/While You Wait For Gear/collect-data-and-prepare.md b/docs/docs/While You Wait For Gear/collect-data-and-prepare.md
new file mode 100644
index 000000000..3f549c185
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/collect-data-and-prepare.md
@@ -0,0 +1,75 @@
+# Collect your data and get prepared
+
+Before getting started, we suggest that you store at least 30 days of CGM data. People often like to compare their before and after looping data. Nightscout is an excellent tool to capture your CGM history, as well as log your carbs and boluses. For instructions on setting up your own Nightscout site (or updating your existing one for OpenAPS use), see [here](https://openaps.readthedocs.org/en/latest/docs/While%20You%20Wait%20For%20Gear/nightscout-setup.html). By logging and collecting a recent history of your insulin+BG patterns, you can also take advantage of the Autotune feature which uses Nightscout databases, as well as use Nightscout reports, which are often helpful for showing your data to your healthcare provider.
+
+Later in these docs is a link to donate your data to a project called [OpenHumans](https://openaps.readthedocs.org/en/latest/docs/Give%20Back-Pay%20It%20Forward/data-commons-data-donation.html). There is no requirement to share your data or participate in OpenHumans. If you choose to, you can donate your data whether you are looping or not. Individuals within the project who share their data do so willingly and you should do the same only if you feel comfortable. That being said, it is always a good idea to record your data before embarking on a new set of experiments. This will be helpful to understand the effects of the system as well as gain a better understanding of your response to different control strategies.
+
+## Practice good CGM habits
+
+A good quality CGM session is a critical part of successful looping. If you're used to stretching your sensor sessions out until failure, you may want to reconsider this approach as you will have failed looping times, too. One technique that has helped eliminate early sensor jumpiness in a session is to "presoak" a new sensor before the old one dies when you notice the old sensor is getting jumpy or loses calibration. To read more about this presoak technique, check out this [blog post](https://diyps.org/2016/06/27/how-to-soak-a-new-cgm-sensor-for-better-first-day-bgs/). In addition, be diligent about your sensor calibration habits. Only calibrate on flat arrows and when BGs are steady. Many loopers calibrate once or twice a day only; at bedtime (after dinner has finished digesting) and/or just before getting out of bed. A good guide to sensor calibration - which generally applies regardless of which sensor you have - can be found [here](https://forum.fudiabetes.org/t/how-to-calibrate-a-dexcom-g4-g5-cgm/2049/).
+
+## Use your gear
+
+Starting a DIY loop system like OpenAPS means you are probably switching pumps, and quite possibly using Nightscout for the first time. You may find, like many new users, that settings you thought you had dialed in before will need to be adjusted. Good news, there are several tools and techiques to get you off to the right start. They include:
+
+* Use your pump **BEFORE** you begin looping
+* Practice good CGM habits
+* Collect your carb, bolus, and BG history using Nightscout
+* Use Autotune to analyze and fine-tune your pump settings
+
+### Start Medtronic pump
+
+Many loopers have come from Animas, OmniPods, Roche, or t:slim pumps in order to pump using old Medtronic pumps. The menus will be different and you need to get proficient with the pump's normal use before complicating things with looping. Become familiar with the reservoir changes and teach your T1D kid, if that's the person who will be using the pump. Train caregivers on the new pump, as well. Assuming that you're already familiar with insulin pumping (and you should be before trying to loop) but new to these old Medtronic pumps, these "quick menu" guides will help:
+
+* [x12](https://www.medtronicdiabetes.com/sites/default/files/library/download-library/user-guides/x12_user_guide.pdf)
+* [x15](https://www.medtronicdiabetes.com/sites/default/files/library/download-library/user-guides/x15_user_guide.pdf)
+* [x22](https://www.medtronicdiabetes.com/sites/default/files/library/download-library/workbooks/x22_menu_map.pdf) (aka "REAL-TIME")
+* [x23](https://www.medtronicdiabetes.com/sites/default/files/library/download-library/workbooks/x23_menu_map.pdf) (aka "REAL-TIME REVEL™")
+* [x54](https://www.medtronic-diabetes.co.uk/sites/uk/medtronic-diabetes.co.uk/files/veo-x54_ifu_updated_26.04.2013.pdf) (aka "Veo™")
+
+**You should definitely test your basals, ISFs, carb ratios, and DIA all over again now that you've switched pumps and infusion sets. Expect for your settings to change when switching pumps and when beginning to close the loop.**
+
+#### Pump settings
+
+There are a couple areas in the pump that will need to be set specifically in order to allow OpenAPS to loop. Since you are going to be looping soon, you might as well set them correctly in your pump now:
+
+* Set the Temp Basal type to `units per hour` not `%` type.
+
+* Set the carb ratios to grams, not exchange units.
+
+* Set the max basal rate to a reasonable value (typically no more than 3-4 times your regular basal).
+
+* Set basal profile, carb ratios, and ISF values.
+
+ * **Safety note**: your carb ratio is unlikely to vary significantly throughout the course of day. If you have carb ratios that vary significantly (such as more than 2x) between different times of day, you may get unexpected results in looping, such as COB reappearing when the CR schedule changes. For safety, we recommend checking your settings against Autotune, which currently uses a single CR for the entire day. If you are using a schedule with widely varying carb ratios or ISFs, that may be compensating for something other than an actual diurnal variation in carb ratio: perhaps different absorption speeds of different foods, or perhaps related to different macronutrient composition (instead of entering carb equivalents for fat/protein), differing basal insulin needs around mealtime, or something else.
+
+* Set your DIA. **Note**: Most people have their DIA for traditional pumping to be too short (e.g. 2 or 3). For looping, OpenAPS will default to using 5. Many people find they actually need it to be 6 or 7 with properly adjusted other settings.
+
+* If you have periods in the day where your pump normally has basal settings of zero - your loop will not work! You can resolve this by setting the lowest possible basal setting your pump will permit. OpenAPS will then issue temp basals of zero, as needed.
+
+#### Easy Bolus Button
+
+Setting up the Easy Bolus feature for your pump now (and practicing it) may help you avoid a small, annoying pump error later. If you are going to use the (super advanced, not for beginners) SMB (super microbolus) feature, then you need to be aware of the potential for pump error due to remote bolus commands. When the pump is engaged to bolus with a remote bolus command from the rig and another bolus is initiated from the pump manually, the pump will error out with an A52 error. The pump will not deliver the bolus, the reservoir will rewind and the pump time needs to be reset. Put simply, two bolus commands coming in at once cause the pump to error and rewind.
+
+One way to minimize this error is by checking the pump before giving a bolus. Check to see if the rig is giving a SMB by using the OpenAPS pill in Nightscout, checking the pump-loop log in Papertrail, or logging into the rig and looking at the pump loop. If the rig is actively giving a SMB, then try to time your bolus wizard use to be in the 5 minutes between SMBs (SMBs are only enacted every 5 minutes at most). These steps might be a little too complex for young kids or school nurses, depending on the situation. If this error happens frequently, you may need to consider turning off SMBs or try using the Easy Bolus button.
+
+The Easy Bolus button allows you to quickly use the arrow buttons on your pump to give a set increment of insulin. For example, if you setup your Easy Bolus button to have 0.5 unit increments, every click of the `up arrow` on the pump will increment a bolus of 0.5 units. Push the button 4 times and you are setting up a 2.0 unit bolus. You still have to click the `ACT` button twice to confirm and start the delivery of the bolus. Since the button presses are usually pretty quick, there's less likelihood of radio communication interference with a rig's SMB command. You can use IFTTT buttons to enter the carbs in your Nightscout site (or use Care Portal in Nightscout directly). For example, having IFTTT buttons for 5, 10, and 20g carb entries (or whatever your common meal amounts are) can make entering in food pretty easy. The Easy Bolus method requires the ability to roughly estimate your meal bolus (e.g., total carbs divided by carb ratio). As long as you are close, the loop should be able to make up any amount of bolus that was slightly over/under done by using the Easy Bolus button.
+
+#### Extended and Dual Wave substitute
+
+Due to the way Medtronic pumps operate, temp basals can only be set when there is no bolus running, including extended (square) and dual wave boluses. If you're used to extended or dual wave boluses for carb heavy meals (e.g., pizza), which may still be the optimal approach for you, OpenAPS will not be able to provide temp basals during the extended bolus. You won't be looping during those types of boluses.
+
+But, you don't need the square/dual wave boluses anymore, as OpenAPS will help simulate the longer tail insulin needed if you've entered carbs into the system. Also, many loopers have found they can convert to a split bolus strategy to effectively deal with the same meals. There is a carb+insulin+BG simulator called [Glucodyn](http://perceptus.org) that can be used to model a split bolus strategy for those meals. By setting different bolus times and bolus amounts, the model allows the user to slide adjustments to minimize early-meal lows as well as late meal rises. For example, you may find that a 20 minute pre-bolus of 50% of the carbs and a later bolus for the remaining 50% will work well, with looping helping to make up the difference that an extended bolus used to provide. You can practice the transition to split bolusing even before you get your loop running.
+
+Some of the super advanced features you'll learn about later - Unannounced Meals and Supermicrobolus (UAM/SMBs) - also help smooth the transition from extended bolusing. Some users have found that entering in carbs alone can be effective, especially in helping later BG rises from slow-absorping carbs. Once you get your loop running, and are ready for the advanced features, you may be interested in playing with the various techniques available for heavy, slow carb meals.
+
+### Autotune
+
+You've been logging and recording your carbs and boluses in Nightscout, right? You have your CGM data flowing into Nightscout too? Great...now autotune can give you a headstart to fine-tuning your basals and ISF. There are some restrictions on autotune still (only a single daily carb ratio and single daily ISF), but there are tips on the [autotune page](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/autotune.html) for how to deal with multiple values. You can run autotune before you get your loop setup...it doesn't have to run on a rig.
+
+How important are good basals and ISFs? You mean you weren't convinced already by the amount of work put into autotune itself? Well, autotune is a required step in order to enable the most advanced features (SMB and UAM). The new version will check to see if you have an autotune directory in your rig before the loop will be allowed to actually enact any SMBs (no matter what your preferences say). To fulfill this requirement you can do one of the following which will create an autotune directory where it needs to be:
+
+* enable autotune during your OpenAPS setup script and autotune will run automatically as part of your loop.
+* run autotune as a one-off (single run) on your rig using the directions given in the link above
+
+Regardless of if you want to use advanced features later, we highly recommend running autotune as part of the rig nightly, or as a one-off and periodically checking the output to see if the settings on the pump that you are using reflect what the data says your body really needs.
diff --git a/docs/docs/While You Wait For Gear/entering-carbs-bolus.md b/docs/docs/While You Wait For Gear/entering-carbs-bolus.md
new file mode 100644
index 000000000..b087b45dd
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/entering-carbs-bolus.md
@@ -0,0 +1,38 @@
+# Entering carbs & doing boluses
+
+How do you enter carbs & do boluses with OpenAPS? You have a variety of ways to do things.
+
+## Doing boluses
+
+* **Easy bolus button**: Previously before OpenAPS, you probably used the [easy bolus button](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/collect-data-and-prepare.html#easy-bolus-button) to add up a bolus in increments. (E.g. if your pump had increments of 0.5u, you could quickly dial up to a bolus by pressing the up button as many times as needed; hitting enter to confirm it; hitting enter again to deliver the bolus.)
+
+* **Bolus wizard**: Or, you may have used the bolus wizard, sometimes with BG or carb entry, or just as a bolus.
+
+**In OpenAPS, you can still use those same methods for delivering manual doses of insulin (boluses).**
+
+## Entering carbs into OpenAPS
+
+Before OpenAPS, you may or may not have entered carbs into your pump. With OpenAPS, most people *do* want the rig to know about carbs. You have a variety of ways to enter them, depending on whether your rig is **online** or **offline**.
+
+Look at this image for the big picture:
+
+
+
+### Offline carb entry
+
+* You can still use the bolus wizard to enter carbs, although a non-zero amount of bolus must be delivered in order for OpenAPS to record the carbs. If you adjust the bolus recommended by the bolus wizard down to zero and deliver the zero units (as you might ordinarily do if you ate carbs in order to treat a low), the pump may (depending on your pump version) fail to record a bolus wizard record in pumphistory, causing OpenAPS to ignore the carbs as if you hadn't entered them. In that situation, consider delivering the smallest unit of bolus possible (like 0.05u or 0.1u) so that OpenAPS will record the carbs entered into the bolus wizard.
+* Some pumps can use the ['meal marker' feature](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/offline-looping-and-monitoring.html#entering-carbs-while-offline).
+* See section on [extended and dual wave substitutes](https://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/collect-data-and-prepare.html#extended-and-dual-wave-substitute) for information on how extended boluses are handled in OpenAPS.
+
+### Online carb entry
+
+If your rig is online, you have a variety of ways to enter carbs online.
+
+* Nightscout care portal
+* AndroidAPS NS Client ([Download the app-nsclient-release APK from here](https://github.com/MilosKozak/AndroidAPS/releases).)
+* Many options for using IFTTT to get carbs into Nightscout Care portal. ([See the IFTTT page here for instructions](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/ifttt-integration.html).)
+ * Pebble or Apple watch
+ * Google Calendar
+ * Siri, Alexa, Google, etc.
+* Android users: you can use the Care portal option in [NSClient app found here](https://github.com/nightscout/NSClient-Android/releases).
+
diff --git a/docs/docs/While You Wait For Gear/example-max-safety-chart.md b/docs/docs/While You Wait For Gear/example-max-safety-chart.md
new file mode 100644
index 000000000..3e6e92150
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/example-max-safety-chart.md
@@ -0,0 +1,12 @@
+(This chart is what the image in the preferences page is. This renders in MarkDown but not ReadTheDocs, so leaving a copy here in case we want to modify in future. )
+
+
+>| | Example 1 | Example 2 | Example 3 | Example 4 |
+>|------------------------------------------------------------|---------------|--------------|--------------|--------------|
+>| user's max basal safety setting (in pump) | 2 .0 | 2.0 | 3.0 | 2.5 |
+>|`max_daily_safety_multiplier` | 3 | 3 | 3 | 3 |
+>|`current_basal_safety_multiplier` | 4 | 4 | 4 | 4 |
+>| user's current basal rate | 1.0 | 0.4 | 1.2 | 0.7 |
+>|user's highest programmed basal rate | 1.5 | 1.0 | 1.2 | 0.8 |
+>|OpenAPS recommended temp basal rate | 3.0 | 1.8 | 2.4 | 2.6 |
+>|Actual temp basal rate allowed | 2.0 | 1.6 | 2.4 | 2.4 |
diff --git a/docs/docs/While You Wait For Gear/examples_safety_caps_in_play.png b/docs/docs/While You Wait For Gear/examples_safety_caps_in_play.png
new file mode 100644
index 000000000..2d9f5902c
Binary files /dev/null and b/docs/docs/While You Wait For Gear/examples_safety_caps_in_play.png differ
diff --git a/docs/docs/While You Wait For Gear/index.rst b/docs/docs/While You Wait For Gear/index.rst
new file mode 100644
index 000000000..4b5ed2571
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/index.rst
@@ -0,0 +1,16 @@
+While You Wait For Gear
+----------------------
+
+.. toctree::
+ :maxdepth: 4
+
+
+ collect-data-and-prepare
+ loops-in-progress
+ nightscout-setup
+ understanding-your-Explorer-Board-rig
+ Understand-determine-basal
+ understanding-insulin-on-board-calculations
+ monitoring-OpenAPS
+ preferences-and-safety-settings
+ understanding-wifi-options
diff --git a/docs/docs/While You Wait For Gear/loops-in-progress.md b/docs/docs/While You Wait For Gear/loops-in-progress.md
new file mode 100644
index 000000000..fbc35bdf9
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/loops-in-progress.md
@@ -0,0 +1,326 @@
+# Loops In Progress
+
+To get you comfortable with submitting a "PR" (stands for pull request), test it out by submitting a PR to this page, adding your name to the list of people who have loops in progress.
+
+New to Github, and PRs? [Check out how to submit your first PR](http://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html).
+
+List of people who are working on closed loops:
+
+- Dana Lewis
+- Ben West
+- Chris Hannemann
+- Sarah Howard
+- Mike Stebbins
+- Scott Hanselman
+- Greg Scull
+- Aaron Michelson
+- Jayson EWER --Intel Edison w/ TI--cc1111
+- Frank Best
+- Brooke Armstrong & Matt Pazoles
+- David Young
+- Paul Martin
+- Jarred Yaw
+- Shane Mitchell
+- Boris and Kayley Raskin
+- Andy Pabari
+- Rob Kresha - (Papillion, NE, USA)
+- Christian Robinson (London, UK)
+- Gary Kidd (Wilton, CT)
+- Nathan Morse
+- Paul Davis (Brighton, UK)
+- Marion Barker (Sunnyvale, CA, USA)
+- Frank Jungman (San Diego, CA)
+- Sophie Thacher
+- Luis Betancourt (Veracruz, Mexico)
+- Tom Boudreau (Washington DC, USA)
+- Ryan Chen
+- Katherine Mason
+- Garrett Webb (Dallas, TX)
+- Brandon Faloona (Seattle, WA / Burbank, CA)
+- Keith Burns - for Heather (Richmond, VA)
+- Kim St. Dennis (Los Angeles, CA)
+- Gabriel and Gideon Arom (Chicago, IL / Los Angeles, CA)
+- Arlene Samowich (Nashville, TN)
+- Andy Probolus & Marianne Smith (Lancaster, PA)
+- Gregg Haroldson (Huntington Beach, CA)
+- Gera Yeremin (Santa Rosa , CA)
+- Ed Nykaza
+- Jeff Waters (Madison, WI)
+- Greg Hull (Wheaton, IL)
+- Sara and David Goya (Anaheim, CA)
+- Rafael Matuk (Chicago, IL)
+- Luuc Verburgh (Eindhoven, The Netherlands)
+- Iain Cartwright (Adelaide, Australia)
+- Julie Raines (Poughkeepsie, NY)
+- Brandon Parrish (Augusta, GA)
+- Katie Ellison (Bellevue, WA)
+- Sarah Easter (Georgetown, TX)
+- Terri Lyman (Prescott Valley, AZ)
+- Gina Lyon (Laurel, MS) Edison-Explorer Bd, DexG5
+- Eric Jensen (Swarthmore, PA)
+- John Dodds (Glasgow, UK)
+- Lindsey Maguire (Silicon Valley)
+- Dan Robinson (Chicago, IL)
+- Mitch Phillips - (Pennington, NJ)
+- Colin Barlow & Cassie Knox - (San Diego, CA)
+- Andrew H (Sydney, Australia)
+- Hichame Yessou (Milano, Italy)
+- Tim Street (London, UK)
+- Neal Harvey (Grants Pass, OR)
+- Patrick Metcalfe
+- Ken Webster (Hobart, Tas, Australia)
+- David Eddy (Madbury, NH)
+- Tirzah Heide for Nathanael (St. Louis, MO)
+- Tracy Osheroff (Seattle, WA)
+- Mike & Jennifer Crawford (Calgary, AB, Canada)
+- Matthew Byatt (Cambridge, UK)
+- Anna Hassan (New Orleans, LA)
+- Tony Zarro (Atlanta, GA)
+- Mike Wright (San Jose, CA)
+- Derek Rodeback (Loma Linda, CA)
+- Joanne Spotten (SLC, UT)
+- Sandra Keßler (Kassel, Germany)
+- Lukas Ondriga (Svaty Jur, Slovakia)
+- Dominic Herrington (Bishops Stortford, UK)
+- Taylor Fowler (Brooklyn, NY)
+- Mikel Curry
+- Aditya Dasnurkar
+- Jason Wittmer for Andrew (Clive, IA)
+- Kevin Ruess Marshall (Indianapolis, USA)
+- Keith Kubischta (Poway, CA)
+- Emily Kranz (Greensboro, NC)
+- Orla Wilson (Baltimore)
+- Jason Pell for Heidi and Mallory (New York, NY)
+- Patrick van Gestel (Hilvarenbeek, Netherlands)
+- Joe Moran (Los Altos, CA)
+- John & Gregory Kelleher (Sligo, Ireland)
+- Carine Bruyndoncx (Arendonk, Belgium)
+- Jordan Berger (SLC, UT)
+- James Henley (Friendswood, TX)
+- Amy Andrews (Boston, MA)
+- Ann Delano (Seattle, WA)
+- Marcus Whitley (Greenbrier, AR)
+- Trevor Wood (Santaquin, UT)
+- Anne Svejda (Virginia Beach, VA)
+- Melody Andrews-Caron (Ontario, Canada)
+- Andy Sharrow (Saginaw, MI)
+- John Benjamin (Clawson, MI)
+- Vince P. for Tristan (Ravenna, OH)
+- Anthony Cerrone (Danville, CA)
+- Rachel Aumaugher (Davison, MI)
+- Joe Greene (Jacksonville, NC)
+- Sebastien Lussier (Montreal, Canada)
+- Chris Harris (Sydney, Australia)
+- Lee Skelton (London, UK)
+- Jacqueline Burke (Troy, MI / Baltimore, MD)
+- Kate Hainsworth (Austin, TX)
+- Brian Rabinovitz (Chapel Hill, NC)
+- Stephen G. (Seattle, WA)
+- Emily Stunek (Lake Shore, MN)
+- Lorenzo Conte (Chicago, IL)
+- Alasdair McLay (Derby, UK)
+- Ahanu Banerjee (Pittsburgh, PA)
+- Ken Huat CHONG (Kuala Lumpur, Malaysia)
+- Daniel Bjørnbakk (Norway)
+- Katie DiSimone (Paso Robles, CA)
+- Rebecca Jervey (Philadelphia, PA)
+- Ivica Suran (Pazin, Croatia)
+- David Rimmer (Melbourne, Australia)
+- Kyle King (Opelika, AL)
+- Sonya Neufer
+- Sacha M (New Zealand)
+- Joe Dunn for Lizzie
+- Michele Lawford (Canada)
+- parenthetic (diabetic)
+- Lorenzo Sandini (Finland)
+- Deidra Little (Seattle, WA)
+- Tim Mathis (Fort Walton Beach, FL)
+- Greg Uhlenkott (Grangeville, ID, USA)
+- Song Ming Jie (China)
+- Chuck Vanderwist (Western Colorado, USA)
+- James Corbett (Greenbrier, TN USA)
+- Meghan Rutledge (Dallas, TX)
+- Rick Warren (Vancouver, BC, Canada)
+- Carl-Johan Wehtje (London, UK)
+- Cameron Renwick (Muskoka, Ontario, Canada)
+- Cameron Chunn (Huntsville, AL)
+- Patrick & Lesly Kelly for Addy (Tempe, AZ)
+- Melanie Mason for Toby (Leicester, UK)
+- Mohamed Ali Bedair (Cairo, Egypt)
+- Hilary Koch (Waterville, ME)
+- Eric Feibelman (Alachua, FL)
+- Winfried Kuiper (Langballig, Germany)
+- Selin Aygün (Ankara,Türkiye)
+- Ken Kotch (Boulder, CO, USA)
+- Brian Densmore (Clovis, CA, USA)
+- Jesse Szypulski (Louisville, KY, USA) Edison / Explorer Board
+- Robert Silvers (Norwell, MA)
+- Eric Metzler (St. Paul, MN)
+- Helene Brashear (Austin, TX)
+- Jeremy B. for CM (New York, NY)
+- Molly Duerr (Minneapolis, MN)
+- Amber K (Ithaca, NY)
+- Melanie Shapiro (Gainesville, FL)
+- Brandon (Philly)
+- Justin W (Charlottesville, VA)
+- Chris Creek (Martinsburg, PA)
+- Tom Petrillo (San Diego, CA)
+- Christian Driver for Lucy (Wilmslow, UK)
+- Katie Aldridge
+- Darlene Morissette (Winnipeg, MB, Canada)
+- Jake Punshon (Saskatoon, SK, Canada)
+- Elisa Kelley (Austin, TX)
+- Stuart Raphael (Sydney, Australia)
+- Dan Durham (Edmonton, AB, Canada)
+- Niels Hartvig (Odense, Denmark)
+- Dirk Gastaldo (Newbury Park, CA, USA)
+- Clayton McCook (Edmond, OK, USA)
+- Kris Schmitz (Washington, DC/New Brunswick, NJ)
+- Steven Miller (Vancouver, BC, Canada)
+- Kyle Larsen (Provo, UT)
+- Ben Fowler (Huntsville, AL)
+- Giuseppe Acito (Roma, Italy)
+- Mark M (Chicago, IL)
+- Chris Reilly (Detroit, MI)
+- Rod Snyder (Morgantown, WV, USA)
+- John Murray (Pinellas Park, FL, USA)
+- Shirley Steinmacher (son, Salt Lake City, UT, USA)
+- Michael Spradling (Raleigh, NC)
+- Tore Bjørndalen (Norway, Oppegård)
+- John Young (King of Prussia, PA)
+- Kathleen Gagnier (Orlando, FL)
+- Kim Goldmacher (Philadelphia, PA)
+- Craig Brenner (Seattle, WA)
+- Darryl Schick (PA)
+- Nadine Pedersen (Vancouver, Canada)
+- Beno Schechter (Coral Gables, FL)
+- Rami Laakso (Nummela, Finland)
+- Steve Lund (PEI, Canada)
+- Paul Andrel (Phoenixville, PA)
+- Allan Evans (Ottawa, Canada)
+- Simon Lewinson (NE Victoria, Australia)
+- Angie Kabat (Fairbanks, AK)
+- Jacob H (Waterford, MI)
+- Jim Van Hook (St. Louis, MO)
+- Pedro C (Porto, Portugal)
+- Roger Sanftner (San Antonio, TX)
+- Gabriela Ezquerro (Mexico City, MEX)
+- Jessica Carey (CA)
+- Lynne Beard (Kincardineshire, Scotland)
+- Carlin Pressnall (Seattle, WA)
+- James Brown (Derby, UK)
+- Allison Marx (Atlanta, GA)
+- David Ashby (Rexburg, ID)
+- Andrew Warrington (Alsace, France)
+- Kelsey Yearick (Crook, Colorado)
+- Marcel Zandvliet (The Hague, The Netherlands)
+- Gerard Dwan (Boston, MA)
+- Jon Groelz (Captain Cook, HI)
+- Christos Alonistiotis (Athens, Greece)
+- Chris Lodermeier (MN)
+- Tom Beesley (Brighton, UK)
+- Robert Sandvik (Stavanger, Norway)
+- Eugene Girard (Kitchener, Canada)
+- Luke Jenkins for Kyler (Vancouver, WA)
+- Brandon Hunnicutt (Denver, Colorado)
+- Kate Groves (Oxford, UK)
+- Tom Wells (Guildford, UK)
+- Kyle Masterman (Perth, Western Australia)
+- Virginia Saunders (Ontario, Canada)
+- Enda Farrell (Berlin, Germany)
+- Carl Robertson (Rochester, NY, USA)
+- Ben Ortega (Minneapolis, MN)
+- Reza Bolouri (Melbourne, Australia)
+- Todd Radel (Doylestown, PA)
+- Steve Mann (Bronx, NY)
+- Jason Nerothin (Madison, WI)
+- Eben Demong (San Ramon, CA)
+- Peetu Hongisto (Hollola, Finland)
+- Jonathan Cole (St. Louis, MO, USA)
+- Laura Ferrara (Hood River, OR, USA)
+- Caleb Seekell (Charlestown, RI, USA)
+- Dave Rich (Cambridge, ON, CANADA)
+- Tracey Berg-Fulton (Pittsburgh, PA)
+- Juan Mejías (Seville, Spain)
+- Mladen Cvijanovic (Buffalo, NY, USA)
+- Kendra Hunter (Rochester, NY)
+- Roxana Soetebeer (New Brunswick, Canada)
+- Bulbul Ahmed (Charlottesvill, VA, USA)
+- Minna Hannula (Finland)
+- Mark Orders (UK)
+- Alan Ryder (UK)
+- Robert Riemann (DE)
+- Grant Carlson (Sunnyvale, CA, USA)
+- Zachary Christman (Philadelphia, PA, USA)
+- Per Winterdijk (the Netherlands)
+- Paul Featonby (UK)
+- Lisa Morales (California, USA)
+- Rob Neu (wife, Utah, USA; sister-in-law, Virginia, USA)
+- Nancy Simons ( SW France)
+- Jill Gordon (UK)
+- Elwin Versluis (Abcoude, The Netherlands)
+- Carling Lellock (Pittsburgh, PA, USA)
+- Walter Feddern (Ontario, Canada)
+- Abigail Cember (Ardmore, PA, USA)
+- Megann Fuka (Tulsa, OK, USA)
+- Ariane Fleming (Seattle, WA)
+- Sarah Withee (Pittsburgh, PA, USA)
+- Daniel Noor (TN)
+- Raymond Richmond (Edmonton, AB, Canada)
+- Hosam El Din Mohamed El Nagar (Cairo, Egypt)
+- Mary Anne Patton (Brisbane, Australia)
+- Jared Bechard (Overland Park, KS, USA)
+- Tyler Duncan (Lethbridge, Alberta, Canada)
+- Eran I (Israel)
+- Mikko Kesti (Vantaa, Finland) Intel Edison
+- Jan Schenk (Munich, Germany)
+- Jess Phoenix (London, UK)
+- Kelly Polster (Fort Worth, TX)
+- Corey Stoerner (Phoenix, AZ)
+- Chris Wallis (Brisbane, QLD, Australia)
+- Dave Gourley (Kaysville, UT)
+- Chris Heywood (Manchester, UK)
+- Grahame Cottam (Newcastle upon Tyne, UK)
+- Norman Seward (Cardiff, Wales. UK)
+- Luminary Xion (Tokyo, Japan)
+- Nika Beros (Zagreb, Croatia)
+- Katja Jacob (Seattle, WA)
+- Paul Benedict (Evergreen, CO)
+- Luis Toussaint (Tarragona, ES)
+- Dana Sturdivant (Washington, D.C.)
+- Jakub Tomaszczyk (Gold Coast, Australia)
+- Andrew Hopkins (Newcastle, Australia)
+- Robert Clark (Canberra, Australia)
+- David Vanier (Saratoga Springs, NY, USA)
+- Kirsten Otis (Guelph, Ontario, Canada)
+- Natalia Stanichevsky (Ontario, Canada)
+- Patrick Gauthier (Toronto, Ontario, Canada)
+- Anne Evered (Philadelphia, PA)
+- Or Loantz (Israel)
+- Marsha Vasserman (Calgary, Alberta, Canada)
+- Melanie Ellis (Auckland, New Zealand)
+- Kelsey Mosley (Saint Joseph, MN, USA)
+- David Klapan (Osijek, Croatia)
+- Grant M. Beahlen (Macomb Co., MI,)
+- Nobu Aoki(Hyogo,Japan)
+- Kim & Remy Scott (Cambridge, MA)
+- Susanne Röckl (Berlin, Germany)
+- Jose Rico (Bilbao, Spain)
+- Sara Gardiner (Bicester, UK)
+- Mark Fletcher (Ipswich. UK)
+- Colum Keegan (Wicklow, Ireland)
+- Seamus Keegan (Wicklow, Ireland)
+- Nicholas Taylor (London, UK)
+- Andre Champigny (Moncton, New-Brunswick, Canada)
+- Martin Fredheim (Oslo, Norway)
+- John Clifton (Sussex, UK)
+- Pam Kavanagh (Kildare, Ireland)
+- Igor Chambon (Sao Paulo, Brazil)
+- Nigel Lund (Adelaide, Australia)
+- Taivo Liiv (Estonia)
+- Al Jeske (Edmonton, Alberta, CA)
+- Erik Schweighofer (Slovakia)
+- Mark & Kylie (Halifax, Nova Scotia, CA)
+- Aidan Gibson (Portland, OR, USA)
+- Mike Sutherland (San Diego, CA)
+- Carrie Hefner (Vancouver, WA)
diff --git a/docs/docs/While You Wait For Gear/monitoring-OpenAPS.md b/docs/docs/While You Wait For Gear/monitoring-OpenAPS.md
new file mode 100644
index 000000000..341635017
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/monitoring-OpenAPS.md
@@ -0,0 +1,678 @@
+# Understanding all the ways to monitor your rigs
+
+There are two general groups of ways to monitor your rigs:
+
+* Online, meaning it requires the rig to have internet connectivity (via a wifi or hotspot/tethered connection)
+* Offline, meaning the rig does not have any internet connectivity
+
+
+
+## The main ways of monitoring your rig ONLINE include:
+
+* [Papertrail](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#papertrail-remote-monitoring-of-openaps-logs-recommended)
+* [Accessing via SSH (either using an app on your phone, or your computer)](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#accessing-your-online-rig-via-ssh)
+* [Nightscout](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/nightscout-setup.html)
+* AndroidAPS NS Client ([Download the app-nsclient-release APK from here](https://github.com/MilosKozak/AndroidAPS/releases).)
+* Pebble watch (your watchface of choice, such as [Urchin](https://github.com/mddub/urchin-cgm))
+* [Apache Chainsaw](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#apache-chainsaw)
+
+********************************
+
+## The main ways of monitoring your rig OFFLINE include:
+
+* [Pancreabble](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#pancreabble-offline-connection-to-pebble-watch) (offline connection to your Pebble watch)
+* For Android users: "[Hot Button](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#hot-button-for-android-users)"
+* Accessing via [SSH over Bluetooth](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#accessing-your-offline-rig-via-ssh-over-bluetooth), or [by using a mobile router so your phone/rig can connect to the same network offline](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#accessing-your-offline-rig-via-ssh-when-your-phone-and-rig-are-connected-to-the-same-network)
+* For any phone type: [Creating a web page that can be accessed on the phone via the rig's IP address](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#offline-web-page-from-rig-for-any-phone-user)
+
+********************************
+
+## You'll probably come back to this page later to setup different monitoring options
+
+At this point, if you're not yet set up on OpenAPS, you won't quite be ready to set up all of the below options for accessing your rig - because your rig is not built yet! But, just know that there are different "online" and "offline" ways to **monitor** your rig, so you'll want to think about your preferences for both situations, and know that the instructions on the rest of this page are here when you're more familiar and are ready to set up some or all of them.
+
+********************************
+
+## Accessing your online rig via SSH
+
+See below for different ways to access your rig:
+* [If your computer and rig are on the same wifi network](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#if-your-computer-and-rig-are-on-the-same-wifi-network)
+* [If your computer and rig are on different wifi networks](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#if-your-computer-and-rig-are-on-different-wifi-networks)
+* [If your iPhone and rig are on the same wifi network](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/monitoring-OpenAPS.html#if-your-iphone-and-rig-are-on-the-same-wifi-network)
+
+********************************
+
+### If your computer and rig are on the same wifi network
+
+
+
+#### For Mac computers
+
+* Open the Terminal App found in the Utilities folder in Applications.
+
+* Use the command `ssh root@edisonhost.local` (**or whatever you named your edison host**, in the example below, the hostname was edison1). If this is your first time logging in to the rig on the computer, you may get a message about the authenticity of the host and whether you want to add the key fingerprint to the list of known hosts. Go ahead and answer yes. You will be asked for the password for the rig...enter your root password that you setup in Phase 0 (the default was edison). Realize that keystrokes will not appear as you enter the password. A successful login will result in a screen similar to below.
+
+
+
+* If you get an error about "could not resolve hostname", it is likely that your rig is actually connected to a different wifi network than the computer. Try the screen method (directions below) for connecting to your rig.
+
+
+
+* If you get an scary looking error about "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" that is likely because you are attempting to login to a rig that has the same hostname as a previous rig that has been logged into on the computer. (This is why you want to use unique hostnames if you are going to have multiple rigs.) You can delete the history of known hosts for the rig by entering the commands `cd .ssh` and then `rm known_hosts`. This will delete the log of known hosts on your computer. There's no significant downside to removing the known_host log, except that you will need to answer yes to the key fingerprint additions again for the first time you login to old rigs again. After you delete the known hosts, you can use the `ssh root@edisonhost.local` command to login, as described above.
+
+
+
+#### For Windows computers
+
+* Open PuTTY program
+
+* Click the SSH radio button and then enter the IP address of the rig on the "Host Name" line in PuTTY.
+
+
+
+* If you do not know the IP address of the rig, you can obtain it by first logging on using Serial connection (described below) and using the command `ifconfig`.
+
+
+
+* Click the "Open" button in the PuTTY window and, if this is your first time logging into the rig using PuTTY using ssh, you may see a warning regarding the server's host key. Click yes to add the host key to PuTTY's cache.
+
+
+
+* Login using login name `root` and password is whatever you changed it to during setup in Phase 0. The default password was edison. As you type the password, no keystrokes will appear on the screen. Successful login will leave you at a prompt for the root user.
+
+
+
+### If your computer and rig are on different wifi networks
+
+
+
+**Access to the rig will need a cable to connect the UART port on the rig with the USB port on the computer. You will need a cable capable of transmitting data. If you try all of the steps below and are unsuccessful at connecting, try a new cable.**
+
+#### For Mac computers
+
+* Use the Terminal app on the Mac, or follow [these directions for Windows](http://openaps.readthedocs.io/en/latest/docs/Resources/Edison-Flashing/all-computers-flash.html#if-you-re-using-a-windows-pc-for-console)
+
+* If you're using a Mac, use the command `sudo screen /dev/tty.usbserial-* 115200` to enable “screen” mode. You will be prompted to enter a password. Enter your **computer's password** not the rig's password here.
+
+
+
+* You may see a blank screen. Press RETURN to bring up the edison’s login screen. Login as `root` and use your root password (you should have changed it from the default of `edison` during the setup of the rig - if not, please [go back and do so now](http://openaps.readthedocs.io/en/latest/docs/Resources/Edison-Flashing/all-computers-flash.html#initial-edison-setup). A successful login will look like below.
+
+
+
+* If instead, you see a message at the bottom of the screen that says "Sorry, could not find a PTY." that usually means the system has not cleared a previous screen session. If you only had the rig connected by one cable in the UART port on rig, you can simply unplug the rig from the computer and move to a new USB port on the computer. If you don't have any "new" USB ports that were not used by the previous login attempt, then close out terminal app, restart the computer, and try again. This will clear the error.
+
+
+
+* If instead you see a message at the bottom of the screen that says "Cannot exec '/dev/tty.usbserial-*': No such file or directory", double check that you have your rig and computer connected via the rig's UART port. Using the OTG port will cause this error message. Or typos in the screen command will have same result. Double check your spelling, or better yet...use copy and paste whenever possible.
+
+
+
+#### For Windows Users
+
+* Navigate to your Control Panel and then to Device Manager. Click on the Ports to open your USB serial port. Find the COM port that the rig is connected to. In the screenshot below, COM7. Note: different USB ports will have different numbers. If you regularly plug your rig into the computer and use this connection type, you may need to make sure you update the COM number in the steps below if you are switching between different USB ports.
+
+
+
+* Open PuTTY program. Click on the Serial radio button, enter the COM number you got from the previous step into the Serial line number and change the speed to 115200. Click on Open button.
+
+
+
+* Enter `root` for the login and the password is whatever you changed it to during setup in Phase 0. The default password was edison. As you type the password, no keystrokes will appear on the screen. Successful login will leave you at a prompt for the root user as shown below.
+
+
+
+### autossh Reverse Tunnel
+
+If you have an ssh server that is always accessible on the Internet, you can use it as a known hop point to ssh into your rig as long as the rig has an Internet connection.
+
+On the rig, install autossh: `apt-get install autossh`
+
+Your ssh environment must be setup to use key based authentication. ([Basic instructions are here](https://www.debian.org/devel/passwordlessssh).)
+
+On the rig, add the lines below to the `/etc/ssh/ssh_config` file.
+```
+ ServerAliveInterval 60
+ ServerAliveCountMax 5
+```
+
+On the server, add the lines below to the `/etc/ssh/sshd_config` file.
+```
+ ClientAliveInterval 60
+ ClientAliveCountMax 5
+```
+
+The configuration values above ensure when the rig moves from wifi network to wifi network, it will require 5 minutes at most for autossh to establish a new link to the server.
+
+Test the ssh setup by executing autossh on the rig:
+```
+autossh -f -M 0 -T -N Click here to expand the UAMpredBGs description
+ When no carb announcements are available, or when announced carbs are mostly absorbed and COB-based predictions are less reliable, it is also possible to predict that observed deviations will gradually return to zero over some period of time. Once deviations have peaked and are decreasing at a reasonable rate, oref0’s UAM calculations assume that the deviations will continue decreasing at that same rate until they reach zero. If they’re decreasing, but too slowly, it assumes they’ll decrease linearly to zero over 3 hours. If deviations are still increasing, it assumes they’ll peak immediately and start decreasing at ⅓ of the rate they increased from their recent minimum. +
+
+ +
+
+
+
+
+Click here to expand the list of the `Config Variables` you need to enter:
++ +
| KEY | +VALUE | +
|---|---|
| API_SECRET | +Create your own API_SECRET. This is like the password to your NS site. Please write it down somewhere safe or commit it to memory, you will be using it in the future. It needs to be at least 12 characters long and should NOT use the `@` or `&` symbols. | +
| AUTH_DEFAULT_ROLES | +When `readable`, anyone can view Nightscout without a token. Setting it to `denied` will require authentication. Setting it to `denied` requires oref 0.5.0-dev. | +
| DISPLAY_UNITS | +enter either mg/dl or mmol | +
| ENABLE | +bridge openaps pump iob basal careportal sage cage maker(Enter all of the words without commas. Just a single space between each word. Make sure autocorrect does not add space between careportal. **Notice we are not including cob here.** If you are use Lookout or Logger, add xdrip-js to enable the CGM status pill If you have other plugins that you would like to enable, please add them here.) |
+
| DISABLE | +Leave blank | +
| ALARM_TYPES | +simple | +
| BG_HIGH | +Enter the numeric value of BG you’d like as an urgent high alarm. (Note: For users outside the US, this needs to be set in mgdl. Take your desired mmol number and multiply it by 18). | +
| BG_TARGET_TOP | +Enter the numeric value of the top of your target BG.(Note: For users outside the US, this needs to be set in mgdl. Take your desired mmol number and multiply it by 18). | +
| BG_TARGET_BOTTOM | +Enter the numeric value of the bottom of your target BG.(Note: For users outside the US, this needs to be set in mgdl. Take your desired mmol number and multiply it by 18). | +
| BG_LOW | +Enter the numeric value of the BG you’d like as an urgent low alarm.(Note: For users outside the US, this needs to be set in mgdl. Take your desired mmol number and multiply it by 18). | +
| PUSHOVER lines | +Can be left blank for now. If you decide to use Pushover later, you can come back and add your info to these lines. | +
| CUSTOM_TITLE | +This will be the text displayed in the upper left part of the NS website. | +
| THEME | +change from default to colors | +
| BRIDGE_USER_NAME | +Enter your Dexcom Share Account login name. This should be the same account name used in the Share2 or G5 Mobile app. | +
| BRIDGE_PASSWORD | +Enter your Dexcom Share Account password. | +
| BRIDGE_MAX_COUNT | +Default value is 1. Setting this to 7 will update the last 35 minutes of data. | +
+**The remaining variables can be left at their default values.** + +***************** +**Note:** for BRIDGE_MAX_COUNT: This value sets the number of BG values to pull from Share per update. Each Dexcom BG value represent 5 minutes. Nightscout defaults to BRIDGE_MAX_COUNT=1. If you lose connectivity with your Dexcom transmitter, your Share app will automatically backfill data points when you regain connectivity. Nightscount does not do this and you will have gaps in the data for when you were out of range. More information [here](https://github.com/nightscout/cgm-remote-monitor#bridge-share2nightscout-bridge). + +You can change the BRIDGE_MAX_COUNT value to pull more samples per query, which will backfill BRIDGE_MAX_COUNT values for you. This change increases your data usage and may affect your Nightscout billing tier. Setting BRIDGE_MAX_COUNT to 7 will update the previous 35 minutes of data and will keep OpenAPS up to date on your current BG trends. If you frequently have larger data gaps and you use autotune, you may consider increasing this number more to backfill data more aggressively. +***************** + +* Click the purple `Deploy` button at the bottom of screen. + + + +* Wait a little bit while Heroku builds your NS app. You’ll see some text scroll by in the Build App box, and then finally, you will have a message that the NS app was successfully deployed. If the app fails to deploy, it may be that you have not added your credit card information to your account yet. Go add that information in your account billing section, and then come back and press the deploy button again. Don't worry, your account is still free unless you choose otherwise. The credit card simply gives you added dyno hours on your free account (win-win). + + + +* You can verify your site’s successful build by clicking `View` (you should see black site with a profile warning). You will be redirected to a profile set-up page. (If it doesn't redirect automatically, refresh your webpage). + + + +You do not have to enter all the information in the profile if you are using OpenAPS (since OpenAPS will be providing the information for IOB and COB rather than letting NS calculate them), but you do have to fill out the `Basal Profile` and `TimeZone` at a minimum in order to have your temp basals properly display at first. Click `Save` when you have entered the information. You will be prompted to authenticate, if it is the first time you’ve used the device to make changes in your profile. Click on the `Authenticate` link at the bottom of the site, and enter your API_SECRET to complete the authentication. + + + +* Assuming your previous browser tab is still open for "Create a new App | Heroku", let's go back to that tab. This time instead of choosing the `View` option, we are going to select the `Manage App` button. Then, select the `Settings` tab near the top of the screen on your Heroku app. + + + +* Click on `Reveal Config Vars`. Scroll down the bottom of the Config Vars lines until you find the last blank one. You are going to add several additional lines of config vars for OpenAPS use; the DEVICESTATUS_ADVANCED is a required line, the others just make Nightscout more useful when using OpenAPS. + + + +
| KEY | +VALUE | +
|---|---|
| DEVICESTATUS_ADVANCED | +true | +
| PUMP_FIELDS | +battery reservoir clock status | +
| PUMP_RETRO_FIELDS | +battery reservoir clock status | +
| SHOW_FORECAST | +openaps | +
| SHOW_PLUGINS | +openaps pump iob sage cage careportal | +
| PUMP_ENABLE_ALERTS | +true | +
| PUMP_URGENT_BATT_V | +1.3(This is the pump battery voltage that will trigger a red, urgent alert in NS.) | +
| PUMP_URGENT_RES | +10(This is the reservoir volume that will trigger a red, urgent alert in NS.) | +
| PUMP_URGENT_CLOCK | +30 | +
| OPENAPS_ENABLE_ALERTS | +true | +
| OPENAPS_FIELDS | +status-symbol status-label iob meal-assist rssi | +
| OPENAPS_RETRO_FIELDS | +status-symbol status-label iob meal-assist rssi | +
| OPENAPS_WARN | +20(This is the minutes since OpenAPS last successfully looped. This will be a yellow alert in NS.) | +
| OPENAPS_URGENT | +60(Same as the alert above, but will be red in color and have a shorter snooze option.) | +
+
+1. Visit https://yourappname.herokuapp.com/admin. Replace "yourappname" with the name you chose for your app above, that is, the prefix of your NS site's URL. + - Add a new Role + + Name: `oref0rig` + + Permissions: Add the following 8 permissions. Note that the default window is too small to see them all after you paste them in. + ``` + api:devicestatus:create, + api:devicestatus:read, + api:entries:create, + api:entries:read, + api:treatments:create, + api:treatments:read, + api:profile:create, + api:profile:read + ``` + +  + +2. Add a new Subject + + Name: the name of your rig (same as the hostname of your rig). You will need to add a new Subject for each rig you run. + Note: Nightscout will shorten the name to 10 characters in your accesstoken, e.g., `myedisonhostname` becomes `myedisonho-0dccda4ae591e763` + + Roles: `oref0rig` + +  + + Press Save button. + + In the Subject - People, Device etc. view you'll see the access token for your rig, e.g., `myrigname-27c914cabc506fa3` + +3. You need your rig to use the token based authentication. This can be done in three different ways: + + - Using the `cd && ~/src/oref0/bin/oref0-setup.sh` interactive setup. Enter the access token (subjectname and hash of 16 characters, e.g., `myrigname-27c914cabc506fa3`) + Example of the interactive setup: + ``` + Are you using Nightscout? If not, press enter. + If so, what is your Nightscout host? (i.e. https://mynightscout.herokuapp.com)? https://mynightscout.herokuapp.com + Ok, https://mynightscout.herokuapp.com it is. + + Starting with oref 0.5.0 you can use token based authentication to Nightscout. This makes it possible to deny anonymous access to your Nightscout instance. It's more secure than using your API_SECRET. Do you want to use token based authentication y/[N]? y + What Nightscout access token (i.e. subjectname-hashof16characters) do you want to use for this rig? myrigname-27c914cabc506fa3 + ``` + + - Using the `oref0-setup` or `oref0-runagain.sh` command line. + Use `--api-secret=token=myrigname-27c914cabc506fa3`. Don't forget to start with `token=`. + During install it will connect to your Nightscout site and check if the permissions are ok. If OK you'll see this in your log: + ``` + 2017-06-10 19:46:14,758 INFO Nightscout host: https://mynightscout.herokuapp.com + 2017-06-10 19:46:14,816 INFO Starting new HTTPS connection (1): mynightscout.herokuapp.com + 2017-06-10 19:46:15,911 INFO Succesfully got Nightscout authorization token + 2017-06-10 19:46:15,925 INFO All permissions in Nightscout are ok + ``` + If it's not ok it will exit the setup script and tell you which permissions are missing. + + - Change the token in `ns.ini`. It's the third argument of the `args=` line: + ``` + [device "ns"] + fields = oper + cmd = nightscout + args = ns https://mynightscout.herokuapp.com token=myrigname-27c914cabc506fa3 + ``` + You must also change your `API_SECRET` in your crontab, e.g. `API_SECRET=token=myrigname-27c914cabc506fa3`. Use `crontab -e` to edit your crontab. + +4. Test the rig by running `openaps upload` or `openaps upload-ns-status` or just running the pump loop. You should see the update from myrigname in the OpenAPS pill in Nightscout. + +5. When all the rigs are 0.5.0 and are all using token based authentication, you can change the environment variables of your Nightscout: +- `AUTH_DEFAULT_ROLES` from `readable devicestatus-upload` to `denied` if you wish to block read-only access to your Nightscout instance. If you don't mind your CGM data being accessible to anyone with your Nightscout URL, you can just leave `AUTH_DEFAULT_ROLES` absent, which will default it to the value of `readable`. + +Other notes: +- Just like keeping your pump serial number and API_SECRET for yourself, you should not post your authentication token `myrigname-27c914cabc506fa3` on the Internet +- The authentication is also stored in your `crontab`, as `API_SECRET=token=myrigname-27c914cabc506fa3`. When token based authentication is used the API_SECRET on the rig will always start with `token=` instead of a hash. +- You must always secure your Nightscout site with secure http (https). Don't use http://mynightscout.herokuapp.com but rather always use https://mynightscout.herokuapp.com. +- Once you have token auth enabled, you can stop entering your API_SECRET in your browser when authenticating, and keep your API_SECRET as a root/Administrator password that you only use for configuring Nightscout. Instead, you can set up a user (as in steps 1 and 2 above) with the appropriate role. If you wish to be able to enter treatments into NS, you'll need to create an account with `careportal` access and authenticate with that in Nightscout. If you set AUTH_DEFAULT_ROLES to `denied` in step 5, you'll also need a user with `readable` permissions for any browsers that should have read-only access. + +
+
+### Switching from Azure to Heroku
+
+* If you are a current OpenAPS user and want to switch from Azure to Heroku, you will need to change your NS URL in both `ns.ini` and in `cron`. Alternatively, you can edit your runagain.sh file and run the setup script again.
+
+* If you’d like to seamlessly keep all your old Azure NS data showing in your new Heroku NS site, you’ll need to copy and paste your old `MONGODB` string from your Azure site. Find it in either Application Settings or Connection strings in your Azure control panel and then go to Heroku’s `MONGODB_URI` line. Replace the content with your copied string from Azure. Double check that your Azure collection used the “entries” name…if it doesn’t, then you will need to update that variable in Heroku to match as well.
+
+**Note:** It's a good idea to check your deployment connection in Heroku's dashboard after your deploy (typically this still needs to be manually connected after initial setup). Go your `Deploy` tab in your Heroku dashboard, click on the GitHub service, and select your GitHub cgm-remote-monitor repository. You can select the cgm-remote-monitor branch you'd like to deploy at the bottom of the screen. Both master and dev branches work for OpenAPS.
+
+
+
+## Nightscout Troubleshooting and FAQ
+
+### It's not working - I'm missing data in Nightscout?
+
+If you are using a "test pump" that has not received sufficient data in some time, Nightscout pills will NOT be displayed onscreen. Nightscout may also not work if it hasn't had CGM data in a while - so if you haven't been using a CGM and uploading CGM data to Nightscout for the past few days, the site may be empty as well. If this happens, simply use this pump in tandem with a CGM so glucose values are recorded and eventually uploaded to Nightscout. Once sufficient data has been collected (and OpenAPS plugin is enabled and saved) the OpenAPS pills should appear automatically. Medtronic CGM users may also [need to do this to get their CGM data flowing into Nightscout after a gap in uploading data](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/offline-looping-and-monitoring.html#note-about-recovery-from-camping-mode-offline-mode-for-medtronic-cgm-users).
+
+Dexcom CGM users should make sure they have "share" enabled and have actively shared their data with at least one follower, before data will begin flowing to Nightscout. If you don't want to share your data with another person, you can just follow yourself.
+
+### A Note about Nightscout's COB Pill
+
+If you have the Advanced Meal Assist (AMA) OpenAPS feature turned on, OpenAPS calculates COB *dynamically*. To see your COB on your Nightscout web app, look inside the OpenAPS pill. _(If it says "undefined", this means you do NOT have AMA turned on.)_
+
+Nightscout, however, has its own COB pill, which decays carbs *statically*, and it is **NOT** used in OpenAPS calculations.
+
+* **We highly recommend NOT using the Nightscout COB pill.** We even recommend removing it from your Nightscout ENABLE web app settings as it causes bugs, and great confusion, because it will do a static decay and/or mess up your Nightscout.
+
+* **Note also**: Nightscout's Bolus Wizard Preview (BWP) pill also decays carbs *statically*.
+
+* **To avoid confusion: Turn off all other Nightscout pills that use *static* COB calculations.**
+
+### How to display basal changes ("render basal")
+
+* In case you missed it during setup: we recommend that you "render"/display the basal rates (the blue lines to show what temp basals have been enacted, if any.) To do so, select "Default" or "Icicle" from the "Render Basal" pull-down menu in the Settings.
+
+### How to automatically sync your profile from Autotune
+
+OpenAPS does not read anything from Nightscout's *profile* to use for looping (so original basal rates, ISF, carb ratio, targets, etc. come from the pump) . However, if you like your Nightscout profile to accurately reflect what you are looping with and not be out of date, you can use a helper script to upload your rig's profile - that includes your Autotune results) to Nightscout.
+
+To upload the active oref0 profile to Nightscout, run the following command on the rig:
+```
+cd ~/myopenaps; oref0-upload-profile settings/profile.json $NIGHTSCOUT_HOST $API_SECRET
+```
+To synchronize the profile OpenAPS obtained from the pump, run the following command on the rig:
+```
+cd ~/myopenaps; oref0-upload-profile settings/pumpprofile.json $NIGHTSCOUT_HOST $API_SECRET
+```
+
+Afterward, your profile will probably look something like this:
+
+
+
+### How to display OpenAPS purple prediction/forecast lines
+
+* Click the three dots next to your timeframe horizon (2HR, 3HR, 6HR, 12HR, 24HR) and then enable “Show OpenAPS Forecasts”. Don't see this option? Check and make sure you added this variable and that your OpenAPS has successfully run.
+
+### Understanding OpenAPS purple predictions/forecast lines
+
+* There are up to four purple prediction lines that you will see: IOBpredBG; ZTpredBG; UAM; and COBpredBG.
+
+
+
+### Understanding the OpenAPS pill
+
+The OpenAPS pill box has four states, based on what happened in the last 15
+minutes: Enacted, Looping, Waiting, and Warning:
+
+* Waiting is when OpenAPS is uploading, but hasn't seen the pump in a while
+* Warning is when there hasn't been a status upload in the last 15 minutes
+* Enacted means OpenAPS has recently enacted the pump
+* Looping means OpenAPS is running but has not enacted the pump
+* Unknown means Error or Timeout; OpenAPS has reported a failure, or has reported no status for many hours.
+
+### All of a sudden, Nightscout is no longer showing treatments (bolus, carbs, finger BGs) on the graph or rendering my basals.
+
+If you suddenly find that Nightscout is not showing treatments (bolus, carbs, finger BGs etc.) on the graph; and/or that your basals are no longer being rendered in the blue basal line; but otherwise, everything looks normal and you are looping properly:
+
+You probably somehow got a future-dated treatment. One possible reason is a clock-time mismatch between your devices - for example, your BG meter, pump, CGM, or OpenAPS rig may have different dates or times set.
+
+**To remove future treatments:**
+* Go into Nightscout under "Settings" and "Admin tools" and delete any future-dated treatments (press the "remove treatments in the future" button). If the future treatments were caused by a time mismatch, you'll need to resolve that first, or the future dated treatments may simply be re-uploaded.
+
+
diff --git a/docs/docs/While You Wait For Gear/preferences-and-safety-settings.md b/docs/docs/While You Wait For Gear/preferences-and-safety-settings.md
new file mode 100644
index 000000000..211cf2c44
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/preferences-and-safety-settings.md
@@ -0,0 +1,352 @@
+# Understanding your preferences and safety settings
+
+All of the settings specific to OpenAPS (that can't be read from the pump) will live in this file, so when running the setup scripts or building your loop, you will have the `preferences.json` file built for the system to read, in addition to your pump profile settings. Many of these are important safety settings, with reasonable default settings, so other than described below, you likely won’t need to adjust these. If you do decide to adjust a setting, the best practice is to adjust one setting at a time, and observe the impact for 3 days. Changing multiple variables at once is a recipe for a lot of headaches and a lot of painful troubleshooting.
+
+(*Note that there are some preferences that show up by default; these are the most commonly adjusted. There are additional preferences available to set that are not used by everyone, and are described below - any of these can also be added to the preferences.json*)
+
+
+Here are the steps you need to follow - click here to expand the instructions:
++1. Visit https://yourappname.herokuapp.com/admin. Replace "yourappname" with the name you chose for your app above, that is, the prefix of your NS site's URL. + - Add a new Role + + Name: `oref0rig` + + Permissions: Add the following 8 permissions. Note that the default window is too small to see them all after you paste them in. + ``` + api:devicestatus:create, + api:devicestatus:read, + api:entries:create, + api:entries:read, + api:treatments:create, + api:treatments:read, + api:profile:create, + api:profile:read + ``` + +  + +2. Add a new Subject + + Name: the name of your rig (same as the hostname of your rig). You will need to add a new Subject for each rig you run. + Note: Nightscout will shorten the name to 10 characters in your accesstoken, e.g., `myedisonhostname` becomes `myedisonho-0dccda4ae591e763` + + Roles: `oref0rig` + +  + + Press Save button. + + In the Subject - People, Device etc. view you'll see the access token for your rig, e.g., `myrigname-27c914cabc506fa3` + +3. You need your rig to use the token based authentication. This can be done in three different ways: + + - Using the `cd && ~/src/oref0/bin/oref0-setup.sh` interactive setup. Enter the access token (subjectname and hash of 16 characters, e.g., `myrigname-27c914cabc506fa3`) + Example of the interactive setup: + ``` + Are you using Nightscout? If not, press enter. + If so, what is your Nightscout host? (i.e. https://mynightscout.herokuapp.com)? https://mynightscout.herokuapp.com + Ok, https://mynightscout.herokuapp.com it is. + + Starting with oref 0.5.0 you can use token based authentication to Nightscout. This makes it possible to deny anonymous access to your Nightscout instance. It's more secure than using your API_SECRET. Do you want to use token based authentication y/[N]? y + What Nightscout access token (i.e. subjectname-hashof16characters) do you want to use for this rig? myrigname-27c914cabc506fa3 + ``` + + - Using the `oref0-setup` or `oref0-runagain.sh` command line. + Use `--api-secret=token=myrigname-27c914cabc506fa3`. Don't forget to start with `token=`. + During install it will connect to your Nightscout site and check if the permissions are ok. If OK you'll see this in your log: + ``` + 2017-06-10 19:46:14,758 INFO Nightscout host: https://mynightscout.herokuapp.com + 2017-06-10 19:46:14,816 INFO Starting new HTTPS connection (1): mynightscout.herokuapp.com + 2017-06-10 19:46:15,911 INFO Succesfully got Nightscout authorization token + 2017-06-10 19:46:15,925 INFO All permissions in Nightscout are ok + ``` + If it's not ok it will exit the setup script and tell you which permissions are missing. + + - Change the token in `ns.ini`. It's the third argument of the `args=` line: + ``` + [device "ns"] + fields = oper + cmd = nightscout + args = ns https://mynightscout.herokuapp.com token=myrigname-27c914cabc506fa3 + ``` + You must also change your `API_SECRET` in your crontab, e.g. `API_SECRET=token=myrigname-27c914cabc506fa3`. Use `crontab -e` to edit your crontab. + +4. Test the rig by running `openaps upload` or `openaps upload-ns-status` or just running the pump loop. You should see the update from myrigname in the OpenAPS pill in Nightscout. + +5. When all the rigs are 0.5.0 and are all using token based authentication, you can change the environment variables of your Nightscout: +- `AUTH_DEFAULT_ROLES` from `readable devicestatus-upload` to `denied` if you wish to block read-only access to your Nightscout instance. If you don't mind your CGM data being accessible to anyone with your Nightscout URL, you can just leave `AUTH_DEFAULT_ROLES` absent, which will default it to the value of `readable`. + +Other notes: +- Just like keeping your pump serial number and API_SECRET for yourself, you should not post your authentication token `myrigname-27c914cabc506fa3` on the Internet +- The authentication is also stored in your `crontab`, as `API_SECRET=token=myrigname-27c914cabc506fa3`. When token based authentication is used the API_SECRET on the rig will always start with `token=` instead of a hash. +- You must always secure your Nightscout site with secure http (https). Don't use http://mynightscout.herokuapp.com but rather always use https://mynightscout.herokuapp.com. +- Once you have token auth enabled, you can stop entering your API_SECRET in your browser when authenticating, and keep your API_SECRET as a root/Administrator password that you only use for configuring Nightscout. Instead, you can set up a user (as in steps 1 and 2 above) with the appropriate role. If you wish to be able to enter treatments into NS, you'll need to create an account with `careportal` access and authenticate with that in Nightscout. If you set AUTH_DEFAULT_ROLES to `denied` in step 5, you'll also need a user with `readable` permissions for any browsers that should have read-only access. + +
+
+
+
+## Editing your preferences.json
+
+Your preferences are found in the directory `myopenaps/preferences.json`. To edit any of your preferences, you can enter `edit-pref` (as a shortcut) or `cd ~/myopenaps && nano preferences.json`
+
+To check your edits when you're done, use `cd ~/myopenaps && cat preferences.json` When editing preferences, it's advised to do so in terminal (not a word processor) in order to ensure ascii characters are used within your preferences file.
+
+IMPORTANT: Any variables that are not **true**, **false**, or a **number** MUST be inclosed in straight (not curly) quotes.
+
+ 1. "max_iob": 0, <-- Zero is a number, so no quotes necessary.
+ 2. "enableUAM": false, <-- True/False do not require quotes
+ 3. "curve": "rapid-acting" <-- "Rapid-acting" is not true/false or a number, so it must be inclosed in quotes.
+
+
+## Commonly-adjusted preferences:
+
+```
+{
+ "max_iob": 0,
+ "max_daily_safety_multiplier": 3,
+ "current_basal_safety_multiplier": 4,
+ "autosens_max": 1.2,
+ "autosens_min": 0.7,
+ "rewind_resets_autosens": true,
+ "adv_target_adjustments": true,
+ "unsuspend_if_no_temp": false,
+ "enableSMB_after_carbs": false,
+ "enableSMB_with_COB": false,
+ "enableSMB_with_temptarget": false,
+ "enableUAM": false,
+ "curve": "rapid-acting"
+}
+```
+
+#### max_iob:
+
+`max_iob` is an important safety setting for your OpenAPS set up. Beginning with oref0 0.6.0 and beyond, `max_iob` is the maximum amount of insulin on board from all sources -- both basal (or SMB correction) and bolus insulin -- that your loop is allowed to accumulate to treat higher-than-target BG. Unlike the other two OpenAPS safety settings (`max_daily_safety_multiplier` and `current_basal_safety_multiplier`), `max_iob` is set as a fixed number of units of insulin. Note that, in previous releases, `max_iob` reflected basal insulin on board only.
+
+In determining your `max_iob` setting, you should consider both your typical meal bolus size and your current basal rate settings when setting this safety parameter. A good rule of thumb to start out with is for `max_iob` to be no more than 3 times your highest basal rate PLUS your typical meal bolus. You can start conservatively and change this setting over time as you evaluate how the OpenAPS system works for you. For people using the advanced features such as SMB (especially those using Fiasp and intending for SMB to replace meal boluses), you will likely need to increase your `max_iob`.
+
+When you run the OpenAPS setup script, it will prompt you to set your `max_iob`. In previous oref0 releases (0.4.3 or older), the set up script automatically set `max_iob` to 0 units. This effectively made your initial OpenAPS installation only capable of setting temp basal rates in response to BG levels that were below your target BG levels. (And if your BG level is sufficiently below your target BG level, OpenAPS will set a 30 min. temporary basal rate of 0u/hr., which is often referred to as a "low glucose suspend".) Again, you can start conservatively and change this setting over time as you evaluate how the OpenAPS system works for you.
+
+The setting you choose during the setup script will be saved in the oref0-runagain script and can be used again if you need to rerun the script.
+
+#### max_daily_safety_multiplier:
+
+This is an important OpenAPS safety limit. The default setting (which is unlikely to need adjusting) is 3. This means that OpenAPS will never be allowed to set a temporary basal rate that is more than 3x the highest hourly basal rate programmed in a user's pump, or, if enabled, determined by autotune.
+
+#### current_basal_safety_multiplier:
+
+This is another important OpenAPS safety limit. The default setting (which is also unlikely to need adjusting) is 4. This means that OpenAPS will never be allowed to set a temporary basal rate that is more than 4x the current hourly basal rate programmed in a user's pump, or, if enabled, determined by autotune.
+
+### Important Note About Safety Multipliers:
+
+`max_daily_safety_multiplier` and `current_basal_safety_multiplier` work together, along with your pump's max basal rate safety setting (set on your pump in the "Basal" menu under "Max Basal Rate").
+
+OpenAPS will determine `maxSafeBasal` as the lowest of three values:
+
+* the user's max basal rate setting (which is set in the user's pump)
+* `max_daily_safety_multiplier` \* the highest programmed basal rate (as specified by the basal rates in the user's pump or, if enabled, determined by autotune)
+* `current_basal_safety_multiplier` \* the user's current basal rate (as specified by the current basal rate programmed in the user's pump or, if enabled, determined by autotune)
+
+If the temporary basal rate setting recommended by OpenAPS (as determined in [`oref0/lib/determine-basal/determine-basal.js`](https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js)) exceeds `maxSafeBasal`, `maxSafeBasal` is used instead.
+
+The following message will be reported to the *pump-loop.log*:
+
+ adj. req. rate: X.X to maxSafeBasal: Y.Y
+
+You can also view this message in the Nightscout OpenAPS pill (which pops up a detailed message about recent OpenAPS activity if you hover your mouse over the OpenAPS pill):
+
+
+
+#### A few examples:
+
+
+
+* In **Example 1**, the user's max basal safety setting is the constraining limit on the OpenAPS recommended temp basal rate.
+* In **Example 2**, 4x the user's current basal rate is the constraining limit on the OpenAPS recommended temp basal rate.
+* In **Example 3**, the user's current basal rate is at his/her highest programmed rate, but none of the safety constraints are binding; the OpenAPS recommended temp basal rate is delivered.
+* In **Example 4**, 3x the user's highest programmed basal rates is the constraining limit on the OpenAPS recommended temp basal rate.
+
+#### About "sensitivity"
+
+Sensitivity, or the sensitivity ratio, refers to autosens calculation of your current, presumably temporary, sensitivity to your normal insulin basal rates. The sensitivity ratio is relative to basal rates, so when using it for ISF it is inverted. Simply put, current insulin basal rate = normal insulin basal rate * sensitivity ratio, while current ISF = normal ISF / sensitivity ratio. So, for example if autosens detects you are more sensitive to insulin, it will lower your sensitivity ratio, e.g., to 0.8. Then, when determining the basal rate, it will use the sensitivity ratio of 0.8 to calculate your corrected basal rate, as normal basal rate * 0.8 (resulting in a lower basal rate), and your ISF as normal ISF / 0.8 (resulting in a higher ISF, i.e., more BG change per insulin unit). If you are less sensitive to insulin, it will raise your sensitivity ratio, e.g., to 1.2, resulting in basal rate of normal rate * 1.2 (a higher basal rate), and ISF of normal ISF / 1.2 (a lower ISF, i.e., less BG change per insulin unit).
+
+#### autosens_max:
+
+This is a multiplier cap for autosens (and autotune) to set a 20% max limit on how high the autosens ratio can be, which in turn determines how high autosens can adjust basals, how low it can adjust ISF, and how low it can set the BG target.
+
+#### autosens_min:
+
+The other side of the autosens safety limits, putting a cap on how low autosens can adjust basals, and how high it can adjust ISF and BG targets.
+
+#### rewind_resets_autosens:
+
+This feature, enabled by default, resets the autosens ratio to neutral when you rewind your pump, on the assumption that this corresponds to a probable site change. Autosens will begin learning sensitivity anew from the time of the rewind, which may take up to 6 hours. If you usually rewind your pump independently of site changes, you may want to consider disabling this feature.
+
+#### unsuspend_if_no_temp:
+
+Many people occasionally forget to resume / unsuspend their pump after reconnecting it. If you're one of them, and you are willing to reliably set a zero temp basal whenever suspending and disconnecting your pump, this feature has your back. If enabled, it will automatically resume / unsuspend the pump if you forget to do so before your zero temp expires. As long as the zero temp is still running, it will leave the pump suspended.
+
+#### carbsReqThreshold
+
+grams of carbsReq to trigger a pushover. Defaults to 1 (for 1 gram of carbohydrate). Can be increased if you only want to get Pushover for carbsReq at X threshold.
+
+#### curve: "rapid-acting"
+
+Rapid-acting is the default in 0.6.0 and beyond. You can change this to "ultra-rapid" for Fiasp ([see here for other tips on switching to Fiasp](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/usability-considerations.html#how-do-i-switch-between-insulin-types-or-switch-to-fiasp-what-should-i-change)), or "bilinear" for using the old curve. Most people prefer the rapid-acting curve over bilinear for Humalog/Novolog. [Read more here to understand the differences in the activity curves](http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/understanding-insulin-on-board-calculations.html#understanding-the-new-iob-curves-based-on-exponential-activity-curves).
+
+#### useCustomPeakTime
+
+Defaults to false. Setting to true allows changing insulinPeakTime
+
+#### insulinPeakTime
+
+Defaults to 75 for rapid acting (Humalog, Novolog). This is the number of minutes after a bolus activity peaks.
+Defaults to 55m for Fiasp if `useCustomPeakTime: false`
+
+## oref1-related preferences:
+
+These preference should **not** be enabled until you've been looping (and running autotune) for several weeks and are confident that all of your basals and ratios are correct. Please read the [oref1 section of the docs](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/oref1.html) before doing so.
+
+#### enableSMB_with_COB
+
+This enables supermicrobolus (SMB) while carbs on board (COB) is positive.
+
+#### enableSMB_with_temptarget
+
+This enables supermicrobolus (SMB) with eating soon / low temp targets. With this feature enabled, any temporary target below 100mg/dL, such as a temp target of 99 (or 80, the typical eating soon target) will enable SMB.
+
+#### enableUAM
+
+This enables detection of unannounced meal (UAM) carb absorption.
+
+#### enableSMB_always
+
+Defaults to false. When true, always enable supermicrobolus (unless disabled by high temptarget).
+
+#### enableSMB_after_carbs
+
+Defaults to false. When true, enables supermicrobolus (SMB) for 6h after carbs, even with 0 carbs on board (COB).
+
+#### allowSMB_with_high_temptarget
+
+Defaults to false. When true, allows supermicrobolus (if otherwise enabled) even with high temp targets.
+
+#### maxSMBBasalMinutes
+
+Defaults to start at 30. This is the maximum minutes of basal that can be delivered as a single SMB with uncovered COB. This gives the ability to make SMB more aggressive if you choose. 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.
+
+#### maxUAMSMBBasalMinutes
+
+Defaults to start at 30. This is the maximum minutes of basal that can be delivered by UAM as a single SMB when IOB exceeds COB. This gives the ability to make UAM more or less aggressive if you choose. 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. Reducing the value will cause UAM to dose less insulin for each SMB. It is not recommended to set this value higher than 60 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.
+
+## Exercise-mode related preferences:
+
+#### exercise_mode
+
+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.**
+
+synonym for high_temptarget_raises_sensitivity
+
+#### high_temptarget_raises_sensitivity
+
+Defaults to false. When set to true, raises sensitivity (lower sensitivity ratio) for temp targets set to >= 111. Synonym for exercise_mode. The higher your temp target above 110 will result in more sensitive (lower) ratios, e.g., temp target of 120 results in sensitivy ratio of 0.75, while 140 results in 0.6 (with default half_basal_exercise_target of 160).
+
+#### low_temptarget_lowers_sensitivity
+
+Defaults to false. When set to true, can lower sensitivity (higher sensitivity ratio) for temptargets <= 99. The lower your temp target below 100 will result in less sensitive (higher) ratios, e.g., temp target of 95 results in sensitivy ratio of 1.09, while 85 results in 1.33 (with default half_basal_exercise_target of 160).
+
+#### sensitivity_raises_target
+
+When true, raises BG target when autosens detects sensitivity
+
+#### resistance_lowers_target:
+
+Defaults to false. When true, will lower BG target when autosens detects resistance
+
+#### half_basal_exercise_target
+
+Set to a number, e.g. 160, which means when temp target is 160 mg/dL *and* exercise_mode=true, run 50% basal at this level (120 = 75%; 140 = 60%). This can be adjusted, to give you more control over your exercise modes.
+
+### Pushover related preferences
+
+#### pushover_snooze:
+
+Defaults to `15`. This sets the minimum time between SMB Pushover alerts.
+
+#### pushover_only:
+
+Defaults to `"carb"`. This sets the type of SMB alerts desired. Options are `"both"`, `"insulin"`, or `"carb"`. Setting pushover_only to `insulin` prevents SMB from sending carb required alerts when SMB thinks additional carbs are required to bring eventual BG up. Setting pushover_only to `carb` prevents SMB from sending insulin required alerts when SMB is hitting maxBolus (see warning in Pushover setup section). Setting pushover_only to `both` allows SMB to send both insulin required and carb required alerts.
+
+#### pushover_sound:
+
+Defaults to `"none"`. This sets the alert sound played on the user device. Valid options are available at https://pushover.net/api.
+
+#### pushover_priority:
+
+Defaults to `0`. This sets the Pushover priority. Valid options are -2, -1, 0, 1, and 2. `-2` generates no notification/alert. `-1` always sends a quiet notification. `0` triggers sound, vibration, and an alert according to the user's device settings. `1` displays a high-priority alert and bypasses the user's quiet hours. `2` requires confirmation from the user.
+
+#### pushover_retry:
+
+Defaults to `60`. When a priority 2 alert is sent, the alert will sound every pushover_retry seconds until the user acknowledges the alert.
+
+#### pushover_expire:
+
+Defaults to `600`. When a priority 2 alert is sent, the alert will sound every pushover_retry seconds until the user acknowledges the alert or pushover_expire seconds passes. After pushover_expire seconds, the alert will be cancelled.
+
+### Other preferences:
+
+Generally, you won't need to adjust any of the preferences below. But if you do wish to change the default behavior, you can add these into your preferences.json to do so (or use oref0-get-profile --updatePreferences to get the full list of all preferences added to your preferences.json).
+
+#### autosens_adjust_targets:
+
+This is used to allow autosens to adjust BG targets, in addition to ISF and basals.
+
+#### adv_target_adjustments:
+
+This feature was previously enabled by default but will now default to false (will NOT be enabled automatically) in oref0 0.6.0 and beyond. (There is no need for this with 0.6.0). This feature 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.
+
+#### skip_neutral_temps:
+
+Defaults to false, so that OpenAPS will set temps whenever it can, so it will be easier to see if the system is working, even when you are offline. This means OpenAPS will set a “neutral” temp (same as your default basal) if no adjustments are needed. If you are a light sleeper and the “on the hour” buzzing or beeping wakes you up (even in vibrate mode), you may want to turn this to “true” to skip setting neutral temps. However, we recommend leaving neutral temps enabled for most people who will be using this system on the go and out of constant connectivity.
+
+**Note**: if set to `true`, in order to reduce notifications at the top of the hour, it will also attempt to cancel temp basals (unless BG or minGuardBG is below threshold and a zero-temp is needed) prior to the top of the hour. Normally a new temp basal will be set (if still needed) after the top of the hour, but that may be delayed if the rig has issues connecting to the pump. People who want to minimize the 'on the hour' temp basal notification beeps/vibrations may choose to accept that risk and choose to set skip_neutral_temps to true.
+
+#### bolussnooze_dia_divisor:
+
+Bolus snooze is enacted after you do a meal bolus, so the loop won’t counteract with low temps when you’ve just eaten. The example here and default is 2; so a 3 hour DIA means that bolus snooze will be gradually phased out over 1.5 hours (3DIA/2).
+
+#### min_5m_carbimpact:
+
+This is a setting for default carb absorption impact per 5 minutes. The default is an expected 8 mg/dL/5min. This affects how fast COB is decayed in situations when carb absorption is not visible in BG deviations. The default of 8 mg/dL/5min corresponds to a minimum carb absorption rate of 24g/hr at a CSF of 4 mg/dL/g.
+
+#### carbratio_adjustmentratio:
+
+This is another safety setting that may be useful for those with secondary caregivers who aren’t dedicated to looking up net IOB and being aware of the status of the closed loop system. The default is 1 (i.e. do not adjust the carb ratio; off). However, in the secondary caregiver situation you may want to set a higher carb ratio to reduce the size of a manual bolus given at any time. With this ratio set to 1.1, for example, the loop would multiple the carb inputs by 10%, and use that number to calculate additional insulin. This can also be used by OpenAPS users who rely on the bolus wizard to calculate their meal bolus, but who want to only bolus for a fraction of the meal, and allow advanced meal assist to high-temp for the rest.
+
+#### maxCOB:
+
+This defaults maxCOB to 120 because that's the most a typical body can absorb over 4 hours. (If someone enters more carbs or stacks more; OpenAPS will just truncate dosing based on 120. Essentially, this just limits AMA as a safety cap against weird COB calculations due to fluky data.)
+
+#### remainingCarbsCap:
+
+This is the amount of the maximum number of carbs we'll assume will absorb over 4h if we don't yet see carb absorption.
+
+#### remainingCarbsFraction:
+
+This is the fraction of carbs we'll assume will absorb over 4h if we don't yet see carb absorption.
+
+#### autotune_isf_adjustmentFraction:
+
+The default of 0.5 for this value keeps autotune ISF closer to pump ISF via a weighted average of fullNewISF and pumpISF. 1.0 allows full adjustment, 0 is no adjustment from pump ISF.
+
+#### offline_hotspot
+
+Defaults to false. If true, enables an offline-only local wifi hotspot if no Internet available. (Do not set to true without testing and understanding how this will impact your connectivity.)
+
+Default hotspot network name is the rig name; default password is "#OpenAPS" (no quotations).
+
+#### 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.
+
+**SAFETY WARNING:** If the pump has a target range high end set lower than the BG input into the Bolus Wizard, the Bolus Wizard will add insulin to cover the carbs as well as bring BG down to the high end. I.e. if your high end is 110 and you enter a 160 BG and 45g of carbs in the Bolus Wizard, the Bolus Wizard will dose 1U to bring BG to 110 and 3U for carbs (assuming 50 (mg/dL)/U and 15g/U factors). The rig will likely have already dosed insulin to bring your BG to your low target, and you are potentially "double dosing". In these scenarios, you will have too much insulin onboard and can experience a severe low. If you use the Boluz Wizard, ensure the high end of the BG target range is a high number such as 250 mg/dL.
+
+#### A52_risk_enable (A52 risk mitigation)
+
+Defaults to false. 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.
+
+(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.)
+
+#### rewind_indicates_cartridge_change
+
+Defaults to false. If true, assumes reservoir and insulin have been replaced and resets Insulin Age (IAGE) on nightscout.
+
+#### prime_indicates_pump_site_change
+
+Defaults to false. If true, assumes cannula has been replaced after a fixed prime (ignores manual primes) and resets Cannula Age (CAGE) on nightscout.
+
+#### battery_indicates_battery_change
+
+Defaults to false. If true, assumes battery has been replaced and resets Battery Age (BAGE) on nightscout.
+
diff --git a/docs/docs/While You Wait For Gear/understanding-insulin-on-board-calculations.md b/docs/docs/While You Wait For Gear/understanding-insulin-on-board-calculations.md
new file mode 100644
index 000000000..3bc1cadca
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/understanding-insulin-on-board-calculations.md
@@ -0,0 +1,170 @@
+# Understanding Insulin on Board (IOB) Calculations
+
+The amount of Insulin on Board (IOB) at any given moment is a key input into the `determine-basal` logic, which is where all the calculations for setting temporary basal rates or small microboluses (SMBs) takes place. This amount of insulin on board gets passed into [`oref0/lib/determine-basal/determine-basal.js`](https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js) as part of the `iob.json` file. That information is then used to project forward blood glucose (BG) trends, which the `determine-basal` logic then responds to in order to correct course. This piece of the OpenAPS documentation provides an explanation of the assumptions used about how insulin is absorbed and how those assumptions translate into the insulin on board calculations used to project BG trends.
+
+## First, some definitions:
+* **dia:** Duration of Insulin Activity. This is the user specified time (in hours) that insulin lasts in their body after a bolus. This value comes from the user's pump settings.
+
+
+* **end:** Duration (in minutes) that insulin is active. `end` = `dia` * 60.
+
+
+* **peak:** Duration (in minutes) until insulin action reaches it's peak activity level.
+
+
+* **activity:** This is percent of insulin treatment that was active in the previous minute."
+---
+
+Click here to expand a clickable list to jump to each preference:
+ +- [Editing your preferences.json](#editing-your-preferencesjson) +- [Commonly-adjusted preferences:](#commonly-adjusted-preferences) + * [max IOB:](#max-iob) + * [max daily safety multiplier:](#max-daily-safety-multiplier) + * [current basal safety multiplier:](#current-basal-safety-multiplier) + * [Important Note About Safety Multipliers:](#important-note-about-safety-multipliers) + + [A few examples:](#a-few-examples) + * [autosens_max:](#autosens-max) + * [autosens_min:](#autosens-min) + * [rewind_resets_autosens:](#rewind-resets-autosens) + * [unsuspend_if_no_temp:](#unsuspend-if-no-temp) + * [carbsReqThreshold](#carbsreqthreshold) + * [curve: "rapid-acting"](#curve-rapid-acting) + * [useCustomPeakTime](#usecustompeaktime) + * [insulinPeakTime](#insulinpeaktime) +- [oref1-related preferences:](#oref1-related-preferences) + * [enableSMB_after_carbs](#enablesmb-after-carbs) + * [enableSMB_with_COB](#enablesmb-with-cob) + * [enableSMB_with_temptarget](#enablesmb-with-temptarget) + * [enableUAM](#enableuam) + * [enableSMB_always](#enablesmb-always) + * [enableSMB_after_carbs](#enablesmb-after-carbs) + * [allowSMB_with_high_temptarget](#allowsmb-with-high-temptarget) + * [maxSMBBasalMinutes](#maxsmbbasalminutes) + * [maxUAMSMBBasalMinutes](#maxUAMSMBBasalMinutes) +- [Exercise-mode related preferences:](#exercise-mode-related-preferences) + * [exercise_mode](#exercise-mode) + * [high_temptarget_raises_sensitivity](#high-temptarget-raises-sensitivity) + * [low_temptarget_lowers_sensitivity](#low-temptarget-lowers-sensitivity) + * [sensitivity_raises_target](#sensitivity-raises-target) + * [resistance_lowers_target:](#resistance-lowers-target) + * [half_basal_exercise_target](#half-basal-exercise-target) +- [Pushover related preferences](#pushover-related-preferences) + * [pushover_snooze:](#pushover-snooze) + * [pushover_only:](#pushover-only) + * [pushover_sound:](#pushover-sound) + * [pushover_priority:](#pushover-priority) + * [pushover_retry:](#pushover-retry) + * [pushover_expire:](#pushover-expire) +- [Other preferences:](#other-preferences) + * [autosens_adjust_targets:](#autosens-adjust-targets) + * [adv_target_adjustments:](#adv-target-adjustments) + * [skip_neutral_temps:](#skip-neutral-temps) + * [bolussnooze_dia_divisor:](#bolussnooze-dia-divisor) + * [min_5m_carbimpact:](#min-5m-carbimpact) + * [carbratio_adjustmentratio:](#carbratio-adjustmentratio) + * [maxCOB:](#maxcob) + * [remainingCarbsCap:](#remainingcarbscap) + * [remainingCarbsFraction:](#remainingcarbsfraction) + * [autotune_isf_adjustmentFraction:](#autotune-isf-adjustmentfraction) + * [offline_hotspot](#offline-hotspot) + * [wide_bg_target_range](#wide-bg-target-range) + * [A52_risk_enable (A52 risk mitigation)](#a52-risk-enable-a52-risk-mitigation) + +
+
+ +## Insulin Activity + +The code in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js) calculates a variable called `activityContrib`, which has two components: `treatment.insulin` and a component referenced here as `actvity`. The unit of measurement for `treatment.insulin` is *units of insulin*; the unit of measurement for `activity` is *percent of insulin used each minute* and is used to scale the `treatment.insulin` value to *units of insulin used each minute*. (There is no variable `activity` created in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js). There is, however, a variable called `activity` created in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js), which represents a slightly different concept. See the FINAL NOTE, below, for more details.) + +There are three key assumptions the OpenAPS algorithm makes about how insulin activity works in the body: + +* **Assumption #1:** Insulin activity increases linearly (in a straight line) until the `peak` and then decreases linearly (but at a slightly slower rate) until the `end`. + +* **Assumption #2:** All insulin will be used up. + +* **Assumption #3:** When insulin activity peaks (and how much insulin is used each minute) depends on a user's setting for how long it takes for all their insulin to be used up. That setting is their duration of insulin activity (`dia`) and generally ranges between 2 and 8 hours. The OpenAPS logic starts off with a default value of 3 hours for `dia`, which translates into 180 minutes for `end`, and assumes that insulin activity peaks at 75 minutes. (This is generally in line with findings that rapid acting insluins (Humalog, Novolog, and Apidra, for example) peak between 60 and 90 minutes after an insulin bolus.) This assumption, however, is generalizable to other user `dia` settings. That is, `peak` can be expressed as a function of `dia` by multiplying by the ratio (75 / 180): + + `peak` = f(`dia`) = (`dia` \* 60 \* (75 / 180)) + + So, for example, for a `dia` of 4 hours, `peak` will be at 100 minutes: + + 100 = (4 \* 60 \* (75 / 180)) + +**NOTE:** The insulin action assumptions described here are set to change with the release of [oref0, version 0.6.0](https://github.com/openaps/oref0/tree/0.6.0-dev). The new assumptions will use exponential functions for the insulin action curves and will allow some user flexibility to use pre-set parameters for different classes of fast-acting insulins (Humalog, Novolog, and Apidra vs. Fiasp, for example). For a discussion of the alternate specifications of insulin action curves, see [oref0 Issue #544](https://github.com/openaps/oref0/issues/544). When oref0, version 0.6.0 is released and the current assumptions are no longer recommended, this documentation will be updated. + +## What The Insulin Activity Assumptions Look Like +Given a `dia` setting of 3 hours, insulin activity peaks at 75 minutes, and between the 74th and 75th minutes, approximately 1.11 percent of the insulin gets used up. + + + +Adding up all the insulin used *each minute* between 0 and `end`, will sum to 100 percent of the insulin being used. + + + +The area under the "curve" can be calculated by taking the [definite integral](https://en.wikipedia.org/wiki/Integral) for the `activity` function, but in this simple case the formula for the area of a triangle is much simpler: + + Area of a triangle = 1/2 * width * height + + = 1/2 * 180 * 1.11 + + = 99.9 (close enough to 100 -- the actual value for activity is 1.1111111, which gets even closer to 100) + +For shorter `dia` settings, the `peak` occurs sooner and at a higher rate. For longer `dia` settings, the `peak` occurs later and at a lower rate. But for each triangle, the area underneath is equal to 100 percent. + + + +## Cumulative Insulin Activity + +Given these `activity` profiles, we can plot cumulative `activity` curves, which are S-shaped and range from 0 to 100 percent. (Note: This step isn't taken in the actual [`oref0/lib/determine-basal/determine-basal.js`](https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js) program, but plotting this out is a useful way to visualize/understand the insulin on board curves.) + + + +Just like how the insulin activity curves shift depending on the setting for `dia`, the cumulative activity curves do as well. + + + +## Insulin on Board + +Insulin on board (`iob`), is the inverse of the cumulative activity curves. Instead of ranging from 0 to 100 percent, they range from 100 to 0 percent. With `dia` set at 3 hours, about 70 percent of insulin is still available an hour after an insulin dosage, and about 17 percent is still available two hours afterwards. + + + +Similar to how the `activity` "curves" (triangles) and cumulative `actvity` curves vary by `dia` settings, the `iob` curves also vary by `dia` setting. + + + +Similar to calculations above, the code in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js) calculates a variable called `iobContrib`, which has two components: `treatment.insulin` and and a component referenced here as `iob`. The unit of measurement for `treatment.insulin` is *units of insulin*; the unit of measurement for `iob` is *percent of insulin remaining each minute* and is used to scale the `treatment.insulin` value to *units of insulin remaining each minute*. (There is no variable `iob` created in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js). There is, however, a variable called `iob` created in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js), which represents a slightly different concept. See the FINAL NOTE, below, for more details.) + +Finally, two sources to benchmark the `iob` curves against can be found [here](http://journals.sagepub.com/doi/pdf/10.1177/193229680900300319) and [here](https://www.hindawi.com/journals/cmmm/2015/281589/). + +**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*. + +
+
+---
+
+# Understanding the New IOB Curves Based on Exponential Activity Curves
+
+As of 0.6.0 OpenAPS has new activity curves available for users to use.
+
+In the new release, users are able to select between using a "bilinear" (looks like what was plotted above: `/\`) or "exponential" curves. Unlike the bilinear `activity` curve (which varies only based on `dia` values in a user's pump), the new exponential curves will allow users to specify both the `dia` value to use AND where they believe their `peak` insulin activity occurs.
+
+A user can select one of three curve defaul settings:
+
+* **bilinear:** Same as how the curves work in oref0, version 0.5 -- IOB curve is calculated based on a bilinear `activity` curve that varies by user's `dia` setting in their pump.
+
+* **rapid-acting:** This is a default setting for Novolog, Novorapid, Humalog, and Apidra insulins. Selecting this setting will result in OpenAPS to use an exponential `activity` curve with `peak` activity set at 75 minutes and `dia` set at 300 minutes (5 hours).
+
+* **ultra-rapid:** This is a default setting for the relatively new Fiasp insulin. Selecting this setting will result in OpenAPS to use an exponential `activity` curve with `peak` activity set at 55 minutes and `dia` set at 300 minutes (5 hours).
+
+ >**Note:** If **rapid-acting** or **ultra-rapid** curves are selected, a user can still choose a custom `peak` and `dia` time, but subject to two constraints:
+ >
+ > * `dia` must be greater than 300 minutes (5 hours); if it's not, OpenAPS will set `dia` to 300 minutes.
+>
+> * `peak` must be set between 35 and 120 minutes; if it's not, OpenAPS will set `peak` to either 75 or 55 minutes, depending on whether the user selected **rapid-acting** or **ultra-rapid** default curves.
+
+## What Do The Exponential Curves Look Like?
+Most commonly, *exponential* is associated with *exponential growth* -- as in, how quickly bacteria might grow in a petri dish, for example. A little less commonly, *exponential* is associated with *exponential decay* -- as in, what the radioactive half-life of a particular element might be.
+
+Examples of such *exponential growth* and *exponential decay* could look like this:
+
+
+(Though the mathematical formulas can be written such that how steep the growth or decay curves can vary quite a bit.)
+
+In the application of exponential curves in modeling how insulin is used in the human body, the trick is to write a mathematical formula that combines some delay in the activity, some rapid growth in the activity to the peak, and then a smooth transition down until all the insulin is used up. (See the **Technical Details**, below for links to the underlying math.)
+
+With `dia` set to 5 hours and the `peak` set to 75 minutes (the default settings for **rapid-acting** insulins), the exponential activity curves in the OpenAPS dev branch looks like this:
+
+
+
+Just like how the bilinear curve in OpenAPS version 0.5.4, the `activity` curves in version 0.6 will start at zero and end at zero and the area under the curve will sum up to 100 percent of the insulin being used up.
+
+
+
+The shape of exponential `activity` curves can vary by either `dia` or by `peak`. Below is what the `activity` curves look like for three separate `peak` settings, but holding the `dia` setting fixed at 5 hours.
+
+
+
+A useful way to visualize how the `activity` curves translate to the `iob` curves is to first show what the cumulative `activity` curves look like:
+
+
+
+And then the `iob` curves are just the inverse of the cumulative `activity` curves:
+
+
+
+## How Do The Exponential Curves Compare To The Bilinear Curves?
+The most important question to a user might be: "Well which set of curves is better for me to use?"
+
+Everyone is different, and their bodies may absorb insulin at different rates. Furthermore, an individual's insulin absorption may vary from day-to-day or week-to-week for many reasons. But with a lot of parameter settings, finding the **best** one is often a process of trial-and-error.
+
+That said, the bilinear curve currently used in OpenAPS 0.5.4 is a relatively simple model of how insulin is absorbed. Although it's a simple model, in many cases it provides decent approximations. The proposed exponential curves are more complex and more closely aligned to how an individual's body might absorb their insulin. But users may or may not find significant differences in how their OpenAPS performs just by switching to the exponential curves.
+
+You can think of the exponential curve for the default **rapid-acting** insulin settings (`dia` = 5 hours, `peak` = 75 minutes) as being a combination of two bilinear curves. One where `dia` is set to 3 hours and the `peak` occurs at 75 minutes; and another one where the `dia` is set to 5 hours, but the `peak` occurs at 125 minutes.
+
+
+
+(The area under each of the three curves sums to 100 percent.)
+
+To make a more direct, apples-to-apples, comparison, setting the exponential curve with `dia` = 5 hours and `peak` = 125 minutes, the difference between the two curves is a little clearer:
+
+
+**NOTE: As described above, OpenAPS will NOT allow you to set a `peak` value above 120 minutes. This graph is shown just to make a direct comparison between the two types of curves.**
+
+Finally, going back to an exponential curve with `dia` set to 5 hours and `peak` set to 75 minutes, the comparison between how the `iob` curve looks relative to the `iob` curve using the bilinear `activity` curve with `dia` set to 5 hours is probably the most relevant:
+
+
+
+The `iob` curve based on the exponential `activity` curve has insulin being used up significantly faster than the `iob` curve based on the bilinear `activity` curve. After one hour, for example, there is a 13 percent difference in how much insulin is remaining between the two curves, and after 2 hours there is a 17 percent difference between the two curves.
+
+## Technical Details
+The source for the new functional forms for the exponential curves were calculated by [Dragan Macsimovic](https://github.com/dm61) and can be found as part of a discussion on the [LoopKit Github page](https://github.com/LoopKit/Loop/issues/388#issuecomment-317938473). There were many others contributing to this discussion, development, and testing of exponential curves for Loop and OpenAPS. The [full discussion](https://github.com/LoopKit/Loop/issues/388) is very technical, but useful if you want more information on the exponential curves.
diff --git a/docs/docs/While You Wait For Gear/understanding-wifi-options.md b/docs/docs/While You Wait For Gear/understanding-wifi-options.md
new file mode 100644
index 000000000..09b175be8
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/understanding-wifi-options.md
@@ -0,0 +1,62 @@
+# Understanding your wifi options
+
+If you want to keep your rig small and portable, using the internet will be important (assuming you are using a Dexcom CGM) to keep BG values flowing to the loop. Ways your rig can stay online and access the internet are:
+
+* Joining known wifi networks [(you'll be able to add more wifi networks to your rig in the future)](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/on-the-go-wifi-adding.html)
+* BT-tethering to your cell phone's hotspot
+* Wifi-tethering to your cell phone's hotspot
+* Wifi-tethering to mifi device
+
+By default, the rig's programming in OpenAPS is to prefer joining known wifi connections over BT-tethered connections. Basically, the rig will look every minute to see if a wifi connection is available. If it is, the rig will connect to that. When a wifi connection is unavailable, the rig will attempt to BT-tether to your phone's hotspot (assuming you have done the work to pair the two devicecs as part of your rig's setup).
+
+Most users prefer a combination of known wifi networks and BT-tethering to maintain internet access for their rig. This minimizes cell phone data use while at the same time requiring no intentional action on the user's part when they enter/leave their known network areas. The rig will move seamlessly off/on known networks and BT-tethers without needing help. Using wifi-tethers requires the user to manually turn the connections on/off when they get into the range of a preferred wifi network to save cell data, therefore those connections aren't preferred.
+
+These [helpful mobile apps](http://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/useful-mobile-apps.html) are worth checking out, as they'll aid you with accessing your rig when it gets connected online.
+
+### Home Wifi
+
+If your home wifi is flaky, your OpenAPS looping will likely be flaky as well. Speed isn't super important, but reliability of uptime is. If your router is old and hasn't been updated in awhile, simply updating your router may be a good idea. Routers are about $100 for a new, well-featured router. If you get your router as part of a package from your ISP, you can ask if they have any updated equipment to improve your home wifi network's stability. Many ISPs tend to forget about their customers' old equipment until they start complaining about it.
+
+### Home router
+
+Have you ever accessed your home wifi's router to see the devices connected to it? How about to make adjustments to your firewall if one is installed? I highly recommend becoming familiar with logging into your home router...this will let you quickly see (1) if your rig is successfully connected to your home wifi and (2) the MAC address and IP address of your rig.
+
+*********
+**NOTE** IP addresses are assigned to the rig by the device providing the internet access. So when the rig is on your home wifi network, the IP address is assigned by your home's router. When the rig is on your phone's hotspot, the IP address is assigned by your phone. The private IP addresses for a wifi network will generally be in the format of `192.168.1.XX` or `10.10.1.XX` and the private IP addresses for a phone hotspot will generally be in the format of `172.20.10.XX` The last two digits will not always be the same every time your rig connects. Most routers, however, will allow you in the Advanced Settings section to configure your LAN settings to always give your rig the same IP address. If you find that you cannot access your rig sometimes, it is a good practice to check if maybe the IP address of the rig has changed since the last time you looked and consider setting your router to assign the rig the same IP address each time.
+***********
+
+Most home routers can be accessed by going to the URL `http://192.168.1.1` on your computer's browser while it is connected to the home wifi. Alternatively, check your router for a sticker that includes information about logging into the router (most include a sticker on the bottom of the router). If there is no sticker, and the URL doesn't work, try googling your router's manufacturer and model number for login information. Each manufacturer usually has a different combination of default user names and logins, for example:
+
+* NetGear routers have user name as `admin` and password is `password`
+
+* Linksys routers have no user name and password is `admin`
+
+* Asus routers have a default for both user and password of `admin`
+
+By having access to your home router, you can easily see if you rig is listed as a connected device. You can also bring up the MAC address and IP address of the rig, which may be helpful in other areas of the rig setup that are discussed later.
+
+
+
+### School wifi networks
+
+School districts vary widely in their wifi structure and access. Start talking to your school district's IT department well in advance of looping to discuss options for the rig's access to school wifi.
+
+If you are sending your t1d kid to school with an OpenAPS rig, getting on the school's wifi network will save you cell phone data and phone battery. Some school districts will need the MAC address of the rig to add it to their "approved" devices list. Other school districts may provide a special login for the rig.
+
+If the school district refuses to allow the rig access to the school's wifi network, you can use BT tethering to your phone's hotspot to stay online while at school. The downside is that you will be using your cell data during the school day and it will cause added drain on the phone's battery.
+
+In some cases, schools have let the phone on the school's wifi but not the rig. Unfortunately though, this won't help much if your kid uses an iPhone. IPhones do not allow the rig to be on the phone's hotspot while the phone is also on school's wifi. So, when the rig connects to the iPhone, the iPhone will disconnect from the school's wifi. Androids (some of them at least) are able to maintain a wifi connection while the rig is tethered to its hotspot.
+
+### Mifi device
+
+If the school won't allow rig's wifi access, or you can't get your rig to use your phone's hotspot, you could use a mifi device through your cell provider. The mifi is a small box (about half the size of a dex receiver usually) that projects a wifi signal using your cellular data plan. If you use a mifi, the phone could stay connected to the school's wifi and the rig could stay connected to the mifi.
+
+One downside of a mifi box, however, is that since the rig is using a wifi-tethered connection to the mifi box...the rig will stay connected until you turn the mifi box off. When your kid (and rig) comes back into a known wifi network, your rig will not necessarily automatically move to the known wifi network from the mifi box. And of course, it's another device to carry.
+
+### Known wifi networks
+
+You will want to prepare ahead of your rig-build by gathering the wifi network names and passwords from areas that you will be at frequently (home, friends' houses, work, etc). By adding known wifi networks to your your rig's setup, you can save from using your cellular data plan to keep your rig running. As you are gathering the network names and passwords, remember to pay attention to lower vs upper case letter, hypens, or special characters. If the names and passwords do not match exactly, the rig will not be able to connect to the network.
+
+### Unknown wifi networks
+
+Unknown wifi networks are pretty frequent during travel. These can be hit or miss for rig connectivity. Networks that require you to click on a terms and conditions (like Starbucks) or enter a last name/room number (like many hotels) will not work for the rig. Sometimes though, you'll get lucky and a hotel will have an open, easy wifi network. There's a section later about how to add wifi networks while you are traveling.
diff --git a/docs/docs/While You Wait For Gear/understanding-your-Explorer-Board-rig.md b/docs/docs/While You Wait For Gear/understanding-your-Explorer-Board-rig.md
new file mode 100644
index 000000000..cf5e5a3f4
--- /dev/null
+++ b/docs/docs/While You Wait For Gear/understanding-your-Explorer-Board-rig.md
@@ -0,0 +1,136 @@
+# Understanding your OpenAPS rig
+
+## Pi HAT rig
+
+After April 2018, there is a Pi+HAT rig as an option for closing the loop with OpenAPS. The HAT can be ordered from the same place that makes the Explorer Board ([click here](https://enhanced-radio-devices.myshopify.com/products/900mhz-explorer-hat?variant=1950212653065). We call it the "Explorer HAT", to differentiate from the Explorer "Board" that goes with the Edison.
+
+
+
+#### Getting Physical: Build your Pi/HAT rig
+
+If you chose a "Pi Zero WH" (with headers), you will place the HAT on the Pi.
+
+##### Buttons and Menu System
+
+The Explorer Board Pi HAT includes a 128x64 OLED display with two general purpose buttons to navigate an included menu system.
+
+##### Button Navigation
+
+The Pi HAT has two general purpose buttons labeled "Up" and "Down". A single press of the "Up" button will move the menu selection cursor up a single menu item and a single press of the "Down" button will move the menu selection cursor down a single menu item.
+
+A double press of the "Down" button will enter in currently selected menu item as indicated by the ">" next to a menu item.
+
+A double press of the "Up" button will take you back to the previous screen.
+
+##### Menu Items
+
+Click here to expand information about insulin activity calculations for older insulin curves with DIA shorter than the 0.7.0 default of 5, as well as information about current variables used in IOB calculations:
++ +## Insulin Activity + +The code in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js) calculates a variable called `activityContrib`, which has two components: `treatment.insulin` and a component referenced here as `actvity`. The unit of measurement for `treatment.insulin` is *units of insulin*; the unit of measurement for `activity` is *percent of insulin used each minute* and is used to scale the `treatment.insulin` value to *units of insulin used each minute*. (There is no variable `activity` created in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js). There is, however, a variable called `activity` created in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js), which represents a slightly different concept. See the FINAL NOTE, below, for more details.) + +There are three key assumptions the OpenAPS algorithm makes about how insulin activity works in the body: + +* **Assumption #1:** Insulin activity increases linearly (in a straight line) until the `peak` and then decreases linearly (but at a slightly slower rate) until the `end`. + +* **Assumption #2:** All insulin will be used up. + +* **Assumption #3:** When insulin activity peaks (and how much insulin is used each minute) depends on a user's setting for how long it takes for all their insulin to be used up. That setting is their duration of insulin activity (`dia`) and generally ranges between 2 and 8 hours. The OpenAPS logic starts off with a default value of 3 hours for `dia`, which translates into 180 minutes for `end`, and assumes that insulin activity peaks at 75 minutes. (This is generally in line with findings that rapid acting insluins (Humalog, Novolog, and Apidra, for example) peak between 60 and 90 minutes after an insulin bolus.) This assumption, however, is generalizable to other user `dia` settings. That is, `peak` can be expressed as a function of `dia` by multiplying by the ratio (75 / 180): + + `peak` = f(`dia`) = (`dia` \* 60 \* (75 / 180)) + + So, for example, for a `dia` of 4 hours, `peak` will be at 100 minutes: + + 100 = (4 \* 60 \* (75 / 180)) + +**NOTE:** The insulin action assumptions described here are set to change with the release of [oref0, version 0.6.0](https://github.com/openaps/oref0/tree/0.6.0-dev). The new assumptions will use exponential functions for the insulin action curves and will allow some user flexibility to use pre-set parameters for different classes of fast-acting insulins (Humalog, Novolog, and Apidra vs. Fiasp, for example). For a discussion of the alternate specifications of insulin action curves, see [oref0 Issue #544](https://github.com/openaps/oref0/issues/544). When oref0, version 0.6.0 is released and the current assumptions are no longer recommended, this documentation will be updated. + +## What The Insulin Activity Assumptions Look Like +Given a `dia` setting of 3 hours, insulin activity peaks at 75 minutes, and between the 74th and 75th minutes, approximately 1.11 percent of the insulin gets used up. + + + +Adding up all the insulin used *each minute* between 0 and `end`, will sum to 100 percent of the insulin being used. + + + +The area under the "curve" can be calculated by taking the [definite integral](https://en.wikipedia.org/wiki/Integral) for the `activity` function, but in this simple case the formula for the area of a triangle is much simpler: + + Area of a triangle = 1/2 * width * height + + = 1/2 * 180 * 1.11 + + = 99.9 (close enough to 100 -- the actual value for activity is 1.1111111, which gets even closer to 100) + +For shorter `dia` settings, the `peak` occurs sooner and at a higher rate. For longer `dia` settings, the `peak` occurs later and at a lower rate. But for each triangle, the area underneath is equal to 100 percent. + + + +## Cumulative Insulin Activity + +Given these `activity` profiles, we can plot cumulative `activity` curves, which are S-shaped and range from 0 to 100 percent. (Note: This step isn't taken in the actual [`oref0/lib/determine-basal/determine-basal.js`](https://github.com/openaps/oref0/blob/master/lib/determine-basal/determine-basal.js) program, but plotting this out is a useful way to visualize/understand the insulin on board curves.) + + + +Just like how the insulin activity curves shift depending on the setting for `dia`, the cumulative activity curves do as well. + + + +## Insulin on Board + +Insulin on board (`iob`), is the inverse of the cumulative activity curves. Instead of ranging from 0 to 100 percent, they range from 100 to 0 percent. With `dia` set at 3 hours, about 70 percent of insulin is still available an hour after an insulin dosage, and about 17 percent is still available two hours afterwards. + + + +Similar to how the `activity` "curves" (triangles) and cumulative `actvity` curves vary by `dia` settings, the `iob` curves also vary by `dia` setting. + + + +Similar to calculations above, the code in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js) calculates a variable called `iobContrib`, which has two components: `treatment.insulin` and and a component referenced here as `iob`. The unit of measurement for `treatment.insulin` is *units of insulin*; the unit of measurement for `iob` is *percent of insulin remaining each minute* and is used to scale the `treatment.insulin` value to *units of insulin remaining each minute*. (There is no variable `iob` created in [oref0/lib/iob/calculate.js](https://github.com/openaps/oref0/blob/master/lib/iob/calculate.js). There is, however, a variable called `iob` created in [oref0/lib/iob/total.js](https://github.com/openaps/oref0/blob/master/lib/iob/total.js), which represents a slightly different concept. See the FINAL NOTE, below, for more details.) + +Finally, two sources to benchmark the `iob` curves against can be found [here](http://journals.sagepub.com/doi/pdf/10.1177/193229680900300319) and [here](https://www.hindawi.com/journals/cmmm/2015/281589/). + +**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*. + +
+
+ +* OpenAPS + * Status Graph + * Set Temp Target + * Cancel temp Target + * Eating Soon: 60m@80 + * Speaking: 45m@110 + * Walking: 45m@120 + * Running: 60m@140 + * Status Text + * Enacted Reason + * Show pump-loop.log + * Unicorn Logo +* Wifi + * Current Wifi Network + * Current Hostname + * Current IP Address + * Show network.log +* System + * Voltage + * Display Tests + * Checkerboard 1 + * Checkerboard 2 + * All On + * Boxes 1 + * Boxes 2 + * lsusb + * Reboot + * Cancel Reboot + +
+The current tree of available menu items (click to expand):
++ +* OpenAPS + * Status Graph + * Set Temp Target + * Cancel temp Target + * Eating Soon: 60m@80 + * Speaking: 45m@110 + * Walking: 45m@120 + * Running: 60m@140 + * Status Text + * Enacted Reason + * Show pump-loop.log + * Unicorn Logo +* Wifi + * Current Wifi Network + * Current Hostname + * Current IP Address + * Show network.log +* System + * Voltage + * Display Tests + * Checkerboard 1 + * Checkerboard 2 + * All On + * Boxes 1 + * Boxes 2 + * lsusb + * Reboot + * Cancel Reboot + +
+ +A series of images of the menu items can be [viewed here](https://imgur.com/a/9qLf93B). + +#### Charging + +The rig can be charged via microUSB. + +**Note:** the charging LED on the board is not working currently (unless you remove the Q3 transistor). Currently, it’s basically just a “plugged into the wall” indicator. The only side effect of removing Q3 is on the binary charging signal to the Pi (which doesn’t work anyway, and we’ve not tried to use). The voltage monitoring should work fine either way, but while the rig is charging will report 4.2V (“fully charged”) any time the battery is more than about 50% charged. So to be sure if it’s charged you should unplug the rig. + +**2nd Note:** make sure the battery plug is switched to ON while the rig is plugged. Otherwise the battery won't charge. + +#### Power + +Like an Edison rig, you can use a single cell (1s) lipo battery or similar; or use wall power. + +#### LED + +The Pi HAT offers 4 LEDs labeled with D1-D4. D1 is the charging LED and works as described above. D2 is the battery low indicator. It turns orange when the LiPo battery voltage goes below 3.6 V or when the rig is plugged and the battery switch is on OFF. D3 and D4 are connected to the CC1110 radio processor and are controlled by the subg_rfspy radio firmware while resetting the radio. That happens repeatedly during wait-for-silence. + +#### Multiple Rigs? What if I have an Edison AND a Pi rig? + +Just like multiple Edison rigs play well together, an Edison and a Pi rig can also work fine side by side. As always, best practice is to make sure they're in the same feature set - don't have one type of rig using SMB's if the other hardware has an old code version that isn't aware of SMB's. + +## Edison/Explorer Board rig + +The Edison/Explorer Board is one of the "rig" types you can use to close the loop with OpenAPS. + +#### Getting Physical: Build your Edison/Explorer Board rig/put the physical pieces together + +The Explorer board is where all the communications are housed for the rig, as well as the battery charger. The Edison is the mini-computer where all the OpenAPS code will be sent and used. In order for this to work, first you have to screw and connect the Edison and Explorer Board together with the nuts and bolts you order. + +The nuts and bolts are tiny, and the spaces are a little tight. It really helps to use a set of tweezers and a small Phillips head screwdriver. You will need 2 small gold screws, 2 small nuts, and 2 small silver screws. + +It's easiest to start with the Explorer board and put on 2 nuts and gold screws (nuts on the side with most of the wiring) inside the little outline where the Edison will eventually sit. The gold screws should be placed as shown, with nuts on the backside. Then, lay the Edison board on top of the gold screws, aligning the screw holes on the Edison board with the gold screw heads (which have screw holes in them). Use a small Phillips head screwdriver to tighten the silver screws into the gold screws beneath them. The Edison board should not wobble, and should feel secure when you are done. Attach your battery into the explorer board plug. A single red light should appear and stay lit. During the course of your OpenAPS rig use, it's good practice to periodically check that the nuts and screws stay tightened. If they come loose, the Edison can wobble off the connection to the Explorer board and you will either get looping failures (if it's loose) or be unable to connect to the Edison (if it comes completely off). + + + +#### Charging LiPo Battery + +You can use the little white block that comes with an iPhone (or similar charger) and a microB-USB cable. The same cables you used to setup the rig and connect to the computer will work for charging, too. Either one of the USB ports on the Explorer board will work for charging. When charging is active, there is an extra red light on in the corner of the Explorer board. When charging is complete, that corner red light will turn off. It may come back on periodically as the battery "tops off". You won’t do any damage leaving the rig plugged in for longer than the charge takes. + +While the rig is plugged in for charging, the Nightscout battery pill will read approximately 65%. This is because it is reading the charging voltage rather than the battery voltage. Once you disconnect from the charger, the Nightscout battery pill will display the LiPo battery's voltage and percent again. + +#### What the lights mean and where they are + +* The LED between the two ports is the power. If this light is on, your rig is on. +* The LED in the corner is the charging indictator. +* The two next to the microUSBs (one green on the latest boards) are for the cc1110 radio chip. By default they just blink once each when you mmtune or otherwise reset it. + +#### Where is the power button? + +The little black button on the end of the board near the JST connector is the power button. If you want to reboot your rig, the easiest way is to hold down the tiny power button for 10-15 seconds until the power light turns off. Wait a couple seconds and then press and hold the power button again until the light turns back on. Give the loop a couple minutes to get itself going again. Rebooting solves a majority of rig issues. + +#### Where is the radio? + +The radio and antenna are down on the end of the Explorer board where you see a little white stick (opposite end of the board from where your battery connects at the JST connector). + +### Cutting the trace to improve radio communication +Some OpenAPS users have found that cutting a portion of the Explorer Board's hidden copper antenna wire (called a trace) will improve radio comms with the pump. Before doing this, remember to disconnect any attached battery or power source. For North American (NA) or Canadian/Australian (CA) pumps (using the 916MHz band), you're looking to cut near the white line that is between the 1 and the 5 in the "915." Consider cutting on the 1-side rather than the exact spot where the white "cut" line is drawn because it is so close to the corner where the rest of the copper wire goes. To make the cut, use a sharp x-acto blade to cut through the copper just beneath the green surface of board. It will take a few swipes and you'll hear a small scraping noise when you get through the wire. Make sure you've cut all the way through the wire to the green circuit board material on the other side. + +Watch this [video](https://www.facebook.com/groups/TheLoopedGroup/permalink/1854229718127019/?hc_location=ufi) for an example. + +#### LiPo Battery + +LiPo batteries are great for a lot of things, but taking damage is not one of them. Please treat LiPo batteries with care. Keep them protected from puncture. The Explorer board has some “pointy” parts on the underside, so providing some protection from the board’s squish is a good idea. A small piece of protection (such as a business card or non-conductive thin foam sheet) will help protect the battery from the board above it. + +Since there is some warmth with an OpenAPS rig, it is also not recommended to put a rig unprotected in a pocket close to the body. The LiPo battery can become warped from the heat or bent from being in the pocket and potentially compromised. A durable case or waist-belt pouch is a good idea (see [here](http://openaps.readthedocs.io/en/latest/docs/Gear%20Up/edison.html#cases) for both hard and soft case ideas). + +The connections between the LiPo battery and its red and black wires are fragile and can break easily. Consider taping the wires to the battery with electrical tape as described in SparkFun's LiPo battery care [tutorial](https://www.sparkfun.com/tutorials/241). (See the Reinforcing the Power Cables section.) This will stabilize the wires and relieve tension on the connections. + +There are several places to get LiPo batteries, with lots of different dimensions and capacities. A 2000 mAh LiPo will get you about 12-14 hours of use, assuming you have the standard setup (which is what you get following these docs) running. + +#### What happens if you have multiple rigs? + +If you have multiple OpenAPS rigs, they’re built to be polite to each other. Even if you had two or more rigs in same room, they won’t trip each other up. They “wait for silence” before issuing any commands to the pump. By having multiple rigs throughout a house, you can move from room-to-room without carrying rigs because the rigs will pass-off comms as you moves in and out of the rig’s range. Stationary rigs will not need LiPo batteries and can be plugged directly into a wall charger from the Explorer board. diff --git a/docs/docs/introduction/communication-support-channels.md b/docs/docs/introduction/communication-support-channels.md deleted file mode 100644 index 278fe35bf..000000000 --- a/docs/docs/introduction/communication-support-channels.md +++ /dev/null @@ -1,24 +0,0 @@ -# Where to go for help with your implementation - -There are several ways to communicate with other participants and contributors in the #OpenAPS project. See also the [Resources](../Resources/index.rst) section for additional assistance. - -**Note:** It's best practice not to share your pump's serial number, so make sure not to include it in pictures or pasted text output when seeking help on pump communication. - -### Gitter -[Gitter](https://gitter.im/) is a messaging/chat service similar to IRC. It provides integration with GitHub and several other services. - -* The [nightscout/intend-to-bolus]( https://gitter.im/nightscout/intend-to-bolus) channel is where you will find active #OpenAPS discussions ranging from technical issues with openaps tools to control theory to general information. It is a great place to introduce yourself and get some help from those who are a few steps further down the road. -* For TI stick communication, use the [oskarpearson/mmeowlink channel](https://gitter.im/oskarpearson/mmeowlink) -* For RileyLink conversations, use the [ps2/rileylink channel](https://gitter.im/ps2/rileylink) -* For LoopKit conversations, use the [LoopKit/Loop channel](https://gitter.im/LoopKit/Loop) - -### Google Groups -A private google group focused on #OpenAPS development work can be found [here](https://groups.google.com/d/forum/openaps-dev). Request access to participate and see some of the archived discussions. If you're new, make sure to introduce yourself! - -### Issues on openaps GitHub -For reporting issues on the openaps tools formally, the openaps [issues page](https://github.com/openaps/openaps/issues) on GitHub is the proper forum. Feel free to try and get through the issues by working with others on the Gitter channel first if you think it may be something unrelated to the codebase. - -### Other online forums -Those in the #OpenAPS community are frequently found in other forums, such as on Twitter (using [the #OpenAPS hashtag](https://twitter.com/search?f=tweets&vertical=default&q=%23OpenAPS&src=typd), as well as [#WeAreNotWaiting](https://twitter.com/search?f=tweets&vertical=default&q=%23WeAreNotWaiting&src=typd)) and on Facebook in the ["CGM In The Cloud"](https://www.facebook.com/groups/cgminthecloud/) group. - -There is also a [Slack channel](https://omniapsslack.azurewebsites.net/) to discuss communication around other pumps that are being explored for being used for other DIY closed loops. diff --git a/docs/docs/introduction/index.rst b/docs/docs/introduction/index.rst deleted file mode 100644 index e27374502..000000000 --- a/docs/docs/introduction/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -Introduction ------------- - - -Introduction section includes: - -* Understanding This Guide -* Ways to Contribute -* Where to Go For Help With Your Implementation - -.. toctree:: - :maxdepth: 4 - - understand-this-guide - contribute - communication-support-channels - - diff --git a/docs/docs/introduction/understand-this-guide.md b/docs/docs/introduction/understand-this-guide.md deleted file mode 100644 index 4166b1273..000000000 --- a/docs/docs/introduction/understand-this-guide.md +++ /dev/null @@ -1,33 +0,0 @@ - -# Understanding this guide - -Some conventions used in this guide: - -* Wherever you see text that is formatted `like this`, it is a code snippet. You should copy and paste instead of attempting to type this out; this will save you debugging time for finding your typos. -* You will see a $ at the beginning of many of the lines of code. This - indicates that it is to be entered and executed at the terminal prompt. Do not type in the dollar sign $. -* Wherever there are `