Omnipy v1.3 coming soon*
Development and testing is going forward now that we've pods for testing. Thanks to all our contributors on the slack channel who have been sending pods, helping with coding and documentation, providing feedback and spreading the word.
Here's what to look forward to in this (last) feature update for omnipy:
- All remaining PDM features: Pod activation, basal rate adjustments,
- Android APS: Messages, warnings, status updates from omnipy and a functional UI for PDM
- Overall connection stability improvements in all areas: Pod, Rileylink and omnipy
- An easier way to set up omnipy with raspberry pi and Android APS on your phone
*Watch out on this page for release announcement and links. For questions, updates and support join us in the omnicore-pdm slack via this (updated) invite link.
March 17th - omnipy v1.2 released
This release fixes an issue with the AAPS client incorrectly registering failed commands as succeeded. For all changes, see release notes on the wiki for more information.
Also see upgrading if you are running a previous version.
Setup documentation for omnipy
omnipy is a PDM (personal diabetes manager) emulator for the OmniPod insulin pump and it can be used to command the pump to perform various functions over a Raspberry Pi on a local network. It exposes a basic HTTP API to be utilized by APS systems, and currently integrates with Android APS via a custom fork of Android APS v2.x
This used to be a pet project, where I investigated the radio communication between the OmniPod and the PDM. Whilst still studying the OmniPod, I have decided that there was enough information available to let it execute basic commands which would make it usable in an artifical pancreas system. I've put together a prototype and integrated it into AndroidAPS for our own use, which became what it is today.
As a father of a child with Type I diabetes, I desperately needed something until there was a "proper" solution, so this piece of software became indispensible, albeit its design issues and lack of user-friendliness.
You are welcome to test it and report issues, but be aware you are doing this on your own risk and so far it has been tested by only two people. Initially tested off-body and on non-t1d volunteers, my son has been using this as a closed loop since November 2018. Since then it has evolved from a raspberry pi with a usb stick (rfcat) to raspberry pi with the RileyLink and Android APS and made gradually available for testing to the general public earlier in March 2019. It's now being tested by more and more people and core functionality has so far shown itself to be stable for a looping setup.
This was intended to be a throw-away prototype and I wanttry to keep it that way. The raspberry pi and android are redundant, as both have enough processing power to perform the operations. My focus on Omnipod related development will shift on to the OmniCore project, which will be ready for public testing by mid late March sometime after the final feature update of omnipy.
In the mean time, please do report any issues you find so they can be addressed.
It seems that the release announcement of RileyLink433 got people excited about OmniPod loopability. For clarification: RL 433 is not an absolute requirement. If you have the old RileyLink, it will still work - however in a very limited range. It's strongly suggested to change the antenna, for which purpose RileyLink also provides an antenna upgrade kit. Please see the requirements section in the wiki and Increasing Radio Range for what you can further do with your RileyLink.