[3.1.0.3] - AAPS uses the 5 minute backfilled BG from Xdrip instead of current reading

[nlof]

If xdrip misses a BG due to BT connection issues, next time it connects, it backfills BG. AAPS gets the current BG for a split second, after which it receives the backfilled BG and stays with that 5 minute old BG until the next reading. I've seen that frequently because my new phone has frequent xdrip BT connection issues with my G5 transmitter, basically every 10-15 minutes... (The bad BT connectivity on the Xdrip side is a separate issue). See screenshots of 2x AAPS sequentially and Xdrip after such an event. It last occurred @ 19:31 in the attached logs. Later edit: Also opened discussion on Xdrip here: https://github.com/NightscoutFoundation/xDrip/discussions/2267

AndroidAPS.log

[andyrozman]

This is Xdrip issue not AAPS... Xdrip should Broadcast only latest data entry, not the bacfilled one... So backfills should never be sent towards AAPS...

[nlof]

Interesting. For now it impacts AAPS but I'll report it on Xdrip too... If others believe it's an Xdrip issue alone, I guess this report could be closed here. EDIT: Added Xdrip discussion here: https://github.com/NightscoutFoundation/xDrip/discussions/2267

[justmara]

Why backfills should never be sent towards AAPS? xDrip's broadcast bgentry messages still has the timestamp. So backfilled values can be correctly stored to be shown on graph, used for delta calculation, etc. If they still has the correct time marker - whats problem?

[justmara]

I've seen same behavior on nsclient, when it receives backfilled data from NS after network issues for example. On screenshot below you can see that main graph is drawn correctly to current time, all the predictions are actual, OAPS label shows '1 min ago', but the BG value is shown from 99 minutes ago.

[robertrub]

I confirm. AAPS received both values but AAPS shows the one before last and as expired..

[robertrub]

This is Xdrip issue not AAPS... Xdrip should Broadcast only latest data entry, not the bacfilled one... So backfills should never be sent towards AAPS...

Sorry Andy but I don't agree. When a BG reading is missed by BYODA or xDrip, on the next connection, all the missed data is send. This is needed to calculate precisely the deltas and stats.

I used BYODA till now and this catching up of missed BGs never caused any problems in AAPS.

[Foxy7]

I use Samsung and xdrip+ and get the same issue described above by @robertrub, the 2nd to last timestamp is used on the main screen. It resolves on the next reading but is a pain. Have only been using AAPS since April and assumed this was a glitch we all lived with. the xdrip+ tab within AAPS has the correct data, so assume it just needs to be filtered to look for the most recent value rather than the last value recieved?

[Foxy7]

I watched this happen last night, after a disconnect due to a phone software update, the phone had missed 3 readings and as I restarted it xdrip found the latest data then loaded the missing historical data oldest to newest, so the last value to hit AAPS was the one before the current sgv.

So does suggest that the xdrip sgv value either populates the "latest" file with the previous sgv or AAPS looks for the last entry in a json array, instead of the latest value.

How can we find out which one this is pls?

[ruesseldia]

I noticed that the AAPS watch face shows the correct (=latest) value when data has been backfilled. I‘ve tested this a couple of times and was able to reproduce the effect. Therefore I suppose it‘s an AAPS issue.

[dar-kod]

I use latest nightly xDrip+ and latest AAPS version. I have reported this case before in earlier versions but there was some difficulties to understand the problem. It is clear that AAPS gets all BGs from xDrip+ but it doesn't display it on the main screen in the first reading but after second reading.

In the first reading AAPS gets BG value and display very shortly for maybe 1 second but then the value before last. In some longer disconnections I have seen than not previous value is displayed but some before about maybe 20 or 30 minutes, what was even stranger to me.

I am attaching screenshots which shows what I wrote in the first paragraph.

[duncanbarnes]

The patch by @asquelt seems to have fixed it for me. It does seem to make the query slightly slower but not to a point that its worse than the situation before. Would be great to see asquelt/AndroidAPS@f036e6e as a pull request perhaps?

[nlof]

Maybe someone can also test Milos's commit? They look a lot alike...

[duncanbarnes]

Ah, I hadn't seen that, it is identical apart from formatting in which case I am essentially testing both, glad to see that's in the dev branch. The slower query is the only noticeable effect, it comes up with a grey 0.0 very briefly (0.5s ish) before showing the correct glucose reading.