No automatic reconnect after switching RL's

[mountrcg]

Report

• Build version:b474e72a
• App's log files:
  AndroidAPS_LOG_1599731013439.log.zip

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]

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]

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

1. Install app
2. Configure RL No automatic reconnect after switching RL's #1
3. .....
4. .....

[mountrcg]

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]

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

[bartsopers]

@mountrcg

[mountrcg]

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

[mountrcg]

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

[mountrcg]

@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]

@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]

@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]

@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.