insulin_basal/insulin_bolus records not imported (or exported?)

[widmann]

Sorry for bothering, I'm sure the problem is on my side, but I would be grateful for any hint how and where to start debugging.

I have (more or less) successfully installed your diasend-nightscout-bridge on my Nightscout deployment on Railway by applying all commits from your cgm-remote-monitor fork to my nightscout/cgm-remote-monitor fork.

Glucose readings and carbs are successfully transmitted from Diasend to Nightscout (thus, authentication on both sides appears to work). However, basal and bolus insulin treatments are missing.

I have connected to the Diasend API with Postman and both insulin_basal and insulin_bolus records are reported (together with the glucose readings and carbs). Thus, I assume the problem is not on the Diasend side but not sure.

Presumably I have missed some Nightscout configuration detail but I have no idea where to start searching.

Thanks a lot! Best, Andreas

[burnedikt]

Great to hear that you got it working (generally)! 🎉

As for the basal rate not showing up, the way the bridge works is that it imports the basal rates (and pump settings) into a special nightscout profile called "Diasend", make sure to switch to it via nightscout's "Profile Editor":

and also that the basal rate is actually rendered:

[widmann]

Thank you for the fast response!

Yes, indeed there are data synced to the Diasend profile. I do not yet see how this integrates in the general workflow as these are temporary basals from CamAPS FX changing all the time/every day. I will continue reading to figure this out.

But I'm still missing the bolus treatments (insulin_bolus records in the Diasend API). These are supposed to be synced to Nightscout, right?

Thanks a lot for providing this and your support! Best, Andreas

[burnedikt]

Yes, indeed there are data synced to the Diasend profile. I do not yet see how this integrates in the general workflow as these are temporary basals from CamAPS FX changing all the time/every day. I will continue reading to figure this out.

Yeah, that's a bit unfortunate with CamAPS. Technically, it gives the basal rate as delayed boli but on diasend, we'll get a insulin_basal event whenever the CamAPS Loop adapts the basal rate. This means that if you look back in time in nightscout during one day, the basal rate will be correct, but looking ahead (or further back than one day), the basal information is basically useless. Nightscout only supports one basal profile which is the same for each day right now but of course, with a loop this doesn't really make sense. I am unsure if there's a better way to integrate this with nightscout, e.g. via its support for OpenAPS. This is particularly an issue if you try to generate reports from within nightscout as the basal rates will always be the ones from the current day - for each day.

But I'm still missing the bolus treatments (insulin_bolus records in the Diasend API). These are supposed to be synced to Nightscout, right?

Yes, bolus records are synchronized. one common issue is that the timezone is not correctly setup and the records are actually imported to nightscout but with an offset (depending on your timezone, probably one hour early). However, if the CGM values are fine, then this is probably not the issue.

By the way, if you are in Europe/Berlin timezone, but didn't set it using the TZ environment variable, then nightscout will assume the events to be in UTC timezone, which means any CGM value or bolus happening right now, will show up in one hour on nightscout). This can be fixed by setting the TZ environment variable correctly. If you receive CGM data on the nightscout side but the values diverge from the actual values on diasend / CamAPS Fx, it's likely a timezone offset issue.

Sometimes, boli also don't show up correctly in nightscout and are instead detected (wrongly) as a carb correction due to the nature of the data received (see #18) - but in that case, you should at least see a carb correction event.

[widmann]

This means that if you look back in time in nightscout during one day, the basal rate will be correct, but looking ahead (or further back than one day), the basal information is basically useless.

Ah, thanks for the explanation!

I am unsure if there's a better way to integrate this with nightscout, e.g. via its support for OpenAPS.

So far I have used NightscoutLoader. Here, the temporary basals from Diasend are imported as "Temp Basal" records into Nightscout. For example:

{
  "_id": {
    "$oid": "638cf9b92c7b473670c4178c"
  },
  "eventType": "Temp Basal",
  "duration": 12,
  "absolute": 0.2,
  "enteredBy": "Nightscout Loader:166:12",
  "created_at": "2022-12-04T19:10:00.000Z"
}

Would this possibly be an option?

Sometimes, boli also don't show up correctly in nightscout and are instead detected (wrongly) as a carb correction due to the nature of the data received (see https://github.com/burnedikt/diasend-nightscout-bridge/issues/18) - but in that case, you should at least see a carb correction event.

Yes, I do see carb corrections (and had already set TZ to Europe/Berlin). So this is indeed presumably related to issue #18. If I can help resolving this issue by some testing or debugging I would be happy to contribute.

Thanks a lot for looking into this! Best, Andreas

[burnedikt]

So far I have used NightscoutLoader. Here, the temporary basals from Diasend are imported as "Temp Basal" records into Nightscout

The only challenge I see with that is that diasend does not know / report the duration of "insulin_basal" events if I remember correctly. So we could only send them to nightscout on the next change of the basal rate (I.e. after the temp basal rate change has ended). This would make it historically more useful but in real time very much unreliable. You basically wouldn't see whether the loop is "doing something" until that "something" has ended. So historically correct but in real time very much incorrect.

Personally I don't care so much about the historical data as I am fine with the diasend reporting if needed, so I put more focus on having data available as fast as possible.

But I can also understand others that care more about the historical part on nightscout.

If you have a smart idea how we can get both historically correct and near real-time data, very much open to it.

[widmann]

If you have a smart idea how we can get both historically correct and near real-time data, very much open to it.

Not sure how complex it would be to implement but my pragmatic (rather than smart) approach would be:

• As long as no new basal_insulin message is received typically we have to rely on the assumption that the last one is still valid.
• Can existing entries be modified? If yes: In case no new basal_insulin record is received with the latest data update the duration field of the last received record is extended until the update timestamp. In case a new basal_insulin record is contained in the latest data update the duration field of the previous is known and can be finalized and the new record becomes the current one which is then again continuously extended every refresh.

Would that possibly work? Would it be complex to implement? Best, Andreas

[burnedikt]

Can existing entries be modified?

I honestly don't know, will have to check. If it's modifyable, then your proposed solution might be a good way forward (also for converting carb corrections to insulin boli as in #18 ). The other thing I am not sure of is that even if records can be modified later on, whether the nightscout site will pick up the changes automatically (or whether you have to reload the page manually).

[burnedikt]

Updating existing treatments is not an operation supported by nightscout, sadly:

Which would mean the treatments would always need to be deleted and re-created if they are to be updated. However, I tried deleting a formerly created temp basal treatment from nightscout and noticed that the UI would not fully reflect the changes (unless you do a full page reload).

Also, I noticed that a "Temp basal" treatment will not be visualized on nightscout unless it has a duration. Also, it seems like you can clear an existing temp basal treatment (even if it has a duration that will last for the next two hours) by adding an empty temp basal treatment. This will basically end the ongoing temp basal. This would probably be good enough as we'd start a temp basal with a duration of e.g. 20 minutes whenever we receive the event from diasend, if then during those 20 minutes, the basal rate changes again according to diasend, we'll just send another temp basal treatment to nightscout. If nothing changes during the 20 minutes, we "prolong" the temp basal by adding another Temp Basal treatment with 20 minutes runtime. Sounds feasible.

Not sure if reporting will correctly pick this up as the durations given for the temp basal records are not necessarily correct since the temp basal can be cancelled earlier but I guess this can anyways happen always (manually cancelling a temp basal) so I would hope that reporting can deal with it.

[burnedikt]

Not sure if reporting will correctly pick this up as the durations given for the temp basal records are not necessarily correct since the temp basal can be cancelled earlier but I guess this can anyways happen always (manually cancelling a temp basal) so I would hope that reporting can deal with it.

Actually, just checked the reports feature for treatments and it definitely adjusts the duration of the temp basal treatment if you cancel it early.

So seems like temp basal treatments is indeed the better way to go about this instead of overwriting the nightscout profile!

[widmann]

Thanks a lot for looking into this! This sounds promising! I would be happy to contribute for example by testing (unfortunately I do not have any JavaScript or TypeScript programming skills).

One minor suggestion: I see that modification is not possible. Would it be possibly feasible to delete the old record and recreate it with the final duration once it is known? This will not change presentation of the data in Nightscout but might improve longer term data consistency also for tools where we do not know whether new entries will properly override older ones if durations overlap.

Thank you! Best, Andreas

[burnedikt]

Version 1.0.0 now imports insulin_basal records from diasend as Temp Basal treatments into nightscout, resulting in a properly distinguishable basal rate and a automatically adjusted temporary basal rate.

Would be more than happy to get some feedback on how it works out.

[burnedikt]

to be completely transparent, I did not get around to implement the suggestion about deleting the old record and updating it with a duration.

One minor suggestion: I see that modification is not possible. Would it be possibly feasible to delete the old record and recreate it with the final duration once it is known? This will not change presentation of the data in Nightscout but might improve longer term data consistency also for tools where we do not know whether new entries will properly override older ones if durations overlap.

I briefly looked into it but it would likely require some more processing of the events (and potentially keeping an in-memory list of the last known basal events or querying the API to update the duration). Also, at least in my case, diasend gives me up to three insulin_basal records for the same time but with different values. The code would need to be able to cope with that, too.

Not saying, it's not doable, just that there's a bunch of edge cases to deal with. Personally, I want to first see this increment at work before investing more time.

[widmann]

This appears to work nicely! So far no problems or unexpected behavior. Great, thanks a lot!

Still no bolus treatments but you didn't touch that part of the code (#18), right? Andreas

[burnedikt]

Great to hear it works out for you as well. I actually quite prefer this new implementation to the previous one. Thanks for the inspiration 🙏

As for the non-detected bolus, let's follow up on #18.

[MiGerth]

Thanks a lot to you for sharing that implementation. It works really great. Setting it up was very easy, with your documentation. Now temp basal is visible in Nightscout. In my case the duration of a temp basal rate is very short. After a few minutes the temp basal goes back to normal basal rate profile values. But CAM APS is still in automode. Do you have an idea, what I can change? Best regards, Michael

[widmann]

I can confirm this issue. Happens if the temporary basal rate is unchanged for longer than the default 20 mins. Here, actually only happens if temp basal is suspended/0. There is a short increase at least every hour to keep cannula free. Thus, a default duration of 60 mins should avoid the problem. Not sure whether there might be side effects of increasing default duration.

Thanks! Best, Andreas

[burnedikt]

Sounds reasonable to set the default duration to 60 mins. I just checked my data and noticed it changes at least every 20 mins but happy to change it!

[burnedikt]

60 mins duration implemented in https://github.com/burnedikt/diasend-nightscout-bridge/releases/tag/v1.0.1