Data is coming from different pump

[camtech57]

Combo Pump AAPS Version 3.1.0.3 Phone KK2 mini Happens every day Switched to virtual pump and back again Restarted phone Reinstalled AAPS Did not solve issue Other people having same problem on forum.

[justmara]

I confirm, this alert appears on every app start. Pretty annoying.

[RyszardS]

Hi I have the same issue with combo pump after update to 3.1.0.3

[RyszardS]

Hi, I found in discard AAPS channel that it could be related with Google play protect, so I disable this option and I switch to virtual pump( select dana R) then I switch back to compo pump. After that loop start working again

[justmara]

@RyszardS this always starts working when you simply dismiss alert. And then in comes back after app restart.

[RyszardS]

I will leave feedback after couple of days

[cascer1]

I don't think disabling Google Play Protect is a valid solution to this problem.

EDIT: Regardless of whether or not it works.

[RyszardS]

@cascer1 You are right, there is not a solution. After one day notification appear again.

[databoy2k]

Issue applies to Virtual Pump type as well. I have to switch to a real pump and then back to Virtual.

AAPS 3.1.0.3 on a Pixel 6, Android 13

[MilosKozak]

hopefuly resolved by https://github.com/nightscout/AndroidAPS/commit/3f3cdde53bcff139515cf9cdfb9bb5dbd68a4ca2

[ThomasWiesner]

Hi there, sorry to reopen this issue, but we have the same error with combo, but AAPS version 3.0.0.1. Happens always when combo is chosen, but not with virtual pump. No loop possible at the moment. What can we do? Thank you for any help, my wife is more than desperate... Thomas

[justmara]

And I can confirm that this is not fixed. Running dev build with Combo pump and see that alert after (literally) every aaps restart.

[MilosKozak]

i need logs from latest dev

[justmara]

AndroidAPS (22).log here is log since app start sorry, im running russian locale on my kid's phone so the notification has text 'Данные поступают'. its first appear is at 17:15:48.474

17:15:48.473 [RxCachedThreadScheduler-27] D/NOTIFICATION: [NotificationStore.add():60]: Notification received: Данные поступают с другой помпы. Измените драйвер помпы, чтобы сбросить ее состояние.
17:15:48.474 [Thread-18] E/PUMP: [PumpSyncImplementation.confirmActivePump():117]: Ignoring pump history record  Allowed: 01.10.2022 09:45:26 Accu-Chek Combo dQ2a-QL7TT-TnnUQ0pGfkE Received: 1665842460000 15.10.2022 17:01:00 Accu-Chek Combo 
17:15:48.475 [RxCachedThreadScheduler-27] D/NOTIFICATION: [NotificationStore.add():60]: Notification received: Данные поступают с другой помпы. Измените драйвер помпы, чтобы сбросить ее состояние.
17:15:48.476 [Thread-18] E/PUMP: [PumpSyncImplementation.confirmActivePump():117]: Ignoring pump history record  Allowed: 01.10.2022 09:45:26 Accu-Chek Combo dQ2a-QL7TT-TnnUQ0pGfkE Received: 1665834180000 15.10.2022 14:43:00 Accu-Chek Combo 
17:15:48.477 [RxCachedThreadScheduler-27] D/NOTIFICATION: [NotificationStore.add():60]: Notification received: Данные поступают с другой помпы. Измените драйвер помпы, чтобы сбросить ее состояние.
17:15:48.482 [Thread-18] E/PUMP: [PumpSyncImplementation.confirmActivePump():117]: Ignoring pump history record  Allowed: 01.10.2022 09:45:26 Accu-Chek Combo dQ2a-QL7TT-TnnUQ0pGfkE Received: 1665834120000 15.10.2022 14:42:00 Accu-Chek Combo 

[MilosKozak]

it seems to be related to ruffy's generation of serial number (which is not real SN) i'm not Combo/ruffy user. Hard to help there is new Combo driver on the way. Hopefuly it will resolve this issue

[justmara]

Ouch, new driver? Need testers? I have spare old Combo to be used with second phone ;)

[MilosKozak]

https://github.com/dv1/AndroidAPS/tree/comboctl-dev

[databoy2k]

Let me know if this should be broken into its own issue, but the virtual pump seems to want Ruffy as well. On AAPS start I get the following: 12:16:53.238 [main] I/PUMP: [RuffyScripter.<init>():178]: No connection to ruffy. Pump control unavailable.

After starting AAPS, but if I don't change my pump from virtual to anything else, my bolus log looks like this:

12:28:19.523 [Thread-115] D/PUMP: [VirtualPumpPlugin.deliverTreatment():186]: Delivering treatment insulin: 4.0U carbs: 0.0g Success: true
Enacted: true
Comment: OK
Insulin: 4.0 U
12:28:19.526 [RxCachedThreadScheduler-20] D/NOTIFICATION: [NotificationStore.add():60]: Notification received: Data is coming from different pump. Change pump driver to reset pump state.
12:28:19.527 [Thread-115] E/PUMP: [PumpSyncImplementation.confirmActivePump():83]: Ignoring pump history record  Allowed: 10/21/22 05:25:28AM MDI eVDUFdj6SRm4-YB6QBtehX Received: 1666376890283 10/21/22 12:28:10PM MDI 
12:28:19.527 [Thread-115] D/PUMPQUEUE: [CommandQueueImplementation.bolus$lambda-10():241]: Going to store carbs
12:28:19.529 [Thread-115] D/PUMPQUEUE: [CommandBolus.execute():30]: Result success: true enacted: true
12:28:19.529 [main] D/PUMP: [BolusProgressDialog.onResume$lambda-3():130]: Running id 1666376890283. Close request id  1666376890283
12:28:19.529 [RxCachedThreadScheduler-50] D/WEAR: [DataLayerListenerServiceMobile.sendMessage():173]: sendMessage: /rx_bridge {"type":"info.nightscout.shared.weardata.EventData.BolusProgress","percent":100,"status":"Success"}
12:28:19.534 [RxCachedThreadScheduler-76] D/DATABASE: [CompatDBHelper.dbChangeDisposable$lambda-18():44]: Firing EventTreatmentChange 1666377490283

But once I've changed my pump from virtual to dash and then back again, it looks like this:

12:31:26.213 [Thread-147] D/PUMP: [VirtualPumpPlugin.deliverTreatment():186]: Delivering treatment insulin: 4.0U carbs: 0.0g Success: true
Enacted: true
Comment: OK
Insulin: 4.0 U
12:31:26.214 [Thread-147] D/PUMP: [PumpSyncImplementation.confirmActivePump():69]: Registering new pump MDI eVDUFdj6SRm4-YB6QBtehX
12:31:26.227 [RxCachedThreadScheduler-66] D/DATABASE: [CompatDBHelper.dbChangeDisposable$lambda-18():49]: Firing EventTreatmentChange 1666377075123

Seems like an issue where it only registers a new pump serial number if the pump has been reset. Maybe AAPS should register a new pump serial number on start?

[MilosKozak]

Let me know if this should be broken into its own issue, but the virtual pump seems to want Ruffy as well. On AAPS start I get the following: 12:16:53.238 [main] I/PUMP: [RuffyScripter.<init>():178]: No connection to ruffy. Pump control unavailable.

After starting AAPS, but if I don't change my pump from virtual to anything else, my bolus log looks like this:

12:28:19.523 [Thread-115] D/PUMP: [VirtualPumpPlugin.deliverTreatment():186]: Delivering treatment insulin: 4.0U carbs: 0.0g Success: true
Enacted: true
Comment: OK
Insulin: 4.0 U
12:28:19.526 [RxCachedThreadScheduler-20] D/NOTIFICATION: [NotificationStore.add():60]: Notification received: Data is coming from different pump. Change pump driver to reset pump state.
12:28:19.527 [Thread-115] E/PUMP: [PumpSyncImplementation.confirmActivePump():83]: Ignoring pump history record  Allowed: 10/21/22 05:25:28AM MDI eVDUFdj6SRm4-YB6QBtehX Received: 1666376890283 10/21/22 12:28:10PM MDI 
12:28:19.527 [Thread-115] D/PUMPQUEUE: [CommandQueueImplementation.bolus$lambda-10():241]: Going to store carbs
12:28:19.529 [Thread-115] D/PUMPQUEUE: [CommandBolus.execute():30]: Result success: true enacted: true
12:28:19.529 [main] D/PUMP: [BolusProgressDialog.onResume$lambda-3():130]: Running id 1666376890283. Close request id  1666376890283
12:28:19.529 [RxCachedThreadScheduler-50] D/WEAR: [DataLayerListenerServiceMobile.sendMessage():173]: sendMessage: /rx_bridge {"type":"info.nightscout.shared.weardata.EventData.BolusProgress","percent":100,"status":"Success"}
12:28:19.534 [RxCachedThreadScheduler-76] D/DATABASE: [CompatDBHelper.dbChangeDisposable$lambda-18():44]: Firing EventTreatmentChange 1666377490283

But once I've changed my pump from virtual to dash and then back again, it looks like this:

12:31:26.213 [Thread-147] D/PUMP: [VirtualPumpPlugin.deliverTreatment():186]: Delivering treatment insulin: 4.0U carbs: 0.0g Success: true
Enacted: true
Comment: OK
Insulin: 4.0 U
12:31:26.214 [Thread-147] D/PUMP: [PumpSyncImplementation.confirmActivePump():69]: Registering new pump MDI eVDUFdj6SRm4-YB6QBtehX
12:31:26.227 [RxCachedThreadScheduler-66] D/DATABASE: [CompatDBHelper.dbChangeDisposable$lambda-18():49]: Firing EventTreatmentChange 1666377075123

Seems like an issue where it only registers a new pump serial number if the pump has been reset. Maybe AAPS should register a new pump serial number on start?

In dev SN is ignored for VirtualPump. It should not happen anymore

[justmara]

@MilosKozak This is really a big problem. This bug makes AAPS ignore boluses from pump history

13:36:30.286 [Thread-33] D/PUMP: [RuffyScripter.runCommand():263]: Attempting to run cmd: BolusCommand{bolus=3.5}
13:36:30.287 [Thread-33] D/PUMP: [RuffyScripter.runCommand():278]: Connection ready to execute cmd BolusCommand{bolus=3.5}
...
13:36:45.015 [BolusCommand] D/PUMP: [BolusCommand.execute():170]: Delivering bolus, remaining: 3.5
...
13:37:02.176 [BolusCommand] D/PUMP: [BolusCommand.execute():192]: Stage 4: full bolus of 3.5 U was successfully delivered
...
13:37:03.256 [ReadQuickInfoCommand] D/PUMP: [ReadQuickInfoCommand.execute():62]: Fri Nov 04 13:35:00 GMT+03:00 2022: Bolus{timestamp=1667558100000 (Fri Nov 04 13:35:00 GMT+03:00 2022), amount=3.5}
...
13:37:03.959 [Thread-33] E/PUMP: [PumpSyncImplementation.confirmActivePump():83]: Ignoring pump history record  Allowed: 04.11.2022 13:36:05 Accu-Chek Combo feDCRjrNSy6Dq9Av5QAZ5t Received: 1667558100000 04.11.2022 13:35:00 Accu-Chek Combo feDCRjrNSy6Dq9Av5QAZ5t

This shows the case when Pump delivered large bolus of 3.5, for some reason it were note writen to AAPS db, and also it were ignored on import from pump history making AAPS count low IOB and keeping delivering more SMB afterwards. Thats a really dangerous problem. See more in log attached

AndroidAPS (25).log

[MilosKozak]

@justmara version tested?

[justmara]

@MilosKozak that log is from 3.1.0.3-master build. must people uses stable version, and this issue is pretty dangerous. dont you think its a reason for 3.1.0.4 bugfix release?

[olorinmaia]

Following. Testing virtual pump and this error happens daily. Changing pump type back and forth fixes it. Im using 3.1.0.3. Should i upgrade to the bugfix version (relalized there is no bugfix version of this except dev.)

[CaioBauab]

Same error at every bolus using MDI. Even changing from MDI to Virtual APS pump and changing back doesn't solve anymore the bug. I need to register using insulin button (not deliver, register only). Any news about a fix?

[marutasan]

@MilosKozak I'm getting this same error with an Accu-chek Insight pump I got today. I've had to delete the pairing with my previous Insight pump and pair a new one (the old one stopped working), and now this is happening. As @justmara said, everytime I deliver a bolus this error appears and the bolus is not being written to AAPS db, dangerous. It only knows about the basal, not boluses. As my case is a little bit different (change of pump, everything else the same), is there any other solution? Thanks!!!!

If i click the "refresh" button on the pump's screen, it tells me when was the last bolus. But the bolus doesn't show on the main screen.

For the moment I need to register insulin boluses by using the insulin button (with the "register only" option).

I attach the logs.

AndroidAPS.log

[cascer1]

This issue is resolved for me when using the dev branch and new combo driver.

[marutasan]

I cannot enter the facebook group yet, I'm waiting to get admitted. Do any of you know if my case can be solved easily? It all worked perfectly well until I had to unpair a pump and pair a new one. The message "Data is coming from a different pump" in fact it's true, but it should admit this new pump's data if I've unpaired the old one, shouldn't it? Two hypos this last night, because the algorithm doesn't have the info re what's the pump doing (boluses or TBRs...).

I couldn't find any info on the docs about this either...

Please, help...

[marutasan]

@MilosKozak , I've been able to upgrade to version 3.1.0.3 from version 3.02 and still not working. There must be some way to tell AndroidAPS that the new pump is the good one, and that it should accept it's data, but I don't know how. Still getting "Data is coming from different pump" error all the time :(

[MilosKozak]

does this appear in latest dev?

[marutasan]

Hello @MilosKozak , I've always used the main branch, I understand you want me to try with the dev branch because there are some changes related to this issue? So the Insight driver has also changed, not only the Combo one?

I've just tried, and I get the same error, I attach screenshot.

I'll go back to the main branch.

[marutasan]

@MilosKozak I finally could get into the facebook group. I saw people suggesting to switch to any other pump and then back to your pump, and it worked. I don't know how many hours I've spent with this today :-( It'd be great if this was in the documentation on the website, just a suggestion! Thanks a lot,

@marutasan

[Philoul]

@marutasan and @MilosKozak

I just tested again this evening with latest dev (3.1.0.3-dev-f) and 2 different Insight pumps on my dev config (first one with firmware v3 and second one with firmware v2...), but I could not reproduce this issue...

Test done: 1) Pair Pump 1 2) Deliver 2 manual boluses (1.00U then 0.50U) recorded correctly in database 3) UnPair Pump 1 then Pair Pump 2 4) Deliver a manual bolus (2.00U) also recorded correctly in database without any alert 5) UnPair Pump 2 then Pair again Pump 1 6) Deliver a third different manual Bolus (3.00 U), no alerts, everything worked fine

On my side everything worked fine without any alerts... It's very strange because I remember I got this issue in the past during the update of Insight driver for Room database, but it was fixed several months before the v3 release, and I never got again this issue...

[Philoul]

After my previous test, I did the same with the Insight Driver in kotlin... And I couldn't reproduce the issue. => All boluses delivered and recorded correctly in database, without alerts with Pump 1, then Pump 2 and then again with Pump 1...

[jotomo]

@justmara 1) What's your ruffy version? 2) Do you still get spurious new pump connected messages? 3) Could you test a PR with a possible fix?

[justmara]

@jotomo sorry, but we've switched to omnipods ages ago, so now can't test it