Closed nlof closed 1 year ago
Just adding a screenshot an hour later with what normally my loop does (cuts off basal rate) as the BG goes down towards 70..
did you disable playprotect?
Yep, it's been off since I started running AAPS. The app is running but it frequently disconnects from the pump. The most efficient cure is to exit AAPS, it restarts on its own and reconnects immediately.
BTW, you can see from the screenshot that the app was running because the temp target line changed several times during the fixed basal rate period. I believe it just couldn't control the pump because it wasn't connected and it didn't reconnect on its own until i restarted AAPS. I see that behavior frequently when I'm awake.
It would be awesome if AAPS could restart on its own as an option after x minutes of disconnect.
stop exactly at 5 am is typical for playprotect
in logs is visible that AAPS really cannot connect to pump. this is android thing, nothing what could AAPS resolve itself
do you have bt watchdogs disabled in aaps and xdrip?
It has nothing to do with playprotect. It happens randomly througout the day, rarely at night. It happened three times in the two attached screenshots. I do have BT watchdog ENABLED jn AAPS, maybe I'll try with it off...
Xdrip doesn't use Bluetooth in this setup because I use BYODA as collector. I use xdrip just to keep a local record but it doesn't use Bluetooth.
And Bluetooth via BYODA works because I get regular BG readings throughout that time.
Plus of course play protect is turned off to begin with 🙂.
I do believe it is related to AAPS because a simple restart of AAPS immediately causes a reconnection with the pump and solves the problem. I don't need to touch Emalink at all. Also Bluetooth works during this time because BYODA keeps collecting BG's.
Even if it is not directly an AAPS problem it would be a proactive fix to add the option of AAPS rebooting if it doesn't connect with the pump (for a variable, user-specified amount of minutes). And add it as an on/off option, with the default being off, so only whomever has this kind of a problem will use it.
If this cannot be taken on as a project by someone else, I might have to teach myself programming again maybe to implement such a fix myself (I used to write programs in Basic on Commodore Vic 20.in the 1980's as a teenager 😀).
Hope it's not too complicated, it should be only an IF (pump not connected for >X time).. THEN (restart AAPS).... kind of question running constantly in the loop mechanism. Plus having that X time variable input option from the user if he turns that switch on.
A weird instance which may be related to the same thing, unclear.
I found the app screen stuck on an SMB 0.1u request at around 11:39AM. Restarted app and saw that the pump was stuck on basal rate since ~ 6:30AM. Uploading all the logs since. There was no pump unreachable warning at any time... Luckily the basal rate handled BG great anyway.
AndroidAPS._2022-10-1011-38-25.1.zip AndroidAPS._2022-10-1011-38-25.0.zip AndroidAPS._2022-10-1000-00-03.70.zip AndroidAPS._2022-10-1000-00-03.69.zip AndroidAPS._2022-10-1000-00-03.68.zip AndroidAPS._2022-10-1000-00-03.67.zip AndroidAPS._2022-10-1000-00-03.66.zip AndroidAPS._2022-10-1000-00-03.65.zip AndroidAPS._2022-10-1000-00-03.64.zip AndroidAPS._2022-10-1000-00-03.63.zip AndroidAPS._2022-10-1000-00-03.62.zip AndroidAPS._2022-10-1000-00-03.61.zip AndroidAPS._2022-10-1000-00-03.60.zip AndroidAPS._2022-10-1000-00-03.59.zip AndroidAPS._2022-10-1000-00-03.58.zip AndroidAPS._2022-10-1000-00-03.57.zip AndroidAPS._2022-10-1000-00-03.56.zip AndroidAPS._2022-10-1000-00-03.55.zip AndroidAPS._2022-10-1000-00-03.54.zip AndroidAPS._2022-10-1000-00-03.53.zip AndroidAPS._2022-10-1000-00-03.52.zip AndroidAPS._2022-10-1000-00-03.51.zip AndroidAPS._2022-10-1000-00-03.50.zip AndroidAPS._2022-10-1000-00-03.49.zip
I'll close this. I think the main problem was with unreliable BT connection with that phone (Realme 8). Since I moved to another phone this hasn't recurred significantly...
Using Omni Eros via Emalink, AAPS 3.1.0.3 (screenshot with built version), G5 BYODA. Using extensive temp target automations (probably irrelevant in this case?).
It seems that there was a period of ~ 5 hours (from ~ 5:30 to ~ 10:30) in which loop was stuck on basal rate. Before and after there were SMB's and varying rates. Normal behavior returned after AAPS restart.
During those 5 hours, at around 8 am BG reached a sudden low of 62, which seemed to correct on its own afterwards inching towards 70, but the basal rate didn't change one bit.
At around 9:30 a pump unreachable error was signaled (it's set to 30 minutes). Only around 10:30 I manually restarted AAPS which immediately fixed the issue and normal pump variability restarted.
I think that the pump was unreachable for longer extent of time during those 5 hours, which caused this behavior. It may have been intermittent or not sure why it was only signaled at 9:30. A simple reboot cured this issue as it always does.
I'm not sure this is the explanation for those 5 hours of stuck loop but I frequently get pump unreachable and the simplest cure is to exit AAPS which immediately restarts and fixes the problem with the pump reconnecting right away.
As a suggestion for a new feature, maybe an AAPS reboot if "pump unreacheable" could be incorporated in AAPS as an on off toggle option (on off box or switch)?
AndroidAPS._2022-09-0805-11-36.3.zip AndroidAPS._2022-09-0805-11-36.4.zip AndroidAPS._2022-09-0805-11-36.5.zip AndroidAPS._2022-09-0805-11-36.6.zip AndroidAPS._2022-09-0805-11-36.7.zip AndroidAPS._2022-09-0805-11-36.8.zip AndroidAPS._2022-09-0805-11-36.9.zip AndroidAPS._2022-09-0805-11-36.27.zip AndroidAPS._2022-09-0805-11-36.28.zip AndroidAPS._2022-09-0805-11-36.29.zip AndroidAPS._2022-09-0805-11-36.30.zip AndroidAPS._2022-09-0805-11-36.31.zip AndroidAPS._2022-09-0810-08-30.0.zip AndroidAPS._2022-09-0810-08-30.1.zip AndroidAPS._2022-09-0810-08-30.2.zip AndroidAPS._2022-09-0810-41-00.0.zip AndroidAPS._2022-09-0810-41-00.1.zip AndroidAPS._2022-09-0810-41-00.2.zip