search

AAPS-Omnipod / AndroidAPS

GNU Affero General Public License v3.0
21 stars 19 forks source link

No automatic reconnect after switching RL's #1

Open mountrcg opened 4 years ago

mountrcg commented 4 years ago

Report

I have 2 RLs. (1) 88:6B:0F:F8:97:CF (2) 88:6B:0F:F9:2E:55

Upon installing the build I connected RL(1), it would always reconnect after switching it off / on. Changed the to RL(2) and this one would require at least one Bluetooth re-enable on the phone to reconnect (RileyLink Status: RileyLink unreachable). Switched back to RL(1), which then showed the same behaviour as RL(2) just before. I reinstalled the build and reconnected RL(1), which would again show the expected behaviour of reconnecting with AAPS after a switch on/off.

mountrcg commented 4 years ago

I have tested this now several times. Only the RL that was first configured, be it via initial import or initial manual configuration will reconnect automatically. If you switch to another RL, that one will only reconnect if you restart BLE or phone. This is also the case if you reconnect the original RL via the Config Builder > Omnipod > RL Configuration > Scan.

bartsopers commented 4 years ago

@mountrcg thank you for the report. Could you please add step-by-step reproduction instructions? e.g.:

  1. Install app
  2. Configure RL #1
  3. .....
  4. .....
mountrcg commented 4 years ago
  1. I usually update the app via transering the signed apk via Android file transfer and install
  2. the previously RL#1 will still be configured as everything else
  3. hamburger menue > Config Builder > Omnipod Settings > RL Config > Scan > Choose RL#2
  4. RL#2 will be acquired and operationes resumes normally with RL#2
  5. loosing a connection with RL#2 can be simulated by switching off the RL#2
  6. RL#2 will n ot automatically reconnect after switching it on again (RileyLink unreachable in Menuw > Pod)
  7. Switching off Bluetooth and reanabling it will result in re-established connection with RL#2

using step 3 again with RL#1 will result in the same behaviour for steps 4-7

bartsopers commented 3 years ago

Can you please try on the latest omnipod_eros_dev? I did several fixes and improvements in the RL selection dialog today.

bartsopers commented 3 years ago

@mountrcg

mountrcg commented 3 years ago

My spare RLs are currently under reconstruction, will test once they are back.

mountrcg commented 3 years ago

At least I am on the current release, thanks for the heads up

mountrcg commented 3 years ago

@bartsopers yes unfortunatly the bug is still there. I got my EMAlink today and was able to test. Same behaviour in AAPS 2.8 as described previously. here a small video I made describing what is happening: http://www.diprobe.com/Filme/AAPS/index.htm

mountrcg commented 3 years ago

@bartsopers so in order to get my EMAlink to automatically reestablish connection after a RileyLink unreachable event I deinstalled AAPS completely, installed your latest dev version , imported my settings that did not include a RL as I deleted it in the configuration builder, and configured the EMAlink. Now it re-acquires connection after I had it switched off and on. Added a video of this in the link above.

I don't want to add the second RL now as this will throw up the RL connection lost issue again.

mountrcg commented 3 years ago

@bartsopers I tested a little more today. I found a quick fix for this issue. (1) do the bug initiation by connecting a second RL to AAPS so that the error appears (2) delete the riley link in the Omnipod preferences (3) save the settings under maintenance (4) restart AAPS (5) import settings (6) initiate a RL under omnipod preferences -> error will not manifest anymore

mountrcg commented 3 years ago

@bartsopers I was switching RL and EmaLink today with rel. 2.8.2.1 and observing same behavior as above. Will test on a different phone next time to rule out that it is the Uniherz Atom XL that I am using.