-
Notifications
You must be signed in to change notification settings - Fork 47
Installing MMeowlink
As this is still a WIP, I don't have a Python package available yet. Install it as follows:
cd ~
git clone https://github.com/oskarpearson/mmeowlink.git mmeowlink-source
cd mmeowlink-source
git checkout master
sudo pip install -e .
openaps vendor add --path . mmeowlink.vendors.mmeowlink
This will create an entry like this in your openaps.ini:
[vendor "mmeowlink.vendors.mmeowlink"]
path = .
module = mmeowlink.vendors.mmeowlink
Note that you might need to delete any existing 'pump' device before running the add, so as to disassociate the pump device from CareLink.
If you already have the loop running with CareLink, you should remove the existing pump definition:
openaps device remove pump
This will remove this section from your openaps.ini:
[device "pump"]
extra = pump.ini
The parameter format is as follows:
openaps device add pump mmeowlink <radio_type> <port> <serial_number_of_pump>
For example, if you're on an Edison with the subg_rfspy firmware, with pump serial number 12345 your command would be:
openaps device add pump mmeowlink subg_rfspy /dev/ttyMFD1 12345
(See the section on udev rules, below, for an alternative to specifying "/dev/ttyMFD1".) Once run, this would appear in your openaps.ini file:
[device "pump"]
vendor = mmeowlink.vendors.mmeowlink
extra = pump.ini
The pump.ini file would contain the following:
[device "pump"]
serial = 12345
port = /dev/ttyMFD1
radio_type = subg_rfspy
For the mmcommander hardware, replace 'subg_rfspy' with 'mmcommander'
NOTE: this only applies to a TI stick that's plugged into a USB port, not a serial device. Serial devices do not appear in 'lsusb' and remain the same across boots.
Device names like "dev/ttyUSB0" are assigned by the kernel when devices are plugged in, and may differ from one boot to the next. To create more meaningful device names that are tied to the USB vendor and product ID, rather than insertion order, you can use udev rules. For example, if you create a file /etc/udev/rules.d/90-mmeowlink.rules that contains
# symlink for TI Dongle flashed with subg_rfspy firmware
ATTR{idVendor}=="1d50", ATTR{idProduct}=="8001", MODE="0664", GROUP="plugdev", SYMLINK+="mmeowlink"
then a symbolic link /dev/mmeowlink will be created whenever the TI Dongle is inserted. You can use the output of
$ lsusb
to verify the vendor and product identifiers for the devices you want to name in this way, and you can have multiple rules, for different devices, in separate files or in the same file.
##Non-US pump users If you are using a non-US pump (the serial number will contain a WW extension), then follow the procedure in this section to get the pump working.
##Run mmtune
- Run the tuner to make sure it works and to set up a frequency for the first time
openaps use pump mmtune
. It may show errors, but if it gives a frequency it's probably safe to ignore the errors.
When running mmtune if you get " Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?" You likely have the wrong port in the pump.ini
file.
[device "pump"] serial = 12345 port = /dev/ttyMFD1 radio_type = subg_rfspy
- Disconnect the TI stick
- Run,
ls -al /dev/tty*
- Reconnect the TI stick
- Run
ls -al /dev/tty*
again - Look for the difference in output between the two output
- Input the difference instead of MFD1 above, For example my port is /dev/ttyACM0
##Tuning as part of your preflight loop to get the cleanest connection every time (Optional)
- Add
echo -n \"mmtune: \" && openaps use pump mmtune
at the beginning of your preflight to runmmtune
during each preflight check.
##Adding a "wait-for-silence" alias so that multiple rigs can run simultaneously (Optional)
-
openaps alias add wait-for-silence '! bash -c "echo -n \"Listening: \"; for i in `seq 1 40`; do echo -n .; ~/mmeowlink-source/bin/mmeowlink-any-pump-comms.py --port [INSERT PORT PATH HERE WITHOUT BRACKETS] --wait-for 20 2>/dev/null | egrep -v subg | egrep No && break; done"'
. If you add this as the first command in your preflight, this will check to see if there are any other current mmeowlink communications with your pump, and step aside if there are. Users have used this to run multiple rigs simultaneously. May require adding asleep [some number]
command at the beginning of your preflight for one rig to stagger things a bit.