See docs, Section 3.1
$ wpa_passphrase "<my_SSID>" "<my_password>" >> /etc/wpa_supplicant/wpa_supplicant.conf
-
Repeat as necessary to add all relevant WiFi networks
-
Use single quotes for SSID and PSK if an escape character is required
Add 8192cu.conf to /etc/modprobe.d/,
Two solutions:
- https://www.raspberrypi.org/forums/viewtopic.php?t=61665
- https://learn.adafruit.com/adafruits-raspberry-pi-lesson-3-network-setup/test-and-configure#fixing-wifi-dropout-issues
Set up the timezone; make sure the RPi, pump, and dex are in-sync (and if you change one, you change them all)
A number of dependencies can be installed via the package manager, apt-get.
Install git, dependencies, PyPi and OpenAPS
See docs, Section 3.2
sudo apt-get git install python \
python-dev python-setuptools \
python-software-properties python-numpy
sudo easy_install -ZU openapssudo openaps-install-udev-rules
## **Enable tab completion for efficiency**
sudo activate-global-python-argcompleteLog out, and back in.
Update openaps (when required)
$ sudo easy_install -ZU openaps
These installations assume the system is for usage, not for development. To install from source, see the individual plugin GitHub pages
Install mmhistorytools, mmglucosetools, openaps-predict
sudo easy_install openapscontrib.mmhistorytools \
openapscontrib.mmglucosetools openapscontrib.predict
(not going to show how for this one quite yet)
Install openaps-monitor
(check the link for full installation instructions)
Openaps Name :
Pump Name :
Pump Serial :
Dexcom name : Add Dexcom CGM receiver as device (not required if using Medtronic CGM)
Openaps manages a git database to store your data, and information about the provenance of that data at every step. Let's teach openaps about our situation.
- Move into new openaps directory
openaps init $myopenaps
cd $myopenaps
- Add cgm and pump devices
openaps device add $my_pump_name medtronic $my_pump_serial
openaps device add $my_dexcom_name dexcom
A vendor is an implementation of some device. Third party plugins can
implement the vendor protocol to implement new kinds of devices for openaps.
A device is the name we give to actual hardware we own that we would
like the implementation to work with. Openaps knows about Medtronic and Dexcom
devices; the community has provided several new implementations to help manage
data.
Add openaps plugins (first as vendors, then as devices)
| Munge name | |
| Glucose Tool name | |
| Predict name | |
| Dose name |
$ openaps vendor add openapscontrib.mmhistorytools
$ openaps device add $munge mmhistorytools
$ openaps vendor add openapscontrib.mmglucosetools
$ openaps device add $glucose mmglucosetools
$ openaps vendor add openapscontrib.predict
$ openaps device add $predict predict
$ openaps vendor add openapscontrib.dose
$ openaps device add $dose dose
Check that the devices are all added properly
$ openaps device show
medtronic://pump
dexcom://cgms
mmhistorytools://munge
mmglucosetools://glucose
predict://predict
dose://dose
where the strings after the // are the names you used for $my_pump_name, $my_dexcom_name, et ceter
Once devices are configured, you can use them. openaps use allows
using any of the device's vendor operations on the device, right from the
commandline.
Check that you can talk with your pump
$ openaps use $my_pump_name model
should return something like:
"723"
Check that you can talk with your dex
$ openaps use $my_dexcom_name iter_glucose 1
should return something like:
[
{
"trend_arrow": "FLAT",
"system_time": "2015-08-23T21:45:29",
"display_time": "2015-08-23T13:46:21",
"glucose": 137
}
]
Add a whole bunch of reports
It's a good idea to check each one out after adding by invoking it and checking
the output. For example, after the first one below (with your dex connected),
run $ openaps report invoke recent_glucose.json, which will create a file
called recent_glucose.json. Then, run $ cat recent_glucose.json and you
should see a file with your most recent glucose values.
- The items in <angle_brackets> are the names you assigned when adding the devices; don't actually use the < >
- If you are using a Medtronic CGM, the first report should use the
$my_pump_namedevice instead of the$my_dexcom_namedevice; theiter_glucose_hoursfunction is common to those devices - For the first two, the number
6is used; you should use a number greater than or equal to your insulin duration, plus a few hours (I have an insulin duration of 3 hours, so I use 3 + 3 = 6 hours to cover longer square boluses) - We know that
read_insulin_sensitiviesis mispelled; this is done because it is mispelled in the openaps toolset, so we decided to keep it consistent - When you are testing the ones near the bottom (that take in a file), make sure you have run the previous reports to generate those input files
$ openaps report add recent_glucose.json JSON $my_dexcom_name iter_glucose_hours 6
$ openaps report add recent_history.json JSON $my_pump_name iter_pump_hours 6
$ openaps report add read_clock.json JSON $my_pump_name read_clock
$ openaps report add read_battery_status.json JSON $my_pump_name read_battery_status
$ openaps report add read_settings.json JSON $my_pump_name read_settings
$ openaps report add read_carb_ratios.json JSON $my_pump_name read_carb_ratios
$ openaps report add read_selected_basal_profile.json JSON $my_pump_name read_seleced_basal_profile
$ openaps report add read_insulin_sensitivies.json JSON $my_pump_name read_insulin_sensitivies
$ openaps report add read_bg_targets.json JSON $my_pump_name read_bg_targets
$ openaps report add read_status.json JSON $my_pump_name read_status
$ openaps report add clean_glucose.json JSON $glucose clean recent_glucose.json
$ openaps report add reconcile_history.json JSON $munge reconcile clean_hisory.json
$ openaps report add resolve_history.json JSON $munge resolve reconcile_history.json
$ openaps report add clean_history.json JSON $munge clean recent_history.json
$ openaps report add normalized_history.json JSON $munge normalize \
resolved_history.json
--basal-profile basal.json
--zero-at read_clock.json
$ openaps report add predict_glucose.json JSON $predict glucose \
normalize_history.json \
recent_glucose.json \
--settings read_settings.json \
--insulin-sensitivities read_insulin_sensitivies.json \
--carb-ratios read_carb_ratios.json
$ openaps report add predict_glucose_without_future_basal.json JSON $predict glucose \
normalize_history.json \
recent_glucose.json \
--settings read_settings.json \
--insulin-sensitivities read_insulin_sensitivies.json \
--carb-ratios read_carb_ratios.json
--basal-dosing-end read_clock.json
$ openaps report add recommended_dose.json JSON $dose recommend \
--resolved-history resolve_history.json \
--settings read_settings.json \
--clock read_clock.json \
--bg-targets read_bg_targets.json \
--insulin-sensitivities read_insulin_sensitivies.json \
--basal-profile read_selected_basal_profile.json \
--predict-glucose-without-basal predict_glucose_without_future_basal.json
$ openaps report add set_dose.json JSON $my_pump_name deliver recommended_dose.json
Did you remember to test all of those reports (in order)? Good!
Add aliases
Aliases are a way to gather a number of openaps commands into a single,
easy-to-exute command. Instead of having to run all of the above reports
individually, you can instead make logical groupings and run them together. For
example, after adding the first alias below (refresh), you can simply run $ openaps refresh and it will execute the constituent reports in order.
Add the following aliases:
$ openaps alias add refresh "report invoke read_settings.json read_bg_targets.json read_insulin_sensitivies.json read_selected_basal_profile.json read_carb_ratios.json"
$ openaps alias add update "report invoke read_status.json read_battery_status.json read_clock.json recent_glucose.json recent_history.json"
$ openaps alias add munge "report invoke clean_glucose.json clean_history.json reconcile_history.json resolve_history.json normalize_history.json"
$ openaps alias add predict "report invoke predict_glucose.json predict_glucose_without_future_basal.json"
$ openaps alias add dose "report invoke recommended_dose.json set_dose.json"
Just like you did with the reports, go ahead and test each of these aliases to make sure the execute properly. For example,
$ openaps refresh
should return:
pump://JSON/read_settings/read_settings.json
reporting read_settings.json
pump://JSON/read_bg_targets/read_bg_targets.json
reporting read_bg_targets.json
pump://JSON/read_insulin_sensitivies/read_insulin_sensitivies.json
reporting read_insulin_sensitivies.json
pump://JSON/read_selected_basal_profile/read_selected_basal_profile.json
reporting read_selected_basal_profile.json
pump://JSON/read_carb_ratios/read_carb_ratios.json
reporting read_carb_ratios.json
This completes the setup of the openaps.ini file, which resides in your
$myopenaps directory. Go ahead and take a look using $ cat openaps.ini.
Make a new directory in your top-level directory (which is probably something
like /home/pi) called /bin.
$ cd
$ mkdir bin
$ cd bin
We will put three files in the /bin directory: one to initialize the web
server, one that power cycles the CareLink stick to make sure it continues to
run, and one that defines the loop. For each of these, make sure and replace
$myopenaps with the directory name you chose for your OpenAPS instance. I'm
assuming here that it is in /home/pi/$myopenaps, but make sure to check and
use the correct full pathname.
Set up start-web
start-web.sh
cd /home/pi/openaps-monitor
screen -d -A -S openaps -m python monitor.py /home/pi/hannemannopenaps
cd -
cd /home/pi/$myopenaps
openaps refresh
cd -
Set up fix-stick
fix-stick.sh
#!/bin/sh
echo "Power-cycling USB to fix dead Carelink stick"
sleep 0.1
echo 0 > /sys/devices/platform/bcm2708_usb/buspower
sleep 1
echo 1 > /sys/devices/platform/bcm2708_usb/buspower
sleep 2
Set up loop shell script
every-five.sh
#!/bin/bash
fuser $(python -m decocare.scan) && exit 1
cd /home/pi/$myopenaps
openaps update && \
openaps munge && \
openaps predict && \
openaps dose || (python -m decocare.stick $(python -m decocare.scan) > /dev/null && echo "Stick OK" 1>&2 || ~/fix-stick.sh 1>&2)
git push 2>&1
cd -
While still in /home/pi/bin, run:
$ chmod a+xr ./*
(I forget exactly what this does ... changed the color of the .sh files when doing ls, I believe, so it registered them or something?)
Also, do this:
$ sudo apt-get install screen
I think this is for the openaps-monitor to function properly.
Set up CRON job
This file goes in your top-level directory (again, probably /home/pi). It tells the OS when to run the scripts. In this case, it is running start-web.sh upon reboot and every-five.sh every five minutes (surprise). every-five.sh calls fix-stick.sh to make sure the CareLink stick is still ticking.
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# m h dom mon dow command
*/5 * * * * /home/pi/bin/every-five.sh > /dev/null
@reboot /home/pi/bin/start-web.sh > /dev/null
Reboot.