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
• Change basal schedule
• Acknowledge various pod alerts
• Activate / Deactivate a pod

What are the limitations?

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

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.

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 in the /omnipy/data directory.

Check out this list of pod fault codes.

What sets the time on the pod? How do time zones apply?

The effective timezone on the pod (insofar as it relates to basal profiles) depends on the profile type. If you're using a Nightscout profile, it takes the timezone that is defined in your Nightscout profile. If you use a local profile, it takes the timezone set on your Android device.

The pod's internal date/time is adjusted with each AAPS profile change, which omnipy then will correspondingly update the profile on the pod. (There is no manual basal schedule change function in omnipy).

If you have a Nightscout profile, the profile on the pod will not be updated unless you undertake a profile switch on AAPS, or if AAPS otherwise updates your profile.

If you have a local profile, and the time on your android device changes, this will be picked up automatically by AAPS and then Omnipy which will update the profile on your pod.