Frequently Asked Questions

What is omnipy?

It's a REST enabled HTTP API that allows the user to communicate with the Omnipod insulin delivery system and perform actions on it programmatically.

What can you do with omnipy?

• Reading the status of a pod
• Delivering an immediate bolus
• Cancelling bolus delivery
• Setting a temporary basal rate
• Cancelling a temporary basal rate
• Acknowledge various pod alerts
• Deactivate a pod

What are the limitations?

• You cannot activate a pod
  You need to activate a pod with the PDM as usual. Once the activation is complete and pod is attached and running, you can let omnipy take over.

• You cannot give an extended bolus
  You can set well calculated temporary basal rates as a workaround

• You cannot change the programmed basal rate
  Same workaround with the extended bolus. The basal rate remains the same throughout pod's lifetime as defined in the profile that was active on the PDM during pod activation.

Why do I need a raspberry pi, can't the phone connect directly to the RileyLink?

Yes it can, if you write the software for it.

omnipy initially was not built around RileyLink and AndroidAPS. Instead it was using a USB radio to communicate with the OmniPod. This was at a time when I was experimenting with the protocol and wasn't utilizing any artificial pancreas system. Therefore neither an android device was needed nor the RileyLink. I have then added AndroidAPS to create a proof of concept. It became useful so I switched from the USB radio to RileyLink as the USB radio implementation was unstable.

As a prototype it provides a test environment for me to carry out experiments to help my main two projects OmniCore and OmniESP where I'm working on a user-friendly artificial pancreas system, with ironically as few components and dependencies as possible.

Will this make the pods last longer?

No. Currently it's not possible to extend the lifetime of the pods beyond the built-in maximum 80 hours limit after the first activation (that is when you hear the beep whilst filling in insulin)

Will this make the pods die out early?

Unlikely. Other Omnipod related development projects (e.g. Loop on iOS) have reported facing issues that were traced to battery depletion and as a result a shorter life-span. Artificial stress testing and limited live tests with omnipy could not reproduce these issues. Having said that, there is space for improvement on the hardware radio (RileyLink) that would further reduce the battery consumption of the pods and this is still under investigation.

Will this make the pods die less or more frequently?

Unlikely. An insulin pump is a complex system with a dangerous task at hand. While all pump manufacturers aim to make their devices as safe as possible, there are many things that can still go wrong and have to be dealt with. In case of Omnipod, Insulet has (wisely) chosen to not deal with them. So instead, the pods are programmed to die at the slightest hint of a problem. Regardless if it's on your arm or sitting on the table; whether it's connected to an APS or to the PDM.

If this is incomplete and not well designed..

Why is it public?
Because our lives improved so much with this, why shouldn't others?

Why not fix it / make it better?
I find it difficult to continue in the current platform, as I am probably not proficient enough in Python. Whilst it makes writing code easier and faster, the devil in the details makes it an overall productivity-nightmare for me. Hence the reason I'm carrying out another development project with the same purpose in another platform which has progressed almost to the same point as omnipy and will support more systems with less hardware.