***January 4th 2019***
Having used OpenAPS for nearly two and a half years, with the release of AndroidAPS v2, which incorporated the SMB features of of the oref1 algorithm with which I had become accustomed, I felt it was time to try switching over and seeing how the two compared. Please bear in mind that this is an n=1 use comparison, for a male adult user, so depending on your use case, you may find the outcomes very different.
What we’re comparing here are the v2 Master of AndroidAPS using a Roche Accuchek Spirit Combo pump and 0.6.2 Master Release of OpenAPS.
To compare the two, I’m using the same criteria as I used to compare Loop and OpenAPS:
- Form
- Function
- Interaction
So let’s make a start with those.
Form
The first and most obvious difference is shown in the picture at the start of the page. There is no rig with AndroidAPS. Everything runs from a phone, much like Loop on the iPhone.
This obviously means that there are fewer parts to charge and run and fewer things to leave behind.
There is also a watch app that makes the entire system completely usable from the watch, which can be extremely beneficial if you are unable to access your phone during the day.
One of the major differences in form with AAPS, which is similar to Loop, is the ability to see a visualisation of carbohydrate & insulin absorption, plus deviations, which is part of the Overview screen, as shown below.
With OpenAPS, while there is an “On Rig” web interface for visualisation, all interaction has to be undertaken from either the pump or via NightScout (often with the use of IFTTT).
That’s the biggest difference in “Form”.
Function
At the top level, both AndroidAPS and OpenAPS use the oref family of algorithms to make predictions and deliver insulin doses, from the 0.6.2 Master release of OpenAPS.
Both systems don’t require a network connection to operate, although setting up and using OpenAPS as an offline system is more difficult than linking xDrip and AAPS or the modified Dexcom app and AAPS.
AndroidAPS and OpenAPS do have some differences in functionality.
Autotune
AndroidAPS v2 doesn’t include Autotune as a core component of the way it works. As a result, it’s not doing the nightly reassessment of ISF, CR and Basal Rates that OpenAPS currently does, although this is envisaged for a future release. If you want to run Autotune, you need to run it independently of your AAPS system.
Profile Switch
AndroidAPS includes the ability to switch between profiles within the application itself. On most pumps it’s possible to run more than one profile. This is replicated within the app, so you can have more than one profile in NightScout, for example and choose which one you currently want to use.
This setting also includes the ability to increase or decrease your current profile by a percentage (which adjusts basal rates and ISF) and also to adjust the timing of the profile, e.g., switch it forward an hour or two if you’re going abroad for the weekend and don’t want to adjust your clock time. Both of these settings can be time-limited or run ad infinitum.
In the absence of Autotune, which adjusts basals, ISF and CR based on a regression, and can be provided with wider limits than the default to adjust within, Percentage Profile Switch gives a broad tool to make a similar type of adjustment.
Current profile written to pump
This is a significant difference between the two systems. In OpenAPS, the profile on the pump is held as the reference profile, and any changes such as Autosens and Autotune use this “Pump Profile” as the datum against which they make changes, with a maximum deviation possible.
Within AndroidAPS, when you change your in-app profile, this is written to the pump, so that any variation is from whatever is loaded in the app rather than using the pump as a reference.
Objectives
Before being able to move into Closed Loop mode, you need to complete the objectives. These are designed to help you set-up and use your loop safely and effectively, with a target of getting your basic settings set-up as optimally as possible.
Open Loop
AndroidAPS can be used with any pump as an Open Loop, unlike OpenAPS which requires a connected Medtronic pump to do so. In Open Loop mode, the system provides notifications when basal rates need adjustment.
Carbs Required alerts
OpenAPS uses Pushover to provide “Carbs required” alerts if it thinks you are going low and it can’t suspend insulin enough for the predicted drop. AndroidAPS doesn’t have this functionality.
Bolus Wizard
OpenAPS doesn’t allow you to enter full mealtime boluses from the software. This is done completely from the pump.
AndroidAPS has a built in bolus wizard that calculates how much insulin or carbs you might need and takes CoB and IOB from both Boluses and TBRs into account, as well as sensitivity adjustments. It can also be used from the watch app.
e-Carbs
e-Carbs allow you to put a block of carbs in over an extended period of time, and it will be automatically divided up over that period. It’s effectively a way to create a square wave bolus using the APS features.
Bolus over Text
This allows a bolus to be initiated via an SMS text message. This is functionality aimed squarely at caregivers.
Interaction
Interaction is broken into two pieces. Getting the system set-up and using it.
Setting up
On the PC/Mac
Setting up AndroidAPS (AAPS) with a Combo requires the AAPS software and Ruffy, which allows pump communication. If you use the DanaRS, then no additional software is required.
I’ve been building OpenAPS for a couple of years now, so I’m very familiar with how it works, which is basically to run a couple of interactive scripts on the rig you are using. You may, however, need to flash Jubilinux or build the OS onto an SD card for a Pi, both of which are slightly more daunting tasks to many. For AndroidAPS, their is a limited requirement to do anything to the phone, if you have one with Android 8.1.
The process is documented in the AAPS docs, and is fairly straightforward. It is:
- Install Android Studio
- Download the Source Code
- Build and Sign the application
- Send application to phone
I didn’t find it particularly difficult and had none of the issues with Android Studio that some people have. The walk through in the documents for building AndroidAPS was very easy to follow, but as I am using a Combo, the explanation about what is needed for Ruffy was much less clear. If you understand how to build AAPS, it should make sense, but I can understand why people have had issues.
Once I’d built the APKs, there was also the small issue that Gmail no longer allows APKs to be sent so you have to deploy using something like Dropbox or renaming files. Again, not a hardship, but I can understand how it might put some people off.
Having said that, these types of idiosyncrasies are evident in all three systems, and having to learn about this aspect of AndroidAPS is no different to having to learn about using Linux for OpenAPS or xCode for Loop.
So while building is different, I don’t think it’s either easier or harder.
On the phone
Once you have installed Ruffy on your phone and paired your Combo, which seems to have a dependency on the phone brand (it worked very easily on a Xiaomi Mi Mix 2 running LineageOS 15.1 but others have had difficulties), and installed AAPS, you’re into set-up, by way of the config builder in V2.
For comparison, this is the equivalent of running the OpenAPS install script after you have got the Edison ready, and there is still a fair bit to do.
The config builder looks like this (and this isn’t all of it):
As you can see, this check box view gives access to all of the potential settings you might want to use with AAPS. As this process leaves the user to choose what they might want, it doesn’t automatically start you off with a base install with a known and tested “good install” from which you can evolve.
The big difference between AAPS and OpenAPS is that you can select whether you use the older versions of the oref algorithms and meal assist functionality that have either been superseded or are automatically enabled in OpenAPS, on their own. You can also elect to use different sensitivity models, two of which don’t exist in OpenAPS (details here). Additionally, some hidden preferences in OpenAPS are fully visible in AAPS.
Otherwise, the options available are more or less the same as those in OpenAPS. This does open up the possibility of combinations that have not had a large amount of testing.
Once you’ve completed the config builder, that’s when AAPS can start to be used.
As mentioned previously, the objectives need to be completed before you can go closed loop, and a subsection of this is using the system in Open Loop mode, where you are offered suggestions about changes to basal rates to accommodate changes in glucose. Once you are through the objectives, you are into real world use.
Comparing the two in use…
Before we start, it’s worth a note on what my standard use of OpenAPS is:
My OpenAPS usage model
Generally, I use a model of easy bolusing and entering rough carb amounts via IFTTT on a watch when using OpenAPS. Then I leave it to get on with smoothing out the differences. I observe the current state using one of a watchface, NightScout or the inbuilt web interface that runs on the OpenAPS rig. It’s a kind of “Superbolus and go” model.
I don’t use a bolus calculator for determining bolus for carbs. Instead I let OpenAPS manage the guesswork part of any food I eat.
That’s pretty much it, and has delivered around 85% time in range using a 3.9mmol/l (70mg/dl) to 10 mmol/l (180mg/dl) range.
Day to day use
The biggest benefit for me in day-to-day use was the reduction in devices that I needed to carry around. As the pump is always connected, and the phone is also my CGM receiver, it reduced the gear I needed and also the amount of charging required. Even using the Combo, which isn’t Bluetooth efficient, it’s considerably more efficient than using Bluetooth tethering with an OpenAPS rig. The difference is around 8 hours more battery life in the phone between charges, which isn’t a bad thing.
Meal times
Given my described usage model for OpenAPS, I was used to delivering an easy bolus, pressing an IFTTT button or two on the watch and then leaving OpenAPS to get on with it, and then getting alerted by OpenAPS when it thought I was heading low.
Historically I’d used a variety of Watchfaces that displayed looping information either from the rig or from NightScout, so the watch display was also something I was useful.
As an adult male user, where I’ve really seen the difference in terms of interactions relates to bolusing and a lesser extent, to carb entry.
Initially, I didn’t have a WearOS watch, so all bolusing activity required me to take the phone out of my pocket, open it, select the insulin option in AAPS (assuming that AAPS was open on the phone), enter a dose (either select the dose window, enter a number on the keypad and hit ok or press the “easy dose buttons” to add specific amounts), select ok, then confirm the dose, and then wait for it to deliver. Compared to pressing the up arrow six times, then pressing okay, waiting for six buzzes and pressing okay again, this felt like a very long-winded way of dosing. Getting my phone out also didn’t feel particularly discrete. If you are in the process of using your phone, this can be a lot quicker.
I’m aware that I can customise the fast dose buttons on the phone interface to make this quicker, but it was the getting the phone out and unlocking it in the first place that I find the bigger nuisance.
I gave in and bought a Huawei Watch 2 in the December sales, because it has a decent battery life, and that did change the experience. Using the bolusing function from the watch is far less in your face than getting a phone out, however, it can still be more obvious than reaching to your belt and hitting pump buttons, and I have been asked questions as I did it on a couple of occasions. If, however, you wear your pump somewhere hidden, I can see a much greater benefit. The watch interface would probably benefit from the same fast dose buttons that the phone UI has.
It’s also worth noting that as an able bodied adult I don’t use the “text to bolus” functionality, but again, I can see where a caregiver would find this useful.
I ended up using AAPS in conjunction with NightScout as well, as I find the IFTTT Do-Button functionality on the watch hugely useful for carb entry and realised that I missed it with the standard AAPS set-up. I can see how this would be a useful feature request to allow local specific carb entries as watch app buttons.
Where I have basically alighted is a model where I am using the system in a very similar way to how I used OpenAPS, but using the watch as my primary interface instead of the watch and the pump buttons.
e-Carbs
Historically I’ve relied on the carb absorption model in OpenAPS with the exception of specific meals, namely curries and pizza, where I’d put in a single “late carb” entry in after 3 hours to encourage more aggressive algorithm behaviour after a couple of hours, knowing what the effects of the food are.
I tried using eCarbs to deal with this in a similar way, but I think that requires a level of tuning that is likely to be similar to the problems I had with trying to work out Loop absorption periods. As always, your Diabetes May Vary, so others may find this works quite well.
The bolus calculator
As can be seen on the earlier picture, like many other aspects of AndroidAPS, the bolus calculator carries a lot of options. In use, while it is supposed to deliver a calculated bolus suggestion, sometimes there is a gut feel that perhaps the value it is suggesting seems a little high, especially after entering carbs for a hypo, and a reduction in suggested insulin is required.
As I’ve previously mentioned, this isn’t functionality I really use, but when I did use it I had occasions where I wasn’t always confident in the output.
Lack of Autotune
They often say that you don’t miss something until it’s gone. I’d argue that this is very true, and especially true with Autotune. I had rather come to rely on it to ensure my dosing was nearly correct.
But why am I mentioning a functionality point in the interaction section? Because it has a direct impact on my interaction with the system.
On flipping to the Combo, I had forgotten one of the golden rules with pumps. They are not all the same. As a result, it’s fair to say that I initially had a few issues with getting levels right. Now with OpenAPS, this would be made easier for me by Autotune each night (I’ve adjusted mine to give it more leeway to adjust basal rates and CR following Fiasp issues). Instead, I had to estimate a percentage profile switch for a few days.
With this going on, I gave in and ran Autotune on a clean rig to try and assess what the changes really needed to be, and then I run it nightly, with a daily upload of the profile to NightScout, from where I can pull it into AndroidAPS via Profile Switch. This has proven to be the best option for me and has meant that the control system is operating efficiently. So in a way it’s added to my interactions, but allowed me to do so in a non-thinking, mechanical, way, rather than having to focus concentration time on it.
Now I’m not saying that you can’t use AAPS without Autotune and it’s worth remembering that I am an n=1 example for whom Autotune has always worked reasonably well, but I have found that the adjustments are much easier to manage and that I need to engage with the system less with Autotune operating alongside the AndroidAPS instance than without.
Having said all this, there are plans to include Autotune within AAPS, so this is an interim gap.
Reviewing the decisions made
AndroidAPS has a screen that shows you its last run and all the information about the decision its made. This is useful in the short term.
It also stores all the logs locally on the phone, and they’re easily accessible for looking back and checking if you’re not sure why something was done. The format is almost identical to that in OpenAPS, and this process is almost as easy as reviewing NightScout pills and can be done offline, when there is no access to NightScout, in the same way that you can review OpenAPS logs on a rig.
Discussion
While there are significant differences in the the form of the two systems, the underlying algorithms remain constant and therefore operate in the same way.
Bear in mind that my conclusions are n=1 and coloured with having been a long term user of a system with very little in terms of a real interface.
Setting up the system is different to OpenAPS – it’s much more akin to Loop, in that you need to do less to get the system on to a phone. However, once you’ve got it there, you are presented with the large array of options. And that can be quite daunting.
The level of personalisation that you can do on the interface is staggering. Unlike Loop, there are a lot of options available, and a lot of things you can adjust and change that affect either function or the form of the interface. I guess this is what happens when you take something that had a file and command line structure and convert it to a graphical interface. Sometimes I’m inclined to think that there are almost too many, and I wonder if it wouldn’t be a good idea to have options like the menu options of the Combo, where you can choose Regular, Advanced and Custom menu settings.
The other side to this is that with the vast range of options, it is possible to configure a set-up that isn’t perhaps as well understood as the original implementation on OpenAPS. The different Sensitivity options are an example of this.
The result is that this flexibility is both a good and a bad thing.
The lack of an additional box is a positive. I haven’t encountered any issues with the operating system on the phone shutting AAPS down (which was always a concern), so I’m confident that the development team have got the balance of this right. The other side of this is that there are also fewer devices to charge and charge lasts longer. All positives for me.
Over the time I’ve been using it, I’ve grown accustomed to using the Watch interface for pretty much everything. I think that it’s also the best way to interact with the system on a day to day basis, allowing your phone to stay in your pocket. There are certain actions that require you to use the phone, but for the most part they come about when you are doing something more in-depth, and it’s often easier to do this on the phone than logging on to a command line.
It’s also very straightforward to dig into the logs and find information if you are looking to understand what has been going on.
I’m not a fan of not having Autotune there, given that I’ve been using it for the best part of two years, however, if that isn’t something you’ve used, then I’m not sure that you’d miss it. Having said that, I personally think it’s important for using the oref1 SMB functionality.
I also miss the pushover alerts, alerting to potentially needing carbs, as these are an excellent warning of a potential low.
The other question I have is whether Autosens on AndroidAPS is doing quite the same as Autosens on OpenAPS, but that requires more testing with the upcoming Medtronic driver for AAPS.
A lot of the functionality is simply “stuff I don’t use in anger”. Text to bolus, bolus calculator, eCarbs and profile switch do things that I personally haven’t needed (other than to hack Autotune into my routine), so it seems unfair to pass a positive or negative comment on these tools.
How do AndroidAPS and OpenAPS compare?
To me, they are two sides of the same coin. Different implementations of the same algorithm. Your choice of which to choose will come down to a number of factors:
- What pump you can get your hands on;
- How you want to build a system;
- Whether you want to run the system on your phone or a rig;
- Whether being able to do everything from a watch is important to you;
- Whether you want the different functionalities of the two systems;
- How much interaction you expect to do with the system
Ultimately, they both do more or less the same thing in slightly different ways, and as a result, both are equally good choices. The question is really, “What are the most important factors for your system?”, and that’s what will drive your decision.