search

nightscout / AndroidAPS

Opensource automated insulin delivery system (closed loop)
https://wiki.aaps.app
GNU Affero General Public License v3.0
725 stars 1.77k forks source link

AAPS 2.8.2 not connecting to Orangelink on Samsung a20e #474

Open OpossumGit opened 3 years ago

OpossumGit commented 3 years ago

I received new OrangeLink today. Connected to it and it worked fine. Later I tried to connect again but connection is not getting established now:

RileyLink Status on MEDTRONIC page remanins in

RileyLink initialization...

state

interesting part of log files:

00:11:01.471 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():58]: pool-18-thread-1[693]Entering poll at t==1736617, timeout is 0 mDataQueue size is 0 00:11:01.473 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():70]: Got data [null] at t==1736621 00:11:01.475 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpy.writeToDataRaw():204]: writeToData (raw=[03 06 10 1A]) 00:11:01.479 [pool-18-thread-1] E/PUMPBTCOMM: [RileyLinkBLE.writeCharacteristic_blocking():509]: BT Device not supported 00:11:01.482 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToDataRaw():209]: BLE Write operation failed, code=0 00:11:01.484 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToData():226]: writeToData: No response from RileyLink 00:11:01.586 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():58]: pool-18-thread-1[693]Entering poll at t==1736734, timeout is 0 mDataQueue size is 0 00:11:01.588 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():70]: Got data [null] at t==1736736 00:11:01.591 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpy.writeToDataRaw():204]: writeToData (raw=[03 06 11 13]) 00:11:01.595 [pool-18-thread-1] E/PUMPBTCOMM: [RileyLinkBLE.writeCharacteristic_blocking():509]: BT Device not supported 00:11:01.597 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToDataRaw():209]: BLE Write operation failed, code=0 00:11:01.599 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToData():226]: writeToData: No response from RileyLink 00:11:01.702 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():58]: pool-18-thread-1[693]Entering poll at t==1736849, timeout is 0 mDataQueue size is 0 00:11:01.705 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpyReader.poll():70]: Got data [null] at t==1736852 00:11:01.707 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpy.writeToDataRaw():204]: writeToData (raw=[02 0B 00]) 00:11:01.711 [pool-18-thread-1] E/PUMPBTCOMM: [RileyLinkBLE.writeCharacteristic_blocking():509]: BT Device not supported 00:11:01.713 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToDataRaw():209]: BLE Write operation failed, code=0 00:11:01.714 [pool-18-thread-1] E/PUMPBTCOMM: [RFSpy.writeToData():226]: writeToData: No response from RileyLink 00:11:01.717 [pool-18-thread-1] D/PUMPBTCOMM: [RFSpy.setMedtronicEncoding():372]: Set Encoding for Medtronic: FourByteSixByteLocal 00:11:01.719 [pool-18-thread-1] D/PUMPBTCOMM: [ServiceTaskExecutor.afterExecute():50]: Finishing task ResetRileyLinkConfigurationTask

I found that RileyLinkBLE.writeCharacteristic_blocking():509 log means that bluetoothConnectionGatt.getService(serviceUUID) == null

why is that happening?

one more interesting thing is that i have installed nRF Connect app to this phone and this app does not connect ot Orange too. Its logs say: Error 133 (0x85): GATT ERROR

OpossumGit commented 3 years ago

After million of attempts I got connected with one trick: paired phone with some unrelated device - speakers. It probably touched something in Bluetooth stack and enabled connections to OrangeLink again (while clearing of cache and data of system Bluetooth app was not helping). Now I am getting following problem: AAPS keeps restarting while communicating with Medtronic 722. That reminds me that it crashed earlier too, which is probable reason why Bluetooth stack was left in blocked state. So I'll have to change the issue to "why AAPS keeps crashing", but it is 6AM in the morning so I'll collect logs later.

OpossumGit commented 3 years ago

update: I can connect to OrangeLink by performing:

  1. delete OL from AAPS
  2. take batteries from OL
  3. reboot phone
  4. put batteries back
  5. connect to OL in AAPS

but then, when AAPS starts pulling pump history AAPS crashes and restarts and crashes again..

log indicates there are BLE issues:

07:37:59.099 [Thread-22] W/PUMPBTCOMM: [RileyLinkCommunicationManager.sendAndListen():88]: isDeviceReachable. Response is invalid ! [noResponseFromRileyLink=[true, false, false, false, false], interrupted={}, timeout={}, unknownCommand={}, invalidParam={}]
07:37:59.102 [Thread-22] E/PUMPCOMM: [MedtronicCommunicationManager.getPumpHistory():418]: Problem acknowledging frame response. (retry=[2])
07:37:59.105 [Thread-22] E/PUMPCOMM: [MedtronicCommunicationManager.getPumpHistory():425]: We couldn't acknowledge frame from pump, aborting operation.
07:37:59.108 [Thread-22] W/PUMPCOMM: [MedtronicCommunicationManager.getPumpHistory():393]: Expected frame number [13, 12], received {} (retrying)
07:37:59.111 [Thread-22] I/PUMPBTCOMM: [RileyLinkCommunicationManager.sendAndListen():75]: Sent:A7 43 37 98 06 00
07:37:59.215 [Thread-22] D/PUMPBTCOMM: [RFSpyReader.poll():58]: Thread-22[1561]Entering poll at t==340477, timeout is 0 mDataQueue size is 0
07:37:59.218 [Thread-22] D/PUMPBTCOMM: [RFSpyReader.poll():70]: Got data [null] at t==340480
07:37:59.221 [Thread-22] D/PUMPBTCOMM: [RFSpy.writeToDataRaw():204]: writeToData (raw=[14 05 00 00 00 00 00 00 00 0F A0 00 00 00 A7 43 37 98 06 00 4B])
07:37:59.225 [Thread-22] E/PUMPBTCOMM: [RileyLinkBLE.writeCharacteristic_blocking():529]: writeCharacteristic_blocking: not configured!
07:37:59.227 [Thread-22] E/PUMPBTCOMM: [RFSpy.writeToDataRaw():209]: BLE Write operation failed, code=5
07:37:59.230 [Thread-22] E/PUMPBTCOMM: [RFSpy.writeToData():226]: writeToData: No response from RileyLink
OpossumGit commented 3 years ago

And, found this too... Seems like real candidate, probably not related to BT then, will open new issue:

07:37:19.231 [Thread-23] D/PUMP: [MedtronicHistoryData.processNewHistoryData():511]: ProcessHistoryData: 'Delivery Suspend' Processed [count=[2, [{},{}]], items={}]
07:37:19.236 [Thread-23] E/CORE: [MedtronicHistoryData.processNewHistoryData():518]: ProcessHistoryData: Error processing Suspends entries: Value 60 for secondOfMinute must be in the range [0,59]
org.joda.time.IllegalFieldValueException: Value 60 for secondOfMinute must be in the range [0,59]
    at org.joda.time.field.FieldUtils.verifyValueBounds(FieldUtils.java:277) ~[na:0.0]
    at org.joda.time.chrono.BasicChronology.getDateTimeMillis(BasicChronology.java:176) ~[na:0.0]
    at org.joda.time.chrono.GregorianChronology.getDateTimeMillis(GregorianChronology.java:44) ~[na:0.0]
    at org.joda.time.chrono.AssembledChronology.getDateTimeMillis(AssembledChronology.java:133) ~[na:0.0]
    at org.joda.time.LocalDateTime.<init>(LocalDateTime.java:511) ~[na:0.0]
    at org.joda.time.LocalDateTime.<init>(LocalDateTime.java:457) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.common.utils.DateTimeUtil.toLocalDateTime(DateTimeUtil.java:43) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.common.utils.DateTimeUtil.getATechDateDiferenceAsMinutes(DateTimeUtil.java:249) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.data.dto.TempBasalProcessDTO.getDuration(TempBasalProcessDTO.java:18) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.data.MedtronicHistoryData.processSuspends(MedtronicHistoryData.java:1119) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.data.MedtronicHistoryData.processNewHistoryData(MedtronicHistoryData.java:516) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.MedtronicPumpPlugin.readPumpHistory(MedtronicPumpPlugin.java:1136) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.MedtronicPumpPlugin.initializePump(MedtronicPumpPlugin.java:599) ~[na:0.0]
    at info.nightscout.androidaps.plugins.pump.medtronic.MedtronicPumpPlugin.getPumpStatus(MedtronicPumpPlugin.java:427) ~[na:0.0]
    at info.nightscout.androidaps.queue.commands.CommandReadStatus.execute(CommandReadStatus.kt:22) ~[na:0.0]
    at info.nightscout.androidaps.queue.QueueThread.run(QueueThread.java:139) ~[na:0.0]
andyrozman commented 3 years ago

Can you please post more logs. I need to see what is happening on initialization of RL.

OpossumGit commented 3 years ago

I have opened #476 and if you agree that it is seconds issue (and not BT issue) we may continue there.

In the meantime, here are logs I have (not a lot of components were checked so log is not so comprehensive). AndroidAPS_LOG_1618378842172.log.zip

andyrozman commented 3 years ago

It seems like your phone has some communication problems with RL/OL. Some phones are pretty problematic (Samsungs and Huaweis for example). In instructions there is recommendation NOT to pair RL with your Phone (or else detection in configuration of RL might not work), but some users have noticed that it works better for them if they actually pair RL with the Phone. So this is something you could try and see if it works better.

OpossumGit commented 3 years ago

yes, it has problems on android level (since even nRF Connect app was throwing errors too). My conclusion is that Samsung has frozen BLE after AAPS has crashed (AAPS does not crash gracefuly).

And reason for crashing in my case is #476

After five steps described above I can always connect and for example if I picked Omnipod pump (that I do not have) I am able to connect and disconnect from OrangeLink without any issues indefinite times (no pairing neccessary).

Therefore, point of this issue is that some devices (Samsung) block BLE for OL after AAPS crash.

Since that is the case, I am more interested that root cause (crashing) is fixed (or is it already fixed in dev, since I have seen a few Medtronic pump history issues being worked on)

rustymonkey commented 3 years ago

fyi, this issue was raised by several users at https://www.facebook.com/groups/AndroidAPSUsers/posts/2980284845526246 . I've been testing the Orangelink for a couple of days with mdt_hotfix_2_8_2 (from Andy Rozman's repository) on an S7. I was testing recovery from lost connections between the OL and the Pump, and between OL and the Phone (re. https://github.com/MilosKozak/AndroidAPS/issues/2121 ), and it was working great until this issue occurred.

The following steps (suggested by Franz Eckl) solved the problem for me (similar to the above but no phone restart): 1 In the pump Preferences > RileyLink Configuration, delete the OL 2 Exit AAPS 3 Power off/on the OL 4 Run AAPS and in pump Preferences > RileyLink Configuration, scan for the OL and add it.

Note:

andyrozman commented 3 years ago

mdt_hotfix_2_8_2 doesn't contain fix for OL...

rustymonkey commented 3 years ago

Been using AAPS for a month with an S7 and this issue seems to occur at least once a day, often after the phone has disconnected from the RL. Based on the reports in FB, it's not an uncommon problem: https://www.facebook.com/photo?fbid=10165663209020541&set=gm.3070659316488798 https://www.facebook.com/groups/AndroidAPSUsers/posts/3060053327549397 https://www.facebook.com/photo/?fbid=10215691550000902&set=gm.3054954914725905

I'll try switching to an old Nexus 5x and see if the results are any different--I'm hoping that you're right that it's a Samsung-specific problem.

rustymonkey commented 3 years ago

We've tested with a Nexus 5x for 7 days and the endless 'Rileylink initialization' problem has not yet occurred (using the identical settings from the S7 device), so it appears to be device-specific.

I'd still suggest raising the priority on this since makes AAPS unreliable on a significant % of android devices.

andyrozman commented 3 years ago

OL fix has been merged into dev (and beta1), so this error might be fixed. Can someone please confirm that? @OpossumGit @rustymonkey

Please test with latest 2.x release (which is 2.5). It seems that OL developer has introduced some bug into 3.2 version (latest one) and he is still working on it.

OpossumGit commented 3 years ago

@andyrozman I am reluctant on using dev/beta versions as AAPS is used by my daughter that spends a lot of time away from me (school). But I am wondering which fix is merged into dev? Currently she is running AAPS from branch you prepared for me (fix you made for pump history crashes) and I have merged bubbledevteam modifications into that code. That is still not perfect solution, reconnecting is not 100%. If I go with dev do I have this MDT fix and is OL fix the work of Bubble or is it something else? And which versions are you talking about (2.5,3.2)? OL firmware? I don’t know which is currently on my device, I updated few months ago.

OpossumGit commented 3 years ago

Found answer to FW, I see those are OL versions and it is downgradeable so I can go with 2.5 whenever I want (if I am on 3.2)

rustymonkey commented 3 years ago

@andyrozman the s7 that experienced the bug doesn't support Android 9 so I can't really verify the fix (I've updated it to PixelExperience firmware (Android 11) and will test it out with AAPS 3.0 dev / RL / MDT 554, and with an OL when my son returns from out of town).

rustymonkey commented 3 years ago

I've tested the S7 running Android 11 (Pixel Experience), and:

That's not to say that I'm not experiencing connectivity issues with 3.0, but as far as I can tell, this issue is resolved.

rustymonkey commented 2 years ago

Unfortunately, in the 3 weeks since my last comment, the RileyLink Initialization error occurred 4 times (on various 3.0 Beta builds)--it's less frequent than with 2.x, but still occurs occasionally.

As reported earlier, restarting the OL and the Phone doesn't solve the problem--to solve the problem, the OL must be removed from AAPS. i.e. 1 In the pump Preferences > RileyLink Configuration, delete the OL 2 Exit AAPS (or power down the phone) 3 Power off/on the OL 4 Run AAPS and in pump Preferences > RileyLink Configuration, scan for the OL and add it.

Note that on 2 occasions in which it occurred, the device's Wi-Fi somehow stopped working and then I rebooted the device and then noticed the RL initialization bug (because the failed basal adjustment alarm went off). Next time such a Wi-Fi disconnect occurs, I'll check to see whether it directly triggers the RL initialization bug (or if it's triggered by rebooting the device). EDIT: On the other 2 occasions in which it occurred, the phone running AAPS ran out of battery--I'll try to test whether this can consistently trigger the bug. EDIT 2: Allowing the S7 to run out of battery consistently triggers this problem.