Skip to content

Medtrum Pump unreachable after 2 minutes #4011

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
PetrMlejnek opened this issue Jun 3, 2025 · 10 comments
Open

Medtrum Pump unreachable after 2 minutes #4011

PetrMlejnek opened this issue Jun 3, 2025 · 10 comments

Comments

@PetrMlejnek
Copy link

Medtrum pump + Android 15 + BYODA: I have a problem with Medtrum pump disconnecting from phone and cannot connect back. After phone restart the pump communicates with AAPS about 2 minutes so I can get bolus or set new profile, but after this time AAPS just cannot connect with pump anymore. If I restart the phone, I can control the pump again, but again just for about 2 minutes.

I use:
Samsung Galaxy S24 Ultra (Android 15)
BYODA 1.12.1.0 (Dexcom G6)
AAPS 3.3.3.0-dev
Build: 1590206-2025.05.30
Medtrum pump (type MD8201, FW version 1.80.83)

I tried and did not help:
AAPS - Medtrum option - Scan on connection error ON/OFF
AAPS option - BT Watchdog ON/OFF
Uninstalling and clean install of AAPS
Different AAPS builds (3.3.2.0-Tsunami_3.4.1, 3.2.0.4-AutoISF)
Play Protect ON/OFF
New Metrum pump/reservoir

What works?
Setup above, but Danai pump
Setup above, but my older phone (S23+ with Android 14)

Some other users have no problems with AAPS 3.3.3.0-dev + Medtrum + Android 15 combo, but they don't use BYODA (but xDrip for example). So maybe there is some conflict between Medtrum and BYODA on Android 15?

AndroidAPS_LOG_1748868734664.log.zip

@PetrMlejnek
Copy link
Author

Demonstration video of the behavior here: https://www.youtube.com/watch?v=pks15PPsM8c

@MilosKozak
Copy link
Contributor

@jbr7rr

@manfred-h
Copy link

manfred-h commented Jun 7, 2025

I have a very similar behaviour using AAPS version 3.3.2.0 (ba55) on my Google Pixel 8a running Android 15 (BP1A.250505.005.B1).

I'll have to change my pump system later this year, which is why I am running a test with 10 Nano Patches I paid for on my own. The problem has already killed two of the patches. I know of another user running a similar test and he has absolutely no problems on the exact same phone. The only difference is he uses Freestyle Libre2 as the CGM, while I use the BYODA app Petr is using with a Dexcom G6.

Is it possible that BYODA/Dexcom BT might cause this misbehaviour? I'll probably run a new test with a third patch tomorrow, but I'll stop BYODA and its BT connection before that. Will collect logs and post them here then.

@manfred-h
Copy link

I have a very similar behaviour using AAPS version 3.3.2.0 (ba55) on my Google Pixel 8a running Android 15 (BP1A.250505.005.B1).

I'll have to change my pump system later this year, which is why I am running a test with 10 Nano Patches I paid for on my own. The problem has already killed two of the patches. I know of another user running a similar test and he has absolutely no problems on the exact same phone. The only difference is he uses Freestyle Libre2 as the CGM, while I use the BYODA app Petr is using with a Dexcom G6.

Is it possible that BYODA/Dexcom BT might cause this misbehaviour? I'll probably run a new test with a third patch tomorrow, but I'll stop BYODA and its BT connection before that. Will collect logs and post them here then.

As described, I ran the third test today with BYODA/Dexcom G6 BT completely disabled. For this I killed the BYODA app, cleared its cache and removed all "Dexcom *" connections in BT.

After that I switched the pump driver in AAPS from AccuChek/Insight to Medtrum and activated a new patch. All this happened around 14:38 MEST as you can probably see in the logs; AAPS even showed a message that the pump date/time had been updated.

The patch could be activated, but couldn't be used for more than appr. 20 seconds. Trying to update its status on the Medtrum tab in AAPS ran into an endless loop.

I then rebooted the smartphone several times with

(a) nothing changed
(b) BT disabled
(c) BT enabled again

In all these situations the pump connected happily for another appr. 20 seconds. I also tried to emit a mini-bolus of 0.5 units, but it timed out as can be seen in one of the screenshots.

In the Medtrum tab I normally (when no connections appears possible) see as BLE Status the usual bluetooth icon with a black background, while shortly after the reboot this icon is shown with a white background.

FWIW, I ran all tests both with the Medtrum extended setting "Scan on connection error" being on an off, which did not change anything.

@PetrMlejnek: have you tried your backup pump base in the meantime? I cannot try another one as I'm on the test-run and only got one pump base.

The only thing I could try would be to use Medtrum's app "EasyPatch" if that would be able to connect with the pump base, but that might kill another patch for me (again, I paid for the 10 patches on my own, so...), so I'd appreciate, if we could get a common sense/understanding, what might be the root cause here and what can/should be checked next.

Attached you find then following logs and screenshots:

(a) AndroidAPS_LOG_1749388863051.log.zip
(b) right after activating the patch, but probably even without connection - NOTE the bluetooth icon!
(c) attempt to program a mini-bolus of 0.5 units
(d) Bolus reported an error
(e) bluetooth icon with a white background right after rebooting the phone

@jbr7rr
Copy link
Contributor

jbr7rr commented Jun 10, 2025

I see something weird in the logs, I need more information.

@PetrMlejnek , @manfred-h Would one of you be able to test with a custom build(s) with added logging? You can re-use a patch for testing if needed (out of body ofcourse), contact me on discord and I can explain how etc.

@manfred-h
Copy link

I see something weird in the logs, I need more information.

@PetrMlejnek , @manfred-h Would one of you be able to test with a custom build(s) with added logging? You can re-use a patch for testing if needed (out of body ofcourse), contact me on discord and I can explain how etc.

@jbr7rr : thanks for looking at the logs! I'll get a new pump base this week, but I'll definitely can add a patch to my pristine sources and build my own .apk, in order retain my local key. Will contact you on discord.

@PetrMlejnek
Copy link
Author

PetrMlejnek commented Jun 10, 2025

Hello @manfred-h and @jbr7rr. I tried different pump base, did not help. I also tried the "trick" with forcing BYODA to stop, did not help. Right now I am back to 3.3.2.0-dev-Tsunami_3.4.1 and Danai, because of #3984 that also starts to happen to me. Until #3984 is fixed, I will not install current dev version. After that I will be more than happy to test this issue #4011 with added logging.

@manfred-h
Copy link

Hi @PetrMlejnek, thanks for testing! Too bad to hear the different pump base did not make a change! FWIW, I switched from BYODA to xDrip+ now, but did not test with the Medtrum pump again yet.

I'll continue to get it to work (hopefully) by following what @jbr7rr suggested with his pumpcontrol app!

@PetrMlejnek
Copy link
Author

@manfred-h Thank you for your reply. My friend @Korostensky is using AAPS 3.3.3.0-dev, Samsung phone with Android 15 and xDrip+ (instead of BYODA) and have no problems with Medtrum. So the problem really could be some BYODA + Medtrum conflict.

@manfred-h
Copy link

manfred-h commented Jun 11, 2025

@PetrMlejnek Yes, as I wrote earlier I suspected that, too. But I found successful users of Medtrum, BYODA and Android 15 in the list on Discord...

I hope you didn't throw away your patches yet, as @jbr7rr wrote in some private discussion they can be reactivated for additional tests, which is where the "aaps-pumpcontrol" app comes into play. It is a second AAPS app, but only for testing other stuff, and which is installed next to your real AAPS app to continue using your working loop configuration. @jbr7rr will setup a separate branch for us which will emit more/changed logs to identify what might the real reason for the failures we see. So, I would encourage you to try that out, too. Shall I pull you into my communication channel I have with @jbr7rr on Discord?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants