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?

• Read the status of a pod
• Deliver an immediate bolus
• Cancel bolus delivery
• Set a temporary basal rate
• Cancel 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.

Can I use the PDM and omnipy at the same time?

Absolutely not. The PDM will detect the interference and will beep annoyingly until it's reset. It may also cause the pod to shut down.

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 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.

(*) Stress test for a newly initialized pod as defined below in 3 phases:

1. Wait a random duration of 1 to 3 minutes. Set temp basal with a random rate and duration, wait 1 to 10 seconds, enact a bolus of a random amount of 0.05 to 1.00 Units. Repeat until total insulin delivered >= 120 Units

2. Wait 1 minute. Set temp basal with a random rate and duration. Repeat 10 times. Deliver a random bolus of 0.05 to 0.25 Units. Go to beginning until total insulin delivered >= 160 Units

3. Wait 1 minute. Set temp basal with a random rate of 0.00 to 1.00 for a random duration. Go to beginning until pod activation time = 4800 minutes.

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.

Can I activate a deactivated/expired pod with this?

No you cannot. Once the pod shuts down, the firmware does not allow it to come back up. You can however read the status and error messages (if any) for a while even after it's 'dead'. Therefore I highly suggest to dispose of the pods, because there is a very real probability that they may infer with the operation of new pods if they are in close range.

What happens if I have two RileyLinks - will the system get confused?

Some people may have a spare RileyLink, or want to use one for live use and the other for testing purposes. This should be unproblematic. Further details:

• When the first connection request comes to omni.py, it starts looking for "a" RileyLink. It finds one, stores its mac address and connects to this RileyLink during the service lifetime. (If you restart the pi, it searches again).
• A RileyLink does not 'belong' to a pod instance and is independent. You can run several omnipy instances (ie multiple pis) with a single RileyLink, and conversely have several omnipy instances with more than one RileyLink.
• An instance of omnipy communicates only with one pod. This can be through one RileyLink or the other - it doesn't matter.
• It is OK to set up two instances of omnipy running with different pods at the same time, either using a single (shared) RileyLink, or multiple RileyLinks.

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.

I had a screamer, what happened (fault codes)..

The fault codes are in the .json files created logged for each pod and recorded in the Pi - not available in APS So far this is a best guess.....

• 49 - You walked to far away from your RL mid-comms - bad connection and the Pod gave up. [Various experiences, including Dexdan 28/3/19 12:30]. However, one experience [Dexdan 14/3/19 7pm], albeit not representative of others, that suggested this may be in some way occlusion-related (damp insulin at a less reliable (leg) site) [Loop call this insulinDeliveryCommandError="Incorrect pod state for command or error during insulin command setup"]
• 98 - A suggestion this is occlusion related but somewhat doubtful as this was a good site with no evidence of lump etc [Dexdan 8/4/19 10am] [Loop call this occlusionCheckTimeouts1="Occlusion check excess timeouts 1"]
• 106 - Occlusion - this seems credible as it was on a less reliable (leg) site [Dexdan 19/3/19 9:21] [Loop call this occlusionCheckAboveThreshold="Occlusion check above threshold"]
• 128 - Think this is related to an incorrect time-offset in the pod? [Dexdan test pod 24/3/19 plus Jeremy 20/3/19 3:03pm] [Loop call this basalUnderInfusion="Basal under infusion"]

(Note, you may also find it helpful to refer to Loop code where they have attributed meaning to the (hex values) of the fault codes. Have flagged the Loop interpretations in above. See OmniKit/Model/FaultEventCode.swift lines 15-132 - https://github.com/ps2/rileylink_ios/commit/60e323259db176dcd20e19780bf7242404d96657#diff-540fe38a8683788662db675679dd8bccR227)

OOOOPPPS, I activated with the PDM, took control in AAPS, and then the PDM communicated with the pod...

well, at this point, you just had the PDM shut down and may have lost the pod (not sure). The PDM will tell you to call Insulet, and will not respond to keys. You do not have to call them and explain you hacked your pod, they would not approve. There is a PDM reset button below the battery compartment. Press this and the PDM will come back to life.