Random BG/Insulin data uploaded to ns

[muthijammy]

I was able to setup railway with merged diasend ns plugin as instructed. There was 1 hr added to ns server issue when I setup TZ variable as Australia/Sydney but it worked once I set as UTC+11. It worked all good from 12pm plus to 4 pm plus. However,after this it stopped working and showing random insulin/CGM values as shown since then.

Not sure if it relates to timezones

[muthijammy]

In reality,G6 CGM shows BG in range from 6-9 pm where as ns had it all out of range.

[muthijammy]

[burnedikt]

Glad to hear you got it working on Railway. From the screenshots, I understand that the glucose values and boli displayed in nightscout are incorrect. What I am not quite sure of is, whether this is just a time offset issue (because e.g. the 7.1U / 50g bolus) is displayed at around 8:40 PM in Dexcom / CamAPS but at around 06:10 PM in nightscout - but this could also be because of entirely different dates or a similar bolus being given multiple times per day, so hard to say from the data / screenshots I see.

The good thing is, data is arriving and since the code shouldn't do random stuff (since it just forwards data from diasend to nightscout), it's likely that there's just a time offset issue. To find out whether this is a timezone issue, one starting point is to find some kind of "marker" event, i.e. a bolus or a manual blood glucose measurement and then wait until it appears on nightscout. If it takes a bunch of hours to arrive then the number of hours it was delayed by is the discrepancy in between the timezone in which the data is stored on diasend and the timezone of your nightscout installation. You can then adapt the nightscout installation accordingly, e.g. if the marker event only appears on nightscout 2 hours later (or is displayed 2 hours earlier) you'll need to adapt the TZ environment variable accordingly.

Also, you might want to take a look at the logs of your railway instance of nighscout as the bridge prints out the timespans it's looking at in each iteration (and also whether it found some data there).

[muthijammy]

Noticed 0.32U Insulin for 50g meal. It happened at 11:10 am yesterday & appeared 9:10 am today. But cant see CGM follow this pattern. May be camaps/diasend doing different thing compared to dexcom? Think dexcom bridge works only for CGM, should I try that? Details BuildDeploy

Load More sgvs:252, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:50:55.655Z Load Complete: sgvs:252, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 4 minutes ago (2023-01-02T21:47:24.000Z - 2023-01-02T21:51:02.467Z): 0 Sending 0 entries to nightscout Next run (Entries) will be in in 2 minutes... tick 2023-01-02T21:51:55.656Z Sending 0 treatments to nightscout Updating basal profile based on 2 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:252, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:52:55.659Z Load Complete: sgvs:252, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 6 minutes ago (2023-01-02T21:47:24.000Z - 2023-01-02T21:53:03.069Z): 1 Sending 1 entries to nightscout got data-received event, requesting reload Next run (Entries) will be in in 2 minutes... Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:53:55.660Z Sending 0 treatments to nightscout Updating basal profile based on 0 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:54:55.663Z Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 3 minutes ago (2023-01-02T21:52:26.000Z - 2023-01-02T21:55:03.784Z): 0 Sending 0 entries to nightscout Next run (Entries) will be in in 2 minutes... tick 2023-01-02T21:55:55.666Z Sending 0 treatments to nightscout Updating basal profile based on 0 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:56:55.668Z Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 5 minutes ago (2023-01-02T21:52:26.000Z - 2023-01-02T21:57:04.378Z): 0 Sending 0 entries to nightscout Next run (Entries) will be in in 2 minutes... tick 2023-01-02T21:57:55.669Z Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Sending 0 treatments to nightscout Updating basal profile based on 0 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:58:55.669Z Load Complete: sgvs:253, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 7 minutes ago (2023-01-02T21:52:26.000Z - 2023-01-02T21:59:05.076Z): 1 Sending 1 entries to nightscout got data-received event, requesting reload Next run (Entries) will be in in 2 minutes... Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T21:59:55.671Z Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Sending 0 treatments to nightscout Updating basal profile based on 0 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T22:00:55.672Z Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 4 minutes ago (2023-01-02T21:57:26.000Z - 2023-01-02T22:01:05.939Z): 0 Sending 0 entries to nightscout Next run (Entries) will be in in 2 minutes... tick 2023-01-02T22:01:55.674Z Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Sending 0 treatments to nightscout Updating basal profile based on 0 records got data-received event, requesting reload Scheduling 0 records for processing in next run Next run (Treatments) will be in in 2 minutes... Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins tick 2023-01-02T22:02:55.677Z Load Complete: sgvs:254, treatments:4, profiles:1 data loaded: reloading sandbox data and updating plugins Number of glucose records since 6 minutes ago (2023-01-02T21:57:26.000Z - 2023-01-02T22:03:06.496Z): 1 Sending 1 entries to nightscout got data-received event, requesting reload Next run (Entries

[burnedikt]

Noticed 0.32U Insulin for 50g meal. It happened at 11:10 am yesterday & appeared 9:10 am today. But cant see CGM follow this pattern.

From my perspective, the CGM values seem pretty similar after the 50g / 0.32 U on nightscout and within CamAPS but obviously hard to tell without seeing the next couple of hours or so after 9am on nightscout.

Either way, since both treatments (bolus, carb corrections) and entries (CGM values) are processed with the same timing information they should have the same temporal offset, I can't really see (from the developer's perspective) how the CGM values would be offset differently than the boli or carbs.

Still, since you're getting input continuously on nightscout, the bridge is doing something, so the most likely issue to me still is some related to time zones. Assuming you're always having (CGM) data at the current time in nightscout, it's safe to say, it is obtaining data from diasend and pushing it to nightscout, but if your observation is correct, it apparently projects the data into the future by ~22 hours, since the bolus actually happened at ~11am but only showed up the next day at 9am.

I did some checks with the TZ setting you are now using (UTC+11) and to me this seems odd as with this setting, the time is exactly 22 hours earlier than in Sydney. This is apparently due to some weird convention that inverts the sign for time offsets when using GMT or UTC, so UTC+11 actually means 11 hours BEHIND UTC whereas UTC-11 means 11 hours ahead of UTC. Bottom line is, if you're located in Sydney, you should either use UTC-11 or Australia/Sydney (both yield the same result) for the TZ setting.

> process.env.TZ = 'Australia/Sydney'
> dayjs('2023-01-02T22:03:06.496Z').format("YYYY-MM-DDTHH:mm:ss")
'2023-01-03T09:03:06'

> process.env.TZ = 'UTC+11'
> dayjs('2023-01-02T22:03:06.496Z').format("YYYY-MM-DDTHH:mm:ss")
'2023-01-02T11:03:06'

> process.env.TZ = 'UTC-11'
'UTC-11'
> dayjs('2023-01-02T22:03:06.496Z').format("YYYY-MM-DDTHH:mm:ss")
'2023-01-03T09:03:06'

Above you can also nicely see why you got the values of 11am of january, 2nd at 09am on january, 3rd - because with UTC+11, that's exactly what it resolves to.

May be camaps/diasend doing different thing compared to dexcom? Think dexcom bridge works only for CGM, should I try that?

Not really sure what you mean by that, sorry. Can you elaborate? CamAPS and Diasend are most certainly behaving differently than Dexcom alone as those are entirely different systems. As for the Dexcom bridge, my understanding so far was that you cannot use it if you're using CamAPS since you can't use the standard dexcom app either (but just CamAPS) - so the data never goes to dexcom clarity in the first place. But like I said, haven't tried it (Dexcom Clarity or Dexcom Bridge) and no experience with it at all.

[muthijammy]

Sorry for commenting late.

TZ as "Australia/Sydney" worked perfectly fine. Not sure I started with it but there was 1 hr DST difference causing issues with it earlier. Forced me to change to UTC+11 which worked fine for 4 hrs & then suddenly went bad. Now, "Australia/Sydney" working perfect and ideal as I dont need to change DST days. Only other change was I updated bridge code from 0.x to 1.x. All good, do happy yo close

Just curious on specific example, 2023-01-02T22:03:06.496Z is 10 Pm where as I referred to 11 AM AEST becoming 9 am due to UTC+11. I noticed Dexcom Bridge variables in ur other issue variables snapshot & assumed it worked for u with Dexcom whereas with camaps+diasend, same didnt work. Sorry for raising stupid question

[muthijammy]

One unrelated doubt related to basal sync. What should I do for below? I would want autotune and hence would want it but not sure whether action is in heroku variables or somewhere in code

Important 2 We already have a synchronization of basal profiles in place using the pump settings synchronization loop. To avoid the pump setting's basal rate to override the one provided by the diasend API, set importBasalRate: false for startPumpSettingsSynchronization.

[burnedikt]

Important 2 We already have a synchronization of basal profiles in place using the pump settings synchronization loop. To avoid the pump setting's basal rate to override the one provided by the diasend API, set importBasalRate: false for startPumpSettingsSynchronization.

By now, you can ignore this comment which was specific to any version prior to 1.0.0. It has been an issue in the past but nowadays, the basal profile stored on the pump is independent of the basal profile created by cam aps's loop which leads to temp basal changes on nightscout.

So the two things should not interfere and you don't need any extra configuration.

Thanks for pointing that out, though, so I can update the readme accordingly.

[burnedikt]

Just curious on specific example, 2023-01-02T22:03:06.496Z is 10 Pm where as I referred to 11 AM AEST becoming 9 am due to UTC+11.

2023-01-02T22:03:06.496Z means 10 PM UTC / GMT. Now, AEST is 10 hours ahead of UTC, which would make it 8 AM (of the next day). But in the past, it was not configured as AEST but as UTC+11 which means 11 hours behind of UTC, which would make the 10 PM to 9 AM on that same day.

Not sure if that helps, I am also not an expert on timezones 😕

[burnedikt]

Sorry for raising stupid question

You shouldn't! I am actually thankful for any question as it allows me to better understand how you guys are using this project.