search

burnedikt / diasend-nightscout-bridge

Synchronize your diasend data to nightscout.
MIT License
18 stars 18 forks source link

Some Meal Boli imported as Carb Corrections #12

Closed burnedikt closed 1 year ago

burnedikt commented 1 year ago

Since #11, carb records retrieved from diasend are treated as carb corrections, if they are not preceeded by a bolus record.

The issue here is that due to the polling loop, the result set retrieved from diasend in one run might include the carbs, but not the preceeding bolus (which also would mean the previous run contained the bolus but not the carbs). In essence we then end up with a Meal bolus without carbs and a carb correction (without bolus).

One way to mitigate this would be to decouple the polling loop for CGM values from the polling loop for treatments and wait for a carb record if a bolus with programmed_meal is received.

burnedikt commented 1 year ago

The polling loop right now, only checks the glucose values. It always starts requesting data from diasend starting at the last received glucose value. Since the treatments (carbs or boli) can come after that last glucose value (but still within the api response), we might process those events doubled.

burnedikt commented 1 year ago

This is the opposite problem of #7. Either we get the bolus record for a meal but the carbs are missing in the API response or the carbs are there but the bolus is not. This can happen if the data is requested exactly between the two records (since bolus record and corresponding carbs are usually ~1 minute apart).

If the bridge would keep bolus records in some kind of queue in case no carb record has been delivered yet, it could combine that record with the next iteration. so that we don't get a Meal Bolus and a Carb Correction.

Additionally, currently we take the time of the meal bolus for the respective treatment within nightscout. And based on that time, we start querying for the next records on diasend (i.e. the next api response will start 1ms after the bolus treatment). Within those next records, we'll then again get the carb correction record and since it comes standalone (no preceeding meal bolus), it will be imported (again!) into nightscout. So an easy fix would already be to ensure the carb record is not included again in the next api response by beginning the next api response after the end of the current one (and not after the last bolus / glucose value)

burnedikt commented 1 year ago

addressed by #13