AAPS keeps rewriting pump profile after profile switch.

[scarral]

My son's phone is a Samsung Galaxy S6 with LineageOS v. 14.1 with AAPS v. 2.6.1.4, Ruffy, Accu chek Combo Pump, Dexcom G6 and xDrip+ version from the 27th October 2019. I follow with a Samsung Galaxy A3 with AndroidOS v. 8.0.0, AAPS v. 2.6.1.4 and xDrip+ version from the 27th October 2019. The AAPS settings in both phones are identical except for:

• the pump, which in my phone's case it's a virtual pump,

• my son's phone has SMS commands enabled, and

• my phone is in open loop mode, my son's in closed loop mode.

Before this issue started my Nightscout version was 0.11.2-dev (created on 11th November 2019).

Since updating Nightscout to 13.0.1 Ketchup (thanks to Atlas migration) I started having the following issues:

• When I do a profile switch AAPS rewrites the new basal profile to the pump, but it doesn't do it once, it does this over and over and over again.

• I also started having the Temporary Target resetting itself after about 5 minutes problem reported in AndroidAPS users FB group for instance by Robert Shipley on the 14th August 2020.

I believe these two problems are related. I temporarily "fixed" them by enabling "NS upload only" in my son's phone and "No upload to NS" on my phone (under Preferences - Connection settings - Advanced Settings).

Reporting bugs

• Note the precise time the problem occurred and describe the circumstances and steps that caused the problem
• Note the Build version (found in the About dialog in the app, when pressing the three dots in the upper-right corner).
• Obtain the app's log files, which can be found on the phone in /storage/emulated/0/Android/data/info.nightscout.androidaps/ See https://github.com/MilosKozak/AndroidAPS/wiki/Accessing-logfiles
• Open an issue at https://github.com/MilosKozak/AndroidAPS/issues/new

[reijoahola-nightscout]

Did I understand correctly: You have the normal AAPS in both phones and updating to the same NS database ? I think you should use NSClient in your phone ?

[scarral]

Yes, I do have AAPS in my phone as well, both access the same Nightscout website. I used NSClient for a while (mind you that was with version 1.54) but to be honest I like the UI of AAPS much better, as I find it a lot more flexible, so I stuck with it. It also alerts me when my son's AAPS is doing changes, which NSClient doesn't.

[reijoahola-nightscout]

I have a feeling that your AAPS-AAPS configuration can cause your problems. I have understood that such dual configuration is not allowed ?

[scarral]

I've had that configuration for ages, since before AAPS v. 2.0. No problems until now.

[reijoahola-nightscout]

This is a very interesting question. I am afraid that this possibility is not mentioned in the documentation and this does not belong to the intended features. Such features are dangerous because those are not tested and if work in one release can stop working in the next release. Depending on AAPS NSClient settings, AAPS resyncs from NS database or not resync. If two AAPS aplications do such together I see big possibilities for problems. One day it can work but stop working when the delays in NS server or network changes.

[reijoahola-nightscout]

When thinking about Profile switching operation and Temporary Target change operation, I must admit that the situation is about the same in those two configurations (normal AAPS -NSClient and your "dangerous" AAPS - AAPS). I cannot point what potetially more dangerous is in your configuration because with NSClient can be done the same. There are some other dangerous areas like Closed / Open Loop mode in your AAPS and a risk that your AAPS starts to send CGM data into NS but you seem already know those problems. But if you could test if the problems disappear when going back into AAPS - NSClient configuration ? It could tell something about possible root causes for your problem. That configuration change should be very easy to do.

[MilosKozak]

hard to say where is the problem. I'd start testing with standalone son's AAPS

[reijoahola-nightscout]

scarral> It also alerts me when my son's AAPS is doing changes, which NSClient doesn't.

Could you clarify in what kind of situation you use this ? What changes are done in the main-AAPS and how are your client-AAPS alertted ? Just thinking that also NSClient app should show the changes when Treatments are done in the main-AAPS ?

[scarral]

So I installed NSClient and deleted AAPS in my phone. The following test was made at around 11:00. A profile switch of 110% with 3 hour duration was set at around 10:00, so at 11:00 the profile switch had about 2 hours to go.

I set a temporary target of 95 for 20 minutes on my phone through NSClient. I will describe what happens in the following runs (when my son's sensor delivered a new BG value),

• Frist run: my son's AAPS resets the temporary target to the standard 100 and immediately sets it back to 95 for 15 minutes. My phone's NSClient follows with about half a second delay.

• Second run: the same happens, and also I see that the profile is set to 100% and immediately back to 110% but the pump profile is not rewritten.

• Subsequent runs until TT expires: The rest of the runs don't do that, TT goes on at 95, treatment info and profile are kept untouched.

Then I set another TT of 98 for 30 minutes.

• Frist run: my son's AAPS resets the temporary target to the standard 100 and immediately sets it back to 95 for 25 minutes. Also I see that the profile is set to 100% and immediately back to 110%, and the pump profile is rewritten first to 100% and then back to 110%.

• Next 3 runs: TT and profile seem untouched, but the pump profile gets rewritten twice.

• Next 2 runs: When there are 10 minutes left of the TT to run, TT does not get changed to 100 and back to 98, neither does the profile (desired behaviour)

• Last run before TT expires (when there's one minute left of the TT) the pump profile is rewritten again.

I let the TT expire, and about 15 minutes later the pump profile starts getting rewritten again (I know because I start getting SMSs again). So having a TT active does not seem to cause the pump profile being rewritten.

In some of the runs, at the same time as the TT was reset to 100, all the information about treatments was lost (IOB and COB show 0 for a second or so), then apparently reread again from NS, but this behaviour does not seem to correlate to either whether TT or profile is set to 100 and 100% and back to 98 and 110% respectively, or when the pump profile is rewritten.

So I started this test at about 11:00 and now is 11:50 and I've received SMSs with text "Basal profile in pump updated" at the following times: 11:07, 11:08, 11:12, 11:15, 11:19, 11:24, 11:32, 11:34, 11:47, 11:49. At this time I set "NS upload only" in my son's phone and "No upload to NS" in my phone. I'm going to keep it that way for the time being, but that means that I cannot set a TT or a profile switch or edit treatments from NSClient. I can do some of these things via SMS commands except:

• set a custom temporary target,

• set a profile switch with duration or time shift,

• delete carb entries.

There might be more things that cannot be done via SMS but I haven't found them or needed them yet. If I do I will update this.

[scarral]

Reijo when I have AAPS in my phone in open loop mode, every time AAPS wants to do something (set a TBR or issue an SMB) I get a notification with the suggested move. Since my phone reads the same data as my son's phone and both phones have identical settings, every time my son's AAPS does something, I get a notification with the respective suggestion in my phone.

[MilosKozak]

this issues are caused by NS. only some people are affected. no idea why solution is to set NS upload only but it will prevent control from NS client. instead of nsclient use SMS. if safer anyway

[reijoahola-nightscout]

Sandra, OK, misunderstood. It was not alarm about changes done in main-AAPS but notification from Open Loop-loop algorithm. Same feature (Open Loop and notes about needed treatments) could also implemented in NSClient. Now it is just stripped off.

[scarral]

Milos: yes I understand how SMS is safer. Adrian told me too a while ago that the problem seems to be in Nightscout, which correlates with my experience that these problems started as soon as I upgraded NS to Ketchup. I posted this as an issue here because reijoahola-nightscout suggested I do that in the FB group. The problem is that there are things that cannot be done via SMS, as I highlighted above. Would it be possible to implement them in 2.7? Thanks!

[reijoahola-nightscout]

Sandra, What about the same AAPS-NSClient configuration but the operations (Profile Switch, TT setting) done from AAPS (not NSClient). Does it then work without problems ?

[MilosKozak]

what is not possible by SMS?

[scarral]

• set a custom temporary target,

• set a profile switch with duration and/or time shift,

• delete carb entries,

• adding carb entries for the following day.

I'll be happy to extend this list as soon as I find more.

[scarral]

Reijo I don't know, but I suspect there would be the same issues, since there are plenty of people reporting the TT problem on their phones using AAPS for themselves, who are not following a child like I.

[reijoahola-nightscout]

Sandra, OK, so it has been noticed also without NSClient, just using certain AAPS - Nightscout configuration.

Is it only TT problem what others have found or also Profile Switch problem ? Is it only after Atlas migration or also with Heroku ?

I have not yet done Atlas migration and NSClient is not necessary for me, just done some testing with it. But AAPS/NSClient setting "NS upload only (disabled sync)" has been sometimes ON, sometimes OFF. There was one problem with Insight pump that could be prevented by using resync from NS but it was with 2.6.1.x releases. It seems to be fixed now in 2.7.0-rc and I could disable resync from NS but I have now tested it with both options but I have not found such problems what you have now reported.

My configuration: Galaxy S9 with Android 10 AAPS 2.6.1.4 and now 2.7.0-rc4 A-C Insight v2 Dexcom G6 with patched G6 app Nightscout 13.0.1 in Heroku

[scarral]

Reijo Adrian mentioned this problem to me sometime in February I think (which is why I hadn't updated my Nightscout website), so apparently it has nothing to do wtih Atlas.

I've only read about the TT problem in the FB group, but not about the profile switch problem. That's also why posting here was a good idea, hopefully more people will chime in?

[reijoahola-nightscout]

This problem sound equally mysterious as this https://github.com/MilosKozak/AndroidAPS/issues/2484. TebbeUbben explained it with this way "This bug occurs when a new TBR is set to override the current one and the pump logs the end event at the same second as the start event. Due to AndroidAPS not supporting two events having the same timestamp, the end event takes precedence. In 2.7.0 we add some artificial offset to end events to avoid this issue."

So that problem (before bug fix) could be prevented by using this setting "NS upload only (disablrd sync)" = ON.