Closed szantos closed 2 years ago
Very strange as this bug was solved . At what exact time did you calibrate (x min before or after normal BG) and at what exact time did BYODA got the usual 5 min BG ?
Hi folks, I can confirm this issue. I use last BYODA and calibrated it after 2min, they has sended last value. DexApp is calculating a value with avg of last and calibatrion value. This calculated value was send to aaps and deducted as early value with yellow triangle.
Why this function is necessary?
The problem is not the yellow triangle (it is a security function) but BYODA sending readings not respecting the "every 5 minutes" rule. This bug was solved but seems like a regression in the code.
Very strange as this bug was solved . At what exact time did you calibrate (x min before or after normal BG) and at what exact time did BYODA got the usual 5 min BG ?
Thank you for looking into it. Hope this helps:
Sadly, I'm only looking AT it and not INTO it (not capable of coding)
this is already resolved except very rare situations. resolving the rest would mean slowing down BG processing too much
@MilosKozak Does the fallback really has to be LGS with red triangle?
Any condition like:
the problem is that deltas are calculated wrong in this case which affects algorithm performace
If conditions are met, closed loop could go on, if not, LGS for 30-40 minutes only !? 🙂
Current way user has to check loop status after every calibration (can be 1-3/day) to make sure it is operating properly. If missed, LGS can go on for hours.
When doing a calibration in BYODA a new BG will be sent to AAPS close to the last one (instead of updating the last one). This causes a "BG too close" error with a red triangle and the loop falls back to LGS (low glucose suspend). The error has been there before (3.0.0.x), too, but the fallback to LGS seems to be new for me (and is very annoying). Current workaround: manually deleting the duplicated BG from BYODA tab of AAPS Proposal: detect calibration and update last BG or only yellow triangle