AdrianLxM
commented
6 years ago Just looking at the debug output of AAPS (that's the part I did noch check yet if it behaves like Oref1): ZT can be quite short (7 to 11 values) and therefore not cover the peak BGI of a correction given shortly before.
Sorry if I'm off here - in this case I'd appreciate a short feedback to check that in AndroidAPS/dev. Thanks
Currently (in 0.6.x), oref0 uses the ZTGuardBG array to determine when to be more aggressive at correcting high BG, if it sees that it can avoid a low by zero-temping. However, I think we could safely do that more aggressively, which would help bring down stubborn highs and perhaps help with UAMs.
The logic would be simple: if minZTGuardBG is above target (starting 5m from now, which effectively means current BG is above target as well), and deviations are positive, then make sure insulinReq is high enough to bring minZTGuardBG down to target:
insulinReq = max(insulinReq, (minZTGuardBG - target) / sens )
If necessary, we can also add logic to make sure it actually sets the zero temp if administering that insuilnReq as an SMB: I suspect that will happen automatically based on the existing code, but if not we can add a check for that.
To evaluate whether this would be a safe way to dose more aggressively when needed without causing lows, I've scrubbed back through several folks' NS graphs to look for instances where minZTGuardBG > target, but that was followed by a low, and the extra insulin from this algorithm would exceed what was given by the current algorithm. I didn't find any such instances yet: the closest I came was a breakfast rise that would've been treated more aggressively, possibly resulting in a BG at or just below the low end of the target range during the pre-lunch eating soon (low temp target).
If anyone sees any scenarios where they think this behavior would be too aggressive for them over the next several days, please feel free to PM me your NS URL so I can review it. Otherwise, I think it'd be worth coding this up to test it.