Merge pull request #135 from openaps/dev

Dev to master

README.md

@@ -125,6 +125,7 @@ Below is an overview of all content linked inside of this document repository. [
         *   <a href="docs/docs/walkthrough/phase-6/considerations.md" class="reference internal">Phase 6: Iterating on Your Closed Loop</a>
         *   <a href="docs/docs/walkthrough/phase-6/keeping-up-to-date.md" class="reference internal">So you think you’re looping? Now keep up to date!</a>
         *   <a href="docs/docs/walkthrough/phase-6/daytime-testing.md" class="reference internal">Testing during the day</a>
+        *   <a href="docs/docs/walkthrough/phase-6/Usability-considerations.md" class="reference internal">Usability Considerations</a>
         *   <a href="docs/docs/walkthrough/phase-6/advanced-features.md" class="reference internal">Advanced features</a>
         *   <a href="docs/docs/walkthrough/phase-6/Configure-Automatic-Sensitivity-Mode.md" class="reference internal">Configuring Automatic Sensitivity Mode</a>
 -   <a href="docs/docs/Resources/index.rst" class="reference internal">Resources</a>

docs/Resources/wifi.md

@@ -0,0 +1,24 @@
+###Wifi Troubleshooting
+
+#My wifi connection keeps dropping and/or I keep getting kicked out of ssh
+There is a script that you can add to your root cron that will test your connection and reset it if it is down. Here is an example that runs every two minuntes (odd minutes). You could also do it every 5 minutes or less. Note, this does not have to be for an Edison, you can set this up for a Pi, etc as well.
+
+```
+cd ~/src
+git clone https://github.com/TC2013/edison_wifi
+cd edison_wifi
+chmod 0755 /home/edison/src/edison_wifi/wifi.sh
+```
+Next, add the script to your root cron. Note this is a different cron that what your loops runs on, so when you open it don't expect to see your loop and other items you've added.
+  * Log in as root ```su root```
+  * Edit your root cron ```crontab -e```
+  * Add the following line ```1-59/2 * * * * /home/edison/src/edison_wifi/wifi.sh google.com 2>&1 | logger -t wifi-reset```
+
+#I forget to switch back to home wifi and it runs up my data plan
+You can add a line to your cron that will check to see if <YOURWIFINAME> is avaiable and automatically switch to it if you are on a different network.
+  * Log in as root ```su root```
+  * Edit your root cron ```crontab -e```
+  * Add the following line ```*/2 * * * * ( (wpa_cli status | grep <YOURWIFINAME> > /dev/null && echo already on <YOURWIFINAME>) || (wpa_cli scan > /dev/null && wpa_cli scan_results | egrep <YOURWIFINAME> > /dev/null && udo pa_cli select_network $(wpa_clilist_networks | grep jsqrd | cut -f 1) && echo switched to <YOURWIFINAME> && sleep 15 && (for i in $(wpa_cli list_networks | grep DISABLED | cut -f 1); do wpa_cli enable_network $i > /dev/null; done) && echo and re-enabled other networks) ) 2>&1 | logger -t wifi-select```
+
+#I am having trouble consistently connecting to my wifi hotspot when I leave the house (iPhone)
+When you turn on your hotspot it will only broadcast for 90 seconds and then stop (even if it is flipped on). So, when you leave your house you need to go into the hotspot setting screen (and flip on if needed). Leave this screen open until you see your rig has connected. It make only take a few seconds or a full minute.

docs/docs/Resources/my-first-pr.md

@@ -7,29 +7,32 @@ It's actually not too hard to do one and it is a great way to contribute. This d
 * Double checking that they your edits look good to you on your copy. 
 * Make a few notes for what you did so people can understand why you made the change. 
 * Then do a pull request, which is to ask the administrataors of the repository to pull your changes 
-back into the dev branch of the main repository. 
+back into the dev (not master) branch of the main repository. 
 * At which time they will do a quick review and merge your changes in.
 
 OK, let's get started. For our example we are going to make an edit to the openaps docs repository.
 
 1. Go to https://github.com/openaps/docs and hit Fork in the upper right to make your own copy of the repository.
 2. Github will automatically take you to your copy (notice in the address bar you are now in your own personal github directory)
-3. In the branch drop down on the upper left of the page we are going to select the dev branch, since that is the one we want to edit. 
+3. In the branch drop down on the upper left of the page we are going to select the dev branch instead of master, since that is the one we want to edit. 
 4. Now we need to find the file we want to edit. Click through the directory structure until you find and are looking at the content of the file you want to change.
 5. Next, press the pencil icon in the upper right next to the trash can icon.
 6. Make edits to the file as necessary.
 7. Next we want to commit our changes. But first we should note what we changed and why. Be sure to put a one liner explaining the why of making the changes you did.
 8. Commit the changes.
 9. Now look and make sure everyting you changed looks like you meant it to (no typos, etc). If any problems, go back and edit again and save again.
 
-We now have an improved file that we want to be pulled back into the dev repository at https://github.com/openaps/docs
-
-1. Go to https://github.com/openaps/docs
-2. Select dev from the branch drop down on the upper left (since that's where we'd like the changes to go to)
-3. Press the pull request button
-4. Set up the the branches you are targeting. The easiest way of thinking about the branch range is this: the base branch is where you think changes should be applied, the head branch is what you would like to be applied.
-5. So choose so the base fork as openaps/docs and then the base as dev. The head fork is going to be <youraccount>/docs and the base as dev. 
-6. It should show the list of changes you made. If not, you did something wrong so stop here and ask for help. If the list looks like your changes then put a note in there to what the overarching reason for the changes are (in your case you only made one, but you could have made a bunch). Create the PR.
+We now have an improved file that we want to be pulled back into the dev branch of the openaps/docs repository at https://github.com/openaps/docs
+
+1. Go to https://github.com/[YOUR_GITHUB_USERNAME]/docs
+ * Or you can go to https://github.com and then click on "docs" in the "Your repositories" section in the lower right.  Both methods will get you to the right place.
+2. Select "dev" (not "master") from the branch drop down on the upper left (since that’s where we’d like the changes to go to)
+3. Click the green "New pull request" button
+4. Under the Compare Changes heading, click "compare across forks"
+5. Set up the the branches you are targeting. The easiest way of thinking about the branch range is this: the base branch is where you think changes should be applied, the head branch is what you would like to be applied.
+6. So, choose the base fork as openaps/docs and then the base as dev (not master). The head fork is going to be <i>youraccount</i>/docs and the base as dev (not master).
+![Pull Request](../Images/Pull_Request.png)
+7. It should show the list of changes you made. If not, you did something wrong so stop here and ask for help. If the list looks like your changes then put a note in there to what the overarching reason for the changes are (in your case you only made one, but you could have made a bunch). Create the PR.
 
 It will now be in a list of PR's that the team will review and potentially give feedback on before committing to the main documentation for openaps!
 

docs/docs/Resources/troubleshooting.md

@@ -54,7 +54,7 @@ OpenAPS uses git as the logging mechanism, so it commits report changes on each
 
 To fix a corrupted git repository you can run `oref0-fix-git-corruption.sh`, it will try to fix the repository, and in case when repository is definitly broken it copies the remainings in a safe place (`tmp`) and initializes a new git repo.
 
-Warning: do not run any  openaps commands with sudo in front of it `sudo openaps`. If you do, your .git permissions will get messed up. Sudo should only be used when a command needs root permissions, and openaps does not need that.
+Warning: do not run any  openaps commands with sudo in front of it `sudo openaps`. If you do, your .git permissions will get messed up. Sudo should only be used when a command needs root permissions, and openaps does not need that. Such permission problems can be corrected by running `sudo chown -R pi.pi .git` in the openaps directory.  If you are using an Intel Edison, run `sudo chown -R edison.users .git`. 
 
 ### Environment variables
 
@@ -74,5 +74,7 @@ json: error: input is not JSON: Unexpected '<' at line 1, column 1:
         
   This error usually comes up when you have pulled a file down from Nightscount that was an invalid file. Typcially you might see this when trying to pull down treatments. Make sure that you have your HOST and API_KEY set correctly at the top of your cron, in your ~/.profile
 
+### Wifi and hotspot issues
+See [wifi troubleshooting page](wifi.md)
 
 

docs/docs/walkthrough/phase-0/hardware.md

@@ -2,6 +2,10 @@
 # Hardware
 This section describes the hardware components required for a 'typical' OpenAPS implementation. There are numerous variations and substitutions that can be made but the following items are recommended for getting started. If you come across something that doesn't seem to work, is no longer available, or if you have a notable alternative, feel free to edit this document with your suggestions.
 
+To start, here is a high-level guide for understanding if your pump is compatible for OpenAPS:
+
+!["Can I do OpenAPS with this pump?"](https://github.com/openaps/docs/blob/b6b742d30b8313dce33b59fc279647343e4915cb/docs/docs/walkthrough/phase-0/Can%20I%20close%20the%20loop%20with%20this%20pump_May%2020%202016.jpg "Can I do OpenAPS with this pump?")
+
 If you're interested in working on communication for another pump (Omnipod, Animas, etc), [click here](http://bit.ly/1nTtccH) to join the collaboration group focusing on alternative pump communication.
 
 
@@ -13,7 +17,9 @@ If you're interested in working on communication for another pump (Omnipod, Anim
 		 * 515/715
 		 * 522/722
 		 * 523/723 (with firmware 2.4A or lower)
-		 * 554 (European Veo, with firmware 2.6A or lower)
+		 * 554/754 (European Veo, with firmware 2.6A or lower)
+		 * (To check firmware, hit Esc on the home screen and scroll all the way to the bottom.  You can also go into the Utilities menu and look for a PC Connect option.  If that is present, the pump will *not* work for looping.  If it's absent, it should be able to receive temp basal commands.)
+
 * <b>A way to communicate with the pump</b>:
 	* Medtronic CareLink USB stick is the recommended option for your initial loop setup
 	* **Note** that there are now other hardware options available to communicate with the pump. Some positives to an alternative include better range; some negatives include having to solder and the fact that they're not documented in this set of documentation yet. But if you're interested, check out some of the alternatives in [the mmeowlink wiki](https://github.com/oskarpearson/mmeowlink/wiki). 
@@ -121,6 +127,7 @@ A large-capacity power supply that is greater than 8000 mAh (milliAmp-hours) is
 
 [TeckNet® POWER BANK 9000mAh USB External Battery Backup Pack](http://www.amazon.com/gp/product/B00FBD3O2M)
 
+[Zendure® 2nd Gen A3 Portable Charger 10000mAh - 2.1a Dual USB - in-line charging](www.amazon.com/Zendure-2nd-Portable-Charger-10000mAh/dp/B014RBEAQC/ref=sr_1_1)
 
 ### USB Cables
 
@@ -138,10 +145,9 @@ Repeated wireless communication with the pump drains the battery quite quickly.
 
 ### Cases
 
-The Raspberry Pi is extremely minimalistic and does not come in a protective case. This is fine for development work, but presents an issue for day-to-day use. There are hundreds of cases available, but here some examples of what others are using in their OpenAPS builds.
+The Raspberry Pi is extremely minimalistic and does not come in a protective case. This is fine for development work, but presents an issue for day-to-day use. There are hundreds of cases available, but here is an example of what others are using in their OpenAPS builds.
 
 [JBtek® Jet Black Case for Raspberry Pi B+ & Raspberry Pi 2 Model B](http://www.amazon.com/gp/product/B00ONOKPHC)
 
-[Raspberry Pi B+ /PI2 Acrylic Case](http://www.amazon.com/Raspberry-Pi-PI2-Acrylic-Case/dp/B00M9ZW6QU)
 
 Additionally, for mobile use, it is helpful to have something besides a lunchbox to carry the entire rig around. The size and weight of the component set as well as the limited range of the CareLink USB stick constrains the options here, but there are still some workable solutions. Waist-worn running gear and camera cases seem to work well. Two options:  [FlipBelt](https://flipbelt.com/) and [Lowepro Dashpoint 20](http://store.lowepro.com/dashpoint-20). 

docs/docs/walkthrough/phase-0/loops-in-progress.md

@@ -2,7 +2,9 @@
 
 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. This way we know how many people are in the development phase, too.
 
-New to Github, and PRs? Check out how to submit your first PR.
+New to Github, and PRs? [Check out how to submit your first PR](../../../../docs/docs/Resources/my-first-pr.md).
+
+When you submit the PR, be sure to target the *dev* branch of openaps/docs, not the master branch.  If you target master, we'll need to ask you to re-submit, or it will likely cause a merge conflict with edits from people who correctly targeted dev.
 
 List of people who are working on closed loops:
 
@@ -11,7 +13,16 @@ List of people who are working on closed loops:
 - 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)