iAPS

[TomH]

iAPS is DIY software for use as an Integrated Automated Glycemic Controller (iAGC) for use in an AID system. Think of it as the software brains that integrates data from a CGM and controls an insulin pump…ala Tandem Control IQ, Omnipod 5, etc. but much more configurable and more widely compatible with CGMs and pumps.

I’m providing this for those interested in or using iAPS because often people don’t stay current on the programs they use. I’m not taking sides on the merits or perspectives indicated below.

1. There has been quite some controversy over the last couple of months regarding iAPS use and its development. In short, it appears the primary developer made parts of the program/algorithm “hidden” from users, vice using “open source” standards, and released major/minor updates either without or little testing or validation to ensure the safety of users. Other knowledgeable/involved people became concerned, stated so on the iAPS Discord and Facebook groups, and some people’s access to the Discord group appears to have been blocked as a result.

2. The same group of knowledgeable/involved users concerned about user’s safety recommended users limit themselves to iAPS version 2.3.3 as they deemed it the last known version meeting “open source” standards AND “reasonably” tested and validated code.

3. The same group of knowledgeable/involved users re-forked (a GitHub term for version control) a version of iAPS; is implementing a standard method of design, development, testing, approval, and release of major/minor improvements; and have designated this branch as “Open-iAPS” to differentiate the efforts. The Open-iAPS group is to release the developed standards, process, and code to users in the foreseeable future; it is available currently only to a limited set of developers and testers.

iAPS, and the eventual Open-iAPS, uses the original oref algorithm with parts of OpenAPS, AAPS, FreeAPSx, as well as Loop. iAPS was developed to move the oref algorithm and the best parts of Android iAGC developments to the iPhone environment. iAPS implemented use of large portions of the open source Loop program code and liberally refers to the Loop docs and its Android program predecessors. iAPS is often described as being “BG” centric vice “carb” centric (usually citing Loop, though Loop has elements of both); this means it is more responsive to changes in BG (both up and down), vice depending on carb entries.

I’ve been on DIY Loop for two years with definite success (over 90% TIR [70-180] consistently…other’s success will vary greatly). I wanted to try iAPS for the last year, but held back because it lacked documentation and development lacked definition. Due to recent reports by a few iAPS users, and despite my reservations, this past week I decided to try iAPS (version 2.3.3). iAPS, similar to Loop, has two DIY build methods: 1) Via Xcode on a Mac (scripts are available that makes this fairly easy (see LoopandLearn.com); 2) Via the web using GitHub.com, any browser and any computer with internet access. Neither process requires programming experience or knowledge, you DO need to be able to read and follow instructions. Help is readily available via groups on the web, Facebook, and GitHub. If you want a longer “no build required” period, you need a paid Apple developer account which costs $99/year.

If there’s interest, I can post further updates of my own experience with iAPS here, along with updates on Open-iAPS as I see them. If you’re interested in iAPS, the current documents are at: What is iAPS? — iAPS 0.0.1 documentation.

[Eric]

Thanks for the summary and info @TomH!

I took a look at iAPS (when I started working on my personal Loop G7 implementation). I did not like it. But I know that’s probably because I just want to do things my way and it looked like iAPS was a little less free and easy than what I have been using.

I look forward to hearing about it from you! Thanks!

[TomH]

So I found out when using Omnipod Dash with iAPS the very first pod used begins its alert tone for a pod change…and goes off like every 10 minutes after that. Just a “tad” (50 million miles in space terms) irritating if, like me, you have a 2-hour notification of change time. It’s even more annoying if, like me, you regularly use the 8-hour grace period the Dash allows, resulting a 10 hour period of listening to the Dash alert beeps (because you can NOT turn them off by other than changing pods! While irritating to me, it caused partiuclar angst with the wife and daughter: “Are you sure that things OK?” I also found out for your first Dash pod you also don’t get the banner warning “Your pod will expire in x hours.” I finally gave up and changed the thing! It’s apparently a known bug they haven’t fixed as yet, but it’s not in the docs. I found references to it on the iAPS Facebook group. I can vouch it did not recur when swapping from my second pod to the third (just put it on)…no extra alert sounds. However, I discovered the warning banner about pod expiration is white text on a yellow background; I’m not sure who thought that was a good idea. I think it fails to comply with ADA (Disability not Diabetes), but then we’re talking about a program not certified/cleared by the FDA, so… Anyway, white on yellow makes it difficult to read, even if you have your glasses; doing it without your glasses at 6:13 am is nearly impossible! (Yes, I new it was going to go off, but really?). On a good not, the developers used the code for new Dash pod activation from Loop_Main, so its familiar if coming from Loop. However, its just a button to insert the cannula and activate, not the slider that’s in Loop_Dev.

I tried DynamicISF and DynamicCR, but suffered a self-inflicted problem, so turned it off and will have to try again. The problem: I tried using the extended bolus for fat/protein included in iAPS (the delay to start, duration, interval, and bolus factor) are all adjustable settings using a version of the Warsaw calculation method, I prefer Waltzing the Dragon’s), Anyway the extended bolus’s it set had red dots adjacent them that I didn’t understand (red is “bad” right?); ended up deleting the entries thinking I hadn’t enabled something; in fact, the colors just represent wether an entry is a bolus (dark blue), basal (light blue), or extended bolus (red)….my fault for not researching adequately. Everything might have been alright if I’d just let it go. However, there’s nothing in the current docs about the color coding, I figured it out because on review, ALL bolus’s were dark, ALL basal’s were light blue, and only the extended bolus’s were red… On thinking about it, I’d use some other color than red and would certainly document the function.

The other things I have changed: I changed the recommended bolus % from the default of 70(%) to 100; I also changed the “Max SMB Basal Minutes” and “Max USM SMB Basal Minutes”. This represents how many minutes worth of basal rate that can be delivered in a single SMB. Simplified Example: If your rate is 1U/hr, 30 would mean the Max is .5U in a single SMB). The documents recommend starting at the default (30) and increase 15 minutes at a time and then test. I’ve changed my settings multiple times and just upped both to 90.

So far, I haven’t noticed a great improvement from Loop to iAPS, though I don’t seem to have “sticky” what for me is a high (anything over 180)…this may be anecdotal as its only been 7 days. I have gone high, but it’s quickly (within 60 or so minutes?); I’ve also noted the turn/inflection can be abrupt. A couple of times I’ve manually entered corrections (like was common in Loop) that invariably have resulted in contending with a low…I’m learning, albeit slowly, to let the program do its thing.

More to follow….

[Eric]

@TomH

However, I discovered the warning banner about pod expiration is white text on a yellow background; I’m not sure who thought that was a good idea.

@TomH

It’s even more annoying if, like me, you regularly use the 8-hour grace period the Dash allows, resulting a 10 hour period of listening to the Dash alert beeps (because you can NOT turn them off by other than changing pods!

As I have mentioned before, there are a lot of reasons why I am sticking with the older version, and just making my own modifications. Many of these mods have been simply to see things easier!

Why not join me on the Dark Side?! I bet that together we can make our own version even better!

You don’t need glasses to see anything on my Loop app! Look at the size of that bolus banner!

I am still working on the G7 stuff on mine, BTW.

[TomH]

@Eric Have to admit that’s pretty good size type! AND, you had the good sense to use contrasting color type!!!

I’m waiting on the Open-iAPS release to come out and see what it offers. I have to admit to having a bit better control of BG with it rather than Loop. Dinner last night had a bit of ripple, but no significant post meal rise, but that could just be anomaly of what I had (steak, Brussels sprouts, garlic toast (sprouted multigrain sourdough…doesn’t spike me and I only dose for half the carbs). Anyway, I’m hoping for improved docs (at least some comments on current features, possibly improvements to few existing features (like colors, perhaps fixing the first pod issue, though I hopefully wont see it again.)

I’m not sure what “joining you” would mean, do you have the code only on your system, vice in GitHub?

[Eric]

@TomH

I’m not sure what “joining you” would mean, do you have the code only on your system, vice in GitHub?

Yes, it is only my computer. It is not anything “official” uploaded anywhere.

BTW, I installed iAPS last night to check it out. Lots of bells and whistles on that thing! Dynamic CF, dynamic ISF, Sigmoid Function…

Is diabetes really that complicated?

I just like simplicity and control of everything. Not a bunch of buttons, just a clean interface and the ability to change whatever I want. Like the insulin action.

[TomH]

@Eric I appreciate the sentiment regarding “simplicity.” The iAPS interface is much more complicated than I think it could/should be and could pretty easily be cleaned up for the minimalist approach while still having all the settings available for those that like to complicate the…uhhh…deal with much more! According to one post I read about the Open-iAPS effort is simplifying/clean-up may be one of their goals…we’ll see, possibly in the next couple of weeks. Most of the settings are pretty much set it and forget it; in fact, that’s the aim of Theresa Hastings, one of the folks involved. She turned up the settings on UAM SMB with the intent of, and according to LNL video success in, being all but completely hands off while eating things like cereal and other “carby” items. I’m not anywhere near that, but seemingly better than I was doing with stock Loop. All things in good time? Hope so…but the clock is running…

[Eric]

@TomH,
I think this is a significant issue. I am not sure if this is a known issue.

This is a normal build of iAPS, not anything I messed with.

The build is not brand new, but code from January. Maybe it has been fixed since then.

---

---

I put iAPS on my phone, along with mine, to compare them. My Loop is using the G6, and iAPS is using the G7.

The problem I am seeing - iAPS keeps showing a CGM number, long after I have turned off the CGM. But my version is correctly showing an empty CGM value.

Here are images with descriptions.

---

---

After 20-30 minutes…

My version:

iAPS:

---

---

After 2 hours, iAPS is still showing a CGM number!

My version:

iAPS:

[TomH]

@Eric Not sure what version that is, current version is 3.4 (I’m not sure if that’s dev or released version by the original developer, not the Open-iAPS group). I don’t recall seeing anything regarding this on FB, don’t know about Discord. Have read others posts indicating no significant problems w versions post 2.3.3 (I believe it dates to Nov ‘23), but safety is paramount. If you can confirm the version you have or GitHub #, I can pass it on.

[Eric]

@TomH

Is this what you need?

[Eric]

I guess that’s an old version.

I got it in January 2024, but was just grabbing what I could for my own dev purposes. Was not looking for the latest.

Maybe it’s already been fixed.

I wanted to share this because showing a stale CGM number seemed really dangerous.

I’ve always said that no information is better than bad information.

[glitzabetes]

Just to throw my experience in, I’ve been using iAPS for ~4 months now, generally without meal announcements at all for the majority of the time. I’m currently sitting at about 73% TIR and 6.6% est A1c. I have recently decided I’ll likely move to announcing breakfast only as this is the time of day the algorithm struggles the most for me (but I’m also quite a bit more carb sensitive in the morning and often have a VERY carby breakfast) - based on early data I expect to be more towards 80+% TIR with just this change,

I know many folks here prefer tighter control than this strategy offers which is totally understandable! For me, as someone that was diagnosed before I was really conscious, eating without thinking about the carbs at all is an extremely surreal and peace-bringing experience (:

[glitzabetes]

My version of iAPS also does this, I’ll be honest I’ve never been all that bothered by it as the algorithm doesn’t act upon stale data (even 5 minute old stale data) and it shows how old the most recent data is directly beneath, also push notifies the user if it’s failed to loop every 20 min or so. I see what you mean in terms of being potentially dangerous if the user tries to act on the stale data but it also pops up and warns you about the CGM data being stale if you try to bolus.

[TomH]

Yes, the version 2.3.3 and the “Branch: main f404fc4” are the key. That’s what I’m using too and the version recommended for newbies as open source and “last tested adequately”. Not sure how I can check for similar result without loosing the G6 except toward the end of its life (I don’t reset currently, perhaps thats how…). Either way, I’ll post to the FB group and see if anyone else has experienced similar. It’s possible it’s been fixed in later code changes, but someone will inevitably respond.

[Eric]

@TomH , it’s easy to test. Turn off the G6 or G7 app, or take off the sensor a few hours before it is due to expire.

Does iAPS show you a blank CGM value to indicate it is no longer reading the CGM, or does it keep showing the last number it was able to read (which in my case was the 106 that it kept showing!).

[Eric]

Thanks for confirming @glitzabetes!

[TomH]

I was thinking the iAPS app was listening for/polling the signal itself vice getting it from the iPhone. I just turned off the app this morning, so will test the system one way or the other, eh?! I’ll check it in 10 minutes…good test either way and will report back here and on the iAPS FB page…

[TomH]

@Eric et al…
OK, so I turned off the Dex and got the following:

1. No insulin dosing on what turned out to be rising BG
2. Warning from the Dexcom app it was disconnected, actually both that the app was closed and there was a loss of signal (I’m not sure how it does that when the app is not active, but that’s a different matter)
3. A red “loop” indication on the iAPS interface showing iAPS isn’t connected and receiving data every 5 mins
4. Multiple banner pop-up’s from iAPS stating it hass not “loop”ed that show how long its been

On reconnection, similar to your experience on the last graphic @Eric provided, I see the last reported BG number at the top, but iAPS shows the latest Dex reading in the graph, but not the intervening period BG #’s for when the Dex was shut down.

While I agree showing the last BG number at the top in green should be changed to indicate some warning (whether red vice green or an explicit statement), the red loop circle, lack of data in the graph, and multiple warnings from both the Dexcom and iAPS seem a sufficient warning to the user that there’s a problem so as not to be overly concerned. I base this on my consideration iAPS is still a work in progress, vice more developed like Loop (though I admit I’m not sure when the transition to “mature” product occurs). I also haven’t tested whether the banner notifications I received from Dex and iAPS can be affected by settings in the iPhone’s Notification Center which might prove the situation to be more concerning. All this said, I’ll still post the info to the FB group for consideration/action as developers deem appropriate. If others see considerations I’m not taking into account, please advise and I’ll adjust my wording of concern to developers appropriately.

@glitzabetes I’d be interested knowing what version of iAPS you’re using as well as your perspective on the brouhaha on iAPS development,not for arguments sake, just perspective… I appreciate your comments on “non-announcement”. Also, I’ve twice tried turning on DynISF and DynCR at .5 and .6 Adjustment Factor; both times I’ve ended up projected and going low (below 70) with target set to 100, received warnings carbs are needed both times, only to turn around quickly and go back 20-40 over target after injesting the recommended carbs. I’m thinking it’s probably my current ISF setting (presumably where iAPS starts from) is too aggressive (too low of a number, I get its an inverse relationship). Did you experience similar? Any recommendation, like not to turn them on? (My TIR is pretty good as is, but always looking to improve.)

[Eric]

This makes no sense to me. They obviously know the number is old, because they are showing the red loop. What is the purpose of still showing an old number? And in green even!

[glitzabetes]

I’m running v2.3.1 at the moment!

I’ll be honest I haven’t been keeping majorly up to date on the iAPS news/discussion as I haven’t been on FB/Discord all that much after having gotten a handle on making things work/adjusting settings. From your write-up I do feel good in that my version is among the properly done open-source versions and whenever next I update I think I may decide to use Open-iAPS depending on where everything stands then. Ultimately - when we use an experimental open-source project like iAPS we know there is not MUCH testing that has been done and we are taking a certain amount of risk in using it. I feel better about using a version where the way the code functions can be understood and vetted by multiple people.

Re: dynamic ISF/CR, I do use these and generally like them (esp with preventing sticky highs) but I have also occasionally experienced issues with it creating lows. A sharp rise at a high BG can result in quite aggressive insulin dosages with dynamic on - one of the reasons why they don’t suggest new folks start with dynamic prior to getting your settings very dialed in. I’ve also noticed that when I have a crappy sensor, dynamic can cause a lot more problems from the jumps - smooth CGM function helps this but I often find it’s better to turn off dynamic in these cases (or replace the sensor early if possible).

If you’re getting lows every time it corrects a high then you probably do want to think about weakening ISF/AF - I run with an AF of 0.5 but of course YDMV. Another option to think about adjusting is max SMB minutes or basal rate if perhaps it’s just able to give too much insulin in one go.

I also just generally find the recommended carbs to overshoot wildly how many carbs are needed so I personally take those with a huge grain of salt. Half of the recommended value is usually even quite a bit overkill for me, especially if my basal has been suspended for some time (which it usually has been when I get ‘carbs required’ notifs). Where I think this number comes from is it applying the dynamic ISF/carb ratio to the current IOB, and with dynamic on at a lower BG of course it estimates your ISF/carb ratio to make you far more insulin sensitive than you are under normal circumstances.