SMBs often fail [3.1.0.3] [DASH]

[rustymonkey]

Based on observation, it appears that after an initial SMB has been successfully given, subsequent SMBs will often fail for a few loop cycles (I think that basals are adjusting correctly though). This issue only started occurring after upgrading from 3.0.3 to 3.1.0.3 (3.0 experienced occasional disconnects from the DASH, but not multiple sequential SMB failures that often result in high BG).

I've replicated this using BOOST 3.1.0.3, with Boost disabled. In the example below, you can see a successful SMB at 5:51am, and then failed boluses at 5:06 and 6:01. My son was sleeping (no change in position).

Note: When the SMBs fail there's no notification in AAPS or a system notification.

AndroidAPS_LOG_1661768474395.zip

[Thomas-Wolff]

I can confirm the same behaviour with the Eros. The newly calculated basal rate is switched through to the pump, the SMB flashes briefly and the update of the main runs so that the SMB fails. In the Loop TAB under SMB there is then the information 'waiting for pump result'.

I have just switched to version 3.0.0.2 for testing, SMB runs cleanly.

Hardware:

Samsung Galaxy A40 Android 11 Dexcom G6 via Byoda

Greetings Thomas

[Ashley112885]

I seem to be having a similar issue and often find the Loop tab says “SMB set by pump: waiting for result” and have to manually select “run” to trigger the SMB. Omnipod Dash AAPS 3.1.0.3 (Boost) Pixel 3a Android 12 Dexcom G6 via BYOD

[rustymonkey]

2 other users on the Boost Discord channel also mentioned experiencing this problem on 3.1.x and that it might be caused by a timing issue described at #1395.

EDIT: but if it's a problem of calculations taking > 1 minute, then why would the issue occur with 3.1.x and not 3.0.x...

[rustymonkey]

Update: reverting to Boost based on AAPS 3.0.2 also resolved the failed SMBs for my son.

[Thomas-Wolff]

A small note from me, that this problem occurs on BOOST has already been described extensively here, I have carried out further tests with EatingNow and with the current master version dev-a with Dymamic ISF, the timing problem also occurs with these. I have now switched back to OpenAPS SMB, as TBR and SMBs are switched through cleanly here, no timing problems at all.

Have a nice Sunday Thomas

[rustymonkey]

Other reports of this problem on 3.1: https://discord.com/channels/942399415770050581/970651783078768680/1010447891262865529 https://discord.com/channels/942372379097698325/943074159955701770/1015368147349553192 https://discord.com/channels/942372379097698325/943074159955701770/1016331845773820024

[justmara]

here is the 100% proof that smb's are canceled BUT thats not because of long calculation, but because both basal+smb are present in result see my log: 00:47:02.033 calculation finished 00:47:02.160 pump 'performing TEMP BASAL' started

for another crazy 1m21s ruffy were crowling through Combo menu setting basal

00:48:23.970 set basal finished: Result rate: 0.18 durationInMinutes: 30 success: true enacted: true

instantly after that SMB loop started:

00:48:24.027 D/PUMPQUEUE: [CommandQueueImplementation.add():152]: Adding: CommandSMBBolus - SMB BOLUS 0,50 ед 00:48:24.127 D/PUMPQUEUE: [QueueThread.run():128]: performing SMB BOLUS 0,50 ед 00:48:24.137 D/PUMPQUEUE: [CommandSMBBolus.execute():26]: Last bolus: 1663966620000 23.09.2022 23:57:00 00:48:24.138 D/PUMPQUEUE: [CommandSMBBolus.execute():34]: SMB bolus canceled. deliverAt: 24.09.2022 00:46 00:48:24.138 D/PUMPQUEUE: [CommandSMBBolus.execute():36]: Result success: false enacted: false

but were canceled right away. because of this line. it gives SMB no more than a minute to be delivered. a minute since original calculation, not the command start. and whole that time were consumed by set basal command which is for sure not a time-critical.

the funny part is that TempBasalCommand does not have such timeout

smb-fail.log

[justmara]

looks like simplest solution would be swapping order of smb and basal commands, so smb comes first, and then basal after it

[MilosKozak]

fixed by https://github.com/nightscout/AndroidAPS/commit/baab2dad4c50ff9e3ab7d93660f2204d3c2ffcf5

[rustymonkey]

Fix confirmed: After testing for 36 hours on Boost_Test_Platform which includes this fix, all SMBs were delivered successfully.

EDIT: to clarify--the version of the code that I tested included the fix by @MilosKozak and not the one by @justmara