[itsmojo]

Problem Description

Fixes problems noted in this Discord post for where RileyLinks were not available when switching from Omnipod to Medtronic.

https://discord.com/channels/1020905149037813862/1239983260663283712/1524109946902417469

The fundamental problem was that the code used to sync the pump view when a timed Silence Pod mode automatically reverts back to being disabled was leaving a reference which preventing the RL's from being released. This was better done by removing the callback sync method that was (incorrectly) used and updating the silence pod state in the existing podStateDidUpdate() delegate callback function.

The other reported problem was being able to get OmnipodKit in a mode where the pump view title said Omnipod DASH with the view showing RileyLink Devices that should only appear when the podType uses RileyLinks (aka it is an Eros). A potential cause for something like this occurring is having a separate OmniUICoordinator.podType variable from the truth held in OmniPumpManagerState held in OmniPumpManager. Was unable to reproduce this problem either before or after eliminating the podType variable duplicated in OmniUICoordinator, but it seemed like a safer & better way to go and it eliminates a possible cause of inconsistent state.

How to Reproduce

From a fresh start of Loop/Trio, select Add Pump -> All Omnipod Types -> Omnipod Classic and select a RileyLink. Then cancel out of the Pair view, note the RileyLink(s) listed (they can be enabled or not) and select Switch pump type. Then either do either an Add Pump for a Minimed or even an Omnipod Classic (again) and note that no RileyLink(s) will be available in the RileyLink Setup view. Even if a new RL is powered up when in this mode, it will still not be seen in the RileyLink Setup view. To recover, a restart of the OS app is needed to get any RileyLinks to appear when setting up either the Minimed or Omnipod Classic pumps. Note that this problem is independent of whether or not a RileyLink is enabled and connected.

Implementation Notes

With this PR, the RileyLinks will not be held when switching pump types away from Omnipod Classic as expected. Note that any previously connected RL's will continue to have their connected LED active when switching away from Omnipod Classic, but it doesn't prevent this RL from being listed as an available RL selection in the RileyLink Setup view for the added pump. While this behavior could be improved in a future PR to RileyLinkKit &/or OmnipodKit that automatically turns off the RL connected LED when switching pump types using RL's, this is the long standing behavior of the RL code with both MinimedKit and OmniKit.

[marionbarker]

Test Summary

The purpose of this test is to ensure no regression. Make sure that Pod Keep Alive continues to work as expected. A separate test will be performed to show this fixes the problem it is supposed to fix.

We know that the pod keep alive was not perfect before and it behaves about as well as it did.
✅ test passes for both the dev implementation (this PR) and for the cherry-pick we will apply to the loop-next-dev branch in a different PR.

Configuration 1

Apply this to Trio dev branch using OmnipodKit code from this PR with SE 2nd gen phone running iOS 18 which is connected to an actual DASH pod.
Copy the heartbeat.wav file over the blank.wav file so I can hear when silent tunes is running.

Configuration 2

Apply this to Loop next-dev branch (by applying the patch to the OmnipodKit loop-next-dev branch) on same SE phone. Configure Loop next-dev to use an rPi DASH pod simulator.
Copy the heartbeat.wav file over the blank.wav file so I can hear when silent tunes is running.

Test Cases:

To avoid RileyLink cross talk. Do the tests on these two configurations at different times.
Note that both configurations will use the nominal 3 minute heartbeat for the DASH and rPi DASH pod when PKA is disabled.

Make sure Silent Pod and Pod Keep Alive (PKA) behave nominally

• Turn on Silent Pod, set an end time, ensure it returns to nominal behavior

  • For configuration 1, enable Extended confidence beeps as an extra test for Silent Pod

• Test PKA using RileyLink, examine log file to ensure pod status happens at 2 minute intervals

• Test PKA using silent tune, examine log file to ensure pod status happesn at 2 min 40 sec intervals

Test with Configuration 1

Test on 2026-07-15.

Silent Pod Test

• Add carbs and listen to SMB start.
  • ✅ Enable Silent pod and do not hear the beep when the SMB completes.
• Set time for silence pod to end at 08:52 pm and begin a large bolus at 08:51 pm
  • ✅ No beeps heard (while silent pod because Silent Pod is still enabled
  • Bolus progress extends past 08:52 pm
  • ❓ No beep is heard at end of bolus - but that may be managed by beep pattern programmed when bolus is initiated
  • ✅ Next automated adjustment (automatic Temp Basal Rate) did beep

PKA - Silent Tune

20:55: Enable PKA using Silent Tune, lock phone and hear the heartbeat sound
21:10: Unlock the phone. The heartbeat sound stops while app is in the foreground with phone unlocked and starts again when app is in the background
21:11: Disable PKA

PKA - RileyLink Device

21:23 Connect to one of three devices

• ❓ EmaLink: It says reconnecting instead of the green connected row, but I see flashing green light on the device which means it is connected
• ✅ JPM Slim Case - the green connected row shows right away and see green light
  • tap disconnect, takes a little time then show the list of 3 devices, green light is out
• ✅ CJK 0.7 EmaLink (reflashed rileylink), got the connected row right away and see green light

21:29 configure for EmaLink and leave it on for at least 10 minutes then check the log for duration

next morning (2026-07016) - issue log from Trio - parse the log:

• ❓ we do not see the 2 minute getStatus cadence
  • IMO this is an issue where the particular Link is not staying connected (and the UI says "reconnecting" instead of "connected"; in other words, this behavior is not caused by this modification

To confirm that it is just that RileyLink (which is not reporting that it is connected), switch to JPM slim case which show a solid connection icon. Let it run for a while and issue the log.txt file again.

• ✅ The cadence when switched to a RileyLink that shows as connected is the expected 2 minutes.

Test with Configuration 2

While collecting data with Trio in the backgound for test 1, go on and build Loop next-dev on the same phone.

Need to take a break. Set up for silent tune and let both Loop (Silent Tune) and Trio (EmaLink) run in PKA mode overnight.

2026-07-16
08:00 Next morning, modify to use one of the RileyLinks not connected to the Trio instance.
Issue Loop Report and ensure the appropriate timing for getStatus calls.

• ✅ as expected, the overnight times are from the Silent Tune are are 160 sec (2 min 40 sec)
• ✅ after switching to a RileyLink, the cadence for getStatus is 2 minutes

[marionbarker]

Test Summary

The purpose of this test is to demonstrate the problem being addressed by this PR is indeed fixed.
✅ successful test

Reproduce the problem

This only needs to be done once.
On SE 2nd gen phone, disable PKA for both Trio and Loop.

On SE 3rd gen phone running Loop next-dev without the code in this PR.

• delete the pump (pump simulator)
• add All Pod Types and choose Eros
  • ❌ no devices are visible
  • ❌ disable BLE, still no devices are visible
  • ✅ quit and restart Loop - 2 devices are visible (the EmaLink, the third device, did show up following a power cycle on the device - take this Emalink out of service - does not seem to be working correctly)
  • choose one rileylink: JPM slimcase
• cancel out of Pair Pod view
  • both devices are visible (JPM Slimcase, enabled, CJK 0.7 EmaLink, disabled)

Now delete the pump and add back a Minimed

• ❌ no RileyLink devices are visible

Demonstrate the Solution

Build Loop next-dev onto the same phone using the code in this PR applied to loop-next-dev branch of OmnipodKit

Add in Minimed

• ✅ both RileyLink devices are visible
• cancel

Add All Omnipod Types

• ✅ select Eros and both RileyLink devices are visible
• select one device, cancel out of pairing the pod

Add in Minimed

• ✅ both RileyLink devices are visible
• cancel

[marionbarker]

Approve from code review and test.