nightscout / nightscout-connect Goto Github PK

Single entry point for bridging cloud resources containing diabetes data to Nightscout.

License: GNU Affero General Public License v3.0

JavaScript 100.00%

nightscout-connect's Introduction

nightscout-connect

Nightscout's methods for synchronizing with common diabetes cloud providers. This module provides a single entry point to Nightscout for similar modules and allows managing http library and injecting dependencies from a single point.

Roadmap

Lower priority

Better UI integration, diagnostics, test connection, fix errors, manage plugin...
Generate predictable pattern eg sine for test.
run in capture mode to generate up to date test fixtures
better sidecar support
better cli support (pipe to/from anywhere: * | nightscout-connect | * , file, fixtures, csv, json, web services...

Help wanted

more vendors
better design suggestions
testing

Brief Doc

ENABLE=connect include the keyword connect in the ENABLE list.
Environment variable prefix CONNECT_:
- CONNECT_SOURCE - The name for the source of one of the supported inputs. one of nightscout, dexcomshare, etc...

How to use

For now there are two "output" devices available, internal Nightscout as a plugin, or external Nightscout as a sidecar from the commnandline. We will consider additional output targets.

From Nightscout

This is a Nightscout plugin. Enable the plugin by including the word connect in the ENABLE list. Select a data source by providing CONNECT_SOURCE. Make sure to provide the credentials needed by your data source. If they are missing, the plugin will produce a helpful error through Nightscout indicating which variables to set.

From command line

Running from the commandline for development purposes, as a sidecar, for example, use npm install and consider npm ln to place the nightscout-connect shell script in your path. Once in your path, it will offer --help for all subcommands.

$ nightscout-connect --help

nightscout-connect <cmd> [args]

Commands:
  nightscout-connect capture <dir> [hint]  Runs as a background server forever.
  nightscout-connect forever [hint]        Runs as a background server forever.
  nightscout-connect demo                  a quick demo using timers instead of
                                           I/O
  nightscout-connect completion            generate completion script

Options:
  --version  Show version number                                       [boolean]
  --help     Show help                                                 [boolean]

nightscout-connect will read the environment variables the same way as Nightscout extended variables using the prefix CONNECT_. Development use typically consists of commands like this:

../cgm-remote-monitor/node_modules/.bin/env-cmd -f ../minimed-envs/subject.env nightscout-connect capture logs

Where subject.env typically consists of something like this:

CONNECT_API_SECRET=626753d7f62f000078e8f6e2
CONNECT_NIGHTSCOUT_ENDPOINT=http://localhost:3030
CONNECT_SOURCE=minimedcarelink
CONNECT_CARELINK_USERNAME=your username
CONNECT_CARELINK_PASSWORD=your password
CONNECT_CARELINK_REGION=your region
CONNECT_COUNTRY_CODE=your country code

Input Data Sources

Nightscout

Work in progress

To sync from another Nightscout site, include CONNECT_SOURCE_ENDPOINT and CONNECT_SOURCE_API_SECRET.

CONNECT_SOURCE=nightscout
CONNECT_SOURCE_ENDPOINT=<URL>
CONNECT_SOURCE_API_SECRET=<OPTIONAL_API_SECRET>

The CONNECT_SOURCE_ENDPOINT must be a fully qualified URL and may contain a ?token=<subject> query string to specify an accessToken. The CONNECT_SOURCE_API_SECRET, if provided, will be used to create a token called nightscout-connect-reader. This information or the token provided in the query will be used to read information from Nightscout and is optional if the site is readable by default.

Select this driver by setting CONNECT_SOURCE equal to nightscout.

Dexcom Share

To synchronize from Dexcom Share use the following variables.

CONNECT_SOURCE=dexcomshare
CONNECT_SHARE_ACCOUNT_NAME=
CONNECT_SHARE_PASSWORD=

Optional, CONNECT_SHARE_REGION and CONNECT_SHARE_SERVER do the same thing, only specify one.

CONNECT_SHARE_REGION= ous or us. us is the default if nothing is provided. Selecting us sets CONNECT_SHARE_SERVER to share2.dexcom.com. Selecting ous here sets CONNECT_SHARE_SERVER to shareous1.dexcom.com.
CONNECT_SHARE_SERVER= set the server domain to use.

Glooko

Note: Experimental.

To synchronize from Glooko use the following variables.

CONNECT_SOURCE=glooko
CONNECT_GLOOKO_EMAIL=
CONNECT_GLOOKO_PASSWORD=
CONNECT_GLOOKO_TIMEZONE_OFFSET=0

By default, CONNECT_GLOOKO_SERVER is set to api.glooko.com because the default value for CONNECT_GLOOKO_ENV is default.

CONNECT_GLOOKO_ENV is the word default by defalt. Other values are eu, development, production, for api.glooko.work, and externalapi.glooko.com, respectively.
CONNECT_GLOOKO_SERVER the hostname server to use - api.glooko.com by default, or eu.api.glooko.com for EU users.
CONNECT_GLOOKO_TIMEZONE_OFFSET defines the time zone offset you are at from the UTC time zone, in hours

If both, CONNECT_GLOOKO_SERVER and CONNECT_GLOOKO_ENV are set, only CONNECT_GLOOKO_SERVER will be used.

Libre Link Up

To synchronize from Libre Link Up use the following variables.

CONNECT_SOURCE=linkup
CONNECT_LINK_UP_USERNAME=
CONNECT_LINK_UP_PASSWORD=

By default, CONNECT_LINK_UP_SERVER is set to api-eu.libreview.io because the default value for CONNECT_LINK_UP_REGION is EU. Other available values for CONNECT_LINK_UP_REGION:

US, EU, DE, FR, JP, AP, AU, AE

For folks connected to many patients, you can provide the patient ID by setting the CONNECT_LINK_UP_PATIENT_ID variable.

Minimed Carelink

To synchronize from Medtronic Minimed Carelink, set the following environment variables.

CONNECT_SOURCE=minimedcarelink
CONNECT_CARELINK_USERNAME
CONNECT_CARELINK_PASSWORD
CONNECT_CARELINK_REGION Either eu to set CONNECT_CARELINK_SERVER to carelink.minimed.eu or us to use carelink.minimed.com.

For folks using the new Many to Many feature, please provide the username of the patient to follow using CONNECT_CARELINK_PATIENT_USERNAME variable.

Tidepool

TODO

Tandem

TODO

History

Initially there was share2nightscout-bridge, then minimed-connect-to-nightscout. The request library was deprecated in February, 2020, and Nightscout needs to adapt by using currently maintained and supported dependencies. The initial goal is to help deprecate share2nightscout-bridge and use currently supported dependencies. Now there are more:

This module should be sufficient to replace share2nightscout-bridge as an initial minimum viable project. There are a few minor enhancements to help encourage migration away from share2nightscout-bridge:

Less latency: new glucose fetches will be tightly aligned to the previous glucose reading. In most cases, new glucose readings will be produced within 30 seconds.
Safe retries: There is an exponential backoff system to help prevent locking your account if the password changes. Each retry will take a much longer amount of time.
Safe community: There are now randomization behaviors to prevent tragedy of the commons from occurring. These features help spread the load to avoid accidentally overwhelming vendor servers.

nightscout-connect's People

Contributors

Stargazers

Watchers

nightscout-connect's Issues

Request failed with status code 504

Hi, Following this incident from the old repository
nightscout/minimed-connect-to-nightscout#44

I tried to change the user agent as I show here
https://github.com/nfontan/nightscout-connect/blob/main/lib/sources/minimedcarelink/index.js
Line 166

but the login errors continue (on CONSENT)

I am available to help in whatever is needed

Thanks

Connect LibreLink Time Delay

Using Nightscout v15.02. Using the following environment variables.
CONNECT_SOURCE='linkup'
CONNECT_LINK_UP_USERNAME='xxxxxxxx'
CONNECT_LINK_UP_PASSWORD='xxxxxxxx'
CONNECT_LINK_UP_REGION='US'

Glucose data points show up, but it takes 22 minutes before they show in NS.
Attached jpeg...
1-Stopped using [timoschlueter]Libre Link up and started using Connect-linkup
2- Stopped Connect-linkup and resumed [timoschlueter]Libre Link up
Note the 22 minute period of no data. This is the delay I was experiencing.

This is probably as designed... but is there a way to increase the sampling from 5 minutes to 1 minute through a CONNECT_LINK_UP_TIME_INTERVAL environment variable?

[minimed carelink] Pulling always at :00, :05, :10, .., no matter when the upload was

I'm using the nightscout-connect plugin with minimed-connect.

I recognized that the plugin pulls every 5 minutes (as expected), but instead of adapting the pulling time to the actual upload (or measurement) time of the uploader, it always uses :00, :05, :10, :15, ... minutes. Therefore, if the regular measurement and upload takes at, e.g., :01, the data is 4 minutes old before being downloaded at :05 by the nightscout-connect plugin.

Is there a way to determine the upload-time (or measurement time-stamp) from minimed carelink and adapt the pulling schedule of the plugin?

Best,
Trenar

Can't seem to get dexcom share to work with dexcom.jp account

I've tried using CONNECT_SHARE_SERVER to share.dexcom.jp and shareous1.dexcom.com with the dexcom.jp credentials but it doesn't seem to connect.

Wrong time of SG on Nightscout with minimedcarelink source

Hello,

I've started using nightscout with nightscout-connect plugin using docker. I've configured everything and no matter what combination of timezones I'm setting, I get always shifted data. It looks like mesurements time from CareLink is in local time but is treated like UTC time. Below more information:

docker-compose.yaml:

nightscout:
    image: nightscout/cgm-remote-monitor:latest_dev
    container_name: nightscout
    environment:
      TZ: Europe/Warsaw
      TIME_FORMAT: 24
      MONGO_CONNECTION: mongodb://mongo:27017/nightscoutdb
      API_SECRET: SECRET
      BG_HIGH: 200
      BG_LOW: 70
      BG_TARGET_TOP: 180
      BG_TARGET_BOTTOM: 70
      AUTH_DEFAULT_ROLES: readable devicestatus-upload
      ENABLE: careportal boluscalc food bwp cage sage iage iob cob basal ar2 rawbg pushover bgi pump openaps cors connect
      SHOW_FORECAST: openaps
      SHOW_PLUGINS: careportal openaps pump iob sage cage
      CUSTOM_TITTLE: Nightscout
      DISPLAY_UNITS: mg/dl
      INSECURE_USE_HTTP: "true"
      CONNECT_SOURCE: minimedcarelink
      CONNECT_CARELINK_REGION: eu
      CONNECT_COUNTRY_CODE: pl
      CONNECT_CARELINK_USERNAME: user
      CONNECT_CARELINK_PASSWORD: pass
    ports:
      - 1337:1337
    depends_on:
      - mongo
    volumes:
      - ./nightscout:/var/opt/ssl/:ro
    restart: unless-stopped

  mongo:
    image: mongo:4.4.23
    container_name: mongo
    environment:
      TZ: Europe/Warsaw
    volumes:
      - ./mongo/data:/data/db
    restart: unless-stopped

extract from docker logs:

   {
      lastSGTrend: 'UP',
      type: 'sgv',
      sgv: 174,
      date: 1691354760000,
      dateString: '2023-08-06T20:46:00.000Z',
      device: 'nightscout-connect://minimedcarelink/NGP',
      trend: 2,
      direction: 'SingleUp'
    }
  ],
  devicestatus: [
    {
      created_at: '2023-08-06T18:47:18.807Z',
      lastMedicalDeviceDataUpdateServerTime: 1691347606617,
      device: 'nightscout-connect://minimedcarelink/NGP',
      uploader: [Object],
      connect: [Object],
      pump: [Object]
    }
  ],
  treatments: []
}
got data-received event, requesting reload

Glooko: Request failed with status code 432

Hello everyone,

Since the beginning of December 2023, I no longer see any values from Glooko in Nightscout. Everything worked before, but Glooko seems to have changed something, as retrieving the data fails with an error 432. The login etc. works, only the retrieval of the data seems to have changed:

event: {
type: 'error.platform.phase.Fetching:invocation[0]',
data: AxiosError: Request failed with status code 432
at settle (/node_modules/axios/dist/node/axios.cjs:1913:12)
at IncomingMessage.handleStreamEnd (/node_modules/axios/dist/node/axios.cjs:2995:11)
at IncomingMessage.emit (node:events:526:35)
at endReadableNT (node:internal/streams/readable:1359:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
code: 'ERR_BAD_REQUEST',
config: [Object],
request: [ClientRequest],
response: [Object]
},

Is there anything known here?

Thanks and best regards
Fabian

Question/idea: Passthrough of cloud connection status to AAPS/xDrip etc?

Hi,

without any knowledge about the inner workings of nightscout, would it in general be possible to pass some (status) information from the cloud provider connection to the "end device" (like xDrip, AAPS)?

My use case is: From time to time, the LibreLinkUp site requires accepting new EULAs. Without this, no access to the readings is possible (see timoschlueter/nightscout-librelink-up#100). So far, this is indicated in xDrip/AAPS as no readings available for the last x minutes. In my setup (currently running nightscout-librelink-up, not nightscout-connect), I'll have to dig through the server logs and find the error message...

As I am considering testing/switching to nightscout-connect, I wonder how this and similar cases are handled - it would be very helpful to see some more detailed status message on the end device, e.g. Cloud EULA changed, please acknowledge...

Thanks!

Crashing when attempting to sync with Glooko

Hey y'all,

So I've got this basically set up it seems, but there is an error when trying to sync with Glooko. It's authenticating correctly from the logs I've seen, but then I see this error which leads to a crash:

2023-08-26T09:35:04Z app[1781975b54e178] fra [info]/opt/app/node_modules/nightscout-connect/lib/sources/glooko/index.js:85
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]      var last_mills = Math.max(two_days_ago, last_known.entries ? last_known.entries.getTime( ) : two_days_ago);
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]                                                         ^
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]TypeError: Cannot read properties of null (reading 'entries')
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Object.dataFromSesssion (/opt/app/node_modules/nightscout-connect/lib/sources/glooko/index.js:85:58)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at dataFetchService (/opt/app/node_modules/nightscout-connect/lib/machines/fetch.js:8:19)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Interpreter._exec (/opt/app/node_modules/xstate/lib/interpreter.js:269:63)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Interpreter.exec (/opt/app/node_modules/xstate/lib/interpreter.js:1026:10)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Interpreter.execute (/opt/app/node_modules/xstate/lib/interpreter.js:387:14)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Interpreter.update (/opt/app/node_modules/xstate/lib/interpreter.js:415:12)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at /opt/app/node_modules/xstate/lib/interpreter.js:110:15
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Scheduler.process (/opt/app/node_modules/xstate/lib/scheduler.js:69:7)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Scheduler.schedule (/opt/app/node_modules/xstate/lib/scheduler.js:48:10)
2023-08-26T09:35:04Z app[1781975b54e178] fra [info]    at Interpreter.send (/opt/app/node_modules/xstate/lib/interpreter.js:104:23)

Looks like somehow last_known is being passed in as null? Any idea why this might happen or how I can resolve it? Maybe we just need to have an explicit if last_entries === null in there to handle this?

LibreLinkUp crashes when last_known is null

I have the following error when using the nightscout-connect plugin 0.0.12 on nightscout version 15.0.1:

 /opt/app/node_modules/nightscout-connect/lib/sources/librelinkup.js:124
       var last_updated = last_known.entries;
                                     ^

 TypeError: Cannot read properties of null (reading 'entries')
     at Object.transformGlucose [as transformer] (/opt/app/node_modules/nightscout-connect/lib/sources/librelinkup.js:124:37)
     at transformService (/opt/app/node_modules/nightscout-connect/lib/machines/fetch.js:14:37)
     at Interpreter._exec (/opt/app/node_modules/xstate/lib/interpreter.js:269:63)
     at Interpreter.exec (/opt/app/node_modules/xstate/lib/interpreter.js:1026:10)
     at Interpreter.execute (/opt/app/node_modules/xstate/lib/interpreter.js:387:14)
     at Interpreter.update (/opt/app/node_modules/xstate/lib/interpreter.js:415:12)
     at /opt/app/node_modules/xstate/lib/interpreter.js:110:15
     at Scheduler.process (/opt/app/node_modules/xstate/lib/scheduler.js:69:7)
     at Scheduler.schedule (/opt/app/node_modules/xstate/lib/scheduler.js:48:10)
     at Interpreter.send (/opt/app/node_modules/xstate/lib/interpreter.js:104:23)

It seems the variable last_known is no longer used so the line lib/sources/librelinkup.js:124 can probably be removed.

I tried contributing myself but I don't have permissions to open a PR :(.

Add support for Dexcom Japan server

This PR just landed in Loop dev: LoopKit/dexcom-share-client-swift#42

It probably holds the info needed to get the server used by Dexcom in Japan etc to work with NS connect.

It should already be possible by using a custom server address, but should probably be added as an option too.

Deleted:
    case NON_US="https://shareous1.dexcom.com"

Added:
    case APAC="https://share.dexcom.jp"
    case Worldwide="https://shareous1.dexcom.com"

@bewest

[GLOOKO] Problem with nightscout-connect using European Glooko account

I am trying to connect to a European Glooko account from Spain, and I get an error when connecting. Here are the logs from Nightscout:

2023-08-05T18:23:30.513865455Z stdout F MiniMed Connect not enabled
2023-08-05T18:23:26.821569259Z stdout F Executing setupMMConnect
2023-08-05T18:23:26.821517826Z stdout F Dexcom bridge not enabled
2023-08-05T18:23:25.015052031Z stdout F Executing setupBridge
2023-08-05T18:23:24.819624981Z stdout F }
2023-08-05T18:23:24.819622748Z stdout F kind: 'glooko'
2023-08-05T18:23:24.819620799Z stdout F baseURL: 'https://eu.api.glooko.com';,
2023-08-05T18:23:24.819619004Z stdout F glookoTimezoneOffset: -7200000,
2023-08-05T18:23:24.819617002Z stdout F glookoPassword: '',
2023-08-05T18:23:24.819614804Z stdout F glookoEmail: '*@gmail.com',
2023-08-05T18:23:24.819612086Z stdout F glookoServer: 'eu.api.glooko.com',
2023-08-05T18:23:24.819609229Z stdout F glookoEnv: 'eu',
2023-08-05T18:23:24.819593054Z stdout F INPUT PARAMS { kind: 'glooko' } {
2023-08-05T18:23:24.819203689Z stdout F GLOOKO using ms offset: -7200000 2

2023-08-05T18:23:43.195213184Z stdout F }
2023-08-05T18:23:43.195211094Z stdout F response: [Object]
2023-08-05T18:23:43.195208838Z stdout F request: [ClientRequest],
2023-08-05T18:23:43.195206737Z stdout F config: [Object],
2023-08-05T18:23:43.195204564Z stdout F code: 'ERR_BAD_REQUEST',
2023-08-05T18:23:43.195202226Z stdout F at processTicksAndRejections (node:internal/process/task_queues:83:21) {
2023-08-05T18:23:43.195199974Z stdout F at endReadableNT (node:internal/streams/readable:1358:12)
2023-08-05T18:23:43.195195974Z stdout F at Unzip.emit (node:events:525:35)
2023-08-05T18:23:43.19519297Z stdout F at Unzip.handleStreamEnd (/workspace/node_modules/nightscout-connect/node_modules/axios/dist/node/axios.cjs:2989:11)
2023-08-05T18:23:43.195188961Z stdout F at settle (/workspace/node_modules/nightscout-connect/node_modules/axios/dist/node/axios.cjs:1909:12)
2023-08-05T18:23:43.195184914Z stdout F data: AxiosError: Request failed with status code 422
2023-08-05T18:23:43.195180833Z stdout F type: 'AUTHENTICATION_ERROR',

[glooko] meal bolus split into insulin and carbs part

When using the glooko source, meal boli are imported into nightscout twice, separating the insulin from the carbs.

Basically, there's one meal bolus containing the given insulin and another one (offset by ~1 minute) with the carbs. I assume the data is also split like this on the glooko api side, yet I wonder if there's some way to combine the data when importing.

Timezone offset for glooko does not respect daylight savings time (DST)

For glooko, a timezone offset needs to be configured in order for the records to correctly show up in nightscout.
However, in a lot of regions, the timezone offset changes by +/-1 hour depending on daylight savings time / summer time. As it is right now, the events will likely be wrongly offsetted when the switch from / to DST happens.

Potential improvement would be to allow specifying the actual target timezone (like Europe/Berlin) as a configurable environment variable instead of a fixed offset as to the best of my knowledge, NodeJS can automatically handle the different offset due to DST (if any) given a timezone name.

https://github.com/nightscout/nightscout-connect/blob/8f2ab374a288f8541b916d92cecfb55bb5f44889/lib/sources/glooko/index.js#L171C13-L171C13

Get no data from europe dexcom share connection

Hi, I have a Dexcom account with a connection to another account as the follower. Since nightscout uses now this plugin I get no data anymore for my main account.

INPUT PARAMS { kind: 'dexcomshare' } {
  shareRegion: 'ous',
  shareServer: undefined,
  shareAccountName: 'XYZ',
  sharePassword: 'XYZ',
  baseURL: 'https://shareous1.dexcom.com',
  kind: 'dexcomshare'
}

here is the log output_

Load Complete:
         profiles:1
data loaded: reloading sandbox data and updating plugins
EVENTUALLY FOUND null
FETCHING
{
  context: {
    retries: 0,
    duration: 0,
    session: '57ca4572-c13f-4a75-99c7-e1fa3569cd72',
    last_known: null,
    diagnostics: {},
    started: 1701122421439,
    startedWaiting: 1701122421439,
    endedWaiting: 1701122421440,
    elapsedWaiting: 1,
    data: [],
    transformed: { entries: [] }
  },
  event: {
    type: 'done.invoke.phase.Transforming:invocation[0]',
    data: { entries: [] },
    toString: [Function (anonymous)]
  }
}
INTERNAL PERSISTENCE { entries: [] }
ALL SETTLED INTERNAL PERSIST [ undefined, undefined, undefined, undefined, null ] [Arguments] {
  '0': [ undefined, undefined, undefined, undefined, null ]
}
INSIDE DEXCOM SOURCE DRIVER ALIGNMENT FOR GLUCOSE
FRAME DONE
{
  context: {
    retries: 0,
    duration: 0,
    session: '57ca4572-c13f-4a75-99c7-e1fa3569cd72',
    last_known: null,
    diagnostics: {},
    started: 1701122421439,
    startedWaiting: 1701122421439,
    endedWaiting: 1701122421440,
    elapsedWaiting: 1,
    data: [],
    transformed: { entries: [] },
    persisted: null
  },
  event: {
    type: 'done.invoke.phase.Persisting:invocation[0]',
    data: null,
    toString: [Function (anonymous)]
  }
}
AFTER

Any suggestions for this issue?

[minimed carelink] Carelink follower login error

After Carelink connect upgrade at 9.28, use google reCaptcha for login, I think it is possible to add an external carelink login page to get login token

Error on empty nightscout instance (glooko)

The following code throws an error if running the connect plugin with glooko credentials on an empty nightscout instance, I assume because there is no last_known yet.

/opt/app/node_modules/nightscout-connect/lib/sources/glooko/index.js:85
      var last_mills = Math.max(two_days_ago, last_known.entries ? last_known.entries.getTime( ) : two_days_ago);
                                                         ^
TypeError: Cannot read properties of null (reading 'entries')
    at Object.dataFromSesssion (/opt/app/node_modules/nightscout-connect/lib/sources/glooko/index.js:85:58)
    at dataFetchService (/opt/app/node_modules/nightscout-connect/lib/machines/fetch.js:8:19)
    at Interpreter._exec (/opt/app/node_modules/xstate/lib/interpreter.js:269:63)
    at Interpreter.exec (/opt/app/node_modules/xstate/lib/interpreter.js:1026:10)
    at Interpreter.execute (/opt/app/node_modules/xstate/lib/interpreter.js:387:14)
    at Interpreter.update (/opt/app/node_modules/xstate/lib/interpreter.js:415:12)
    at /opt/app/node_modules/xstate/lib/interpreter.js:110:15
    at Scheduler.process (/opt/app/node_modules/xstate/lib/scheduler.js:69:7)
    at Scheduler.schedule (/opt/app/node_modules/xstate/lib/scheduler.js:48:10)
    at Interpreter.send (/opt/app/node_modules/xstate/lib/interpreter.js:104:23)

https://github.com/nightscout/nightscout-connect/blob/8f2ab374a288f8541b916d92cecfb55bb5f44889/lib/sources/glooko/index.js#L85C22-L85C22

Glooko returns 0 treatments

Hi,

I'm using nightscout-connect plugin to syng from glooko. Authorization is successuful but Heroku logs shows that zero treatments are returned:

2024-01-27T12:58:59.055619+00:00 app[web.1]: FETCHING
2024-01-27T12:58:59.055705+00:00 app[web.1]: GLOOKO passing batch for transforming
2024-01-27T12:58:59.055795+00:00 app[web.1]: GLOOKO data transformation complete, returning 0 treatments

What am I missing?

Thanks,
Rafael

shareous2.dexcom.com

Hi, I got an error when trying to pull Dexcom data from shareous2.excom.com. I believe it should be shareous1.dexcom.com

best regards
Fredrik

[minimed carelink] Nightscout-connect adds 0, when no up-to-date SGV data is available

Hi all,
I just recently started using the nightscout-connect plugin, as I used xDrip as an uploader to nightscout before.

Today, I changed my sensor for the first time since starting to use nightscout-connect and I recognized, that the plugin adds data points to the database every five minutes with an SGV=0. I think that should not be.

In the following example, I fetched the recent 12 values by
curl https://XXXXXXXXXX.my.nightscoutpro.com/api/v1/entries/sgv.json?count=12&token=XXXXXXXXXX

[{"_id":"64e7663c84a84c2674e17656","lastSGTrend":"NONE","type":"sgv","sgv":XXXXXX,"date":1692886500000,"dateString":"2023-08-24T14:15:00.000Z","device":"go-away-please","trend":XXXXX,"direction":"Flat","utcOffset":0,"sysTime":"2023-08-24T14:15:00.000Z","mills":1692886500000},
{"_id":"64e7663c84a84c2674e1764d","type":"sgv","sgv":0,"date":1692886200000,"dateString":"2023-08-24T14:10:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T14:10:00.000Z","mills":1692886200000},
{"_id":"64e7650884a84c2674daa2d0","type":"sgv","sgv":0,"date":1692885900000,"dateString":"2023-08-24T14:05:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T14:05:00.000Z","mills":1692885900000},
{"_id":"64e763dd84a84c2674d35c6e","type":"sgv","sgv":0,"date":1692885600000,"dateString":"2023-08-24T14:00:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T14:00:00.000Z","mills":1692885600000},
{"_id":"64e762b484a84c2674cc1b9a","type":"sgv","sgv":0,"date":1692885300000,"dateString":"2023-08-24T13:55:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:55:00.000Z","mills":1692885300000},
{"_id":"64e7618584a84c2674c4815f","type":"sgv","sgv":0,"date":1692885000000,"dateString":"2023-08-24T13:50:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:50:00.000Z","mills":1692885000000},
{"_id":"64e7605184a84c2674bd5070","type":"sgv","sgv":0,"date":1692884700000,"dateString":"2023-08-24T13:45:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:45:00.000Z","mills":1692884700000},
{"_id":"64e75f2784a84c2674b58cc3","type":"sgv","sgv":0,"date":1692884400000,"dateString":"2023-08-24T13:40:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:40:00.000Z","mills":1692884400000},
{"_id":"64e75dfe84a84c2674ade186","type":"sgv","sgv":0,"date":1692884100000,"dateString":"2023-08-24T13:35:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:35:00.000Z","mills":1692884100000},
{"_id":"64e75cd384a84c2674a61050","type":"sgv","sgv":0,"date":1692883800000,"dateString":"2023-08-24T13:30:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:30:00.000Z","mills":1692883800000},
{"_id":"64e75ba684a84c26749e9352","type":"sgv","sgv":0,"date":1692883500000,"dateString":"2023-08-24T13:25:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:25:00.000Z","mills":1692883500000},
{"_id":"64e75a7284a84c2674968a99","type":"sgv","sgv":0,"date":1692883200000,"dateString":"2023-08-24T13:20:00.000Z","device":"go-away-please","utcOffset":0,"sysTime":"2023-08-24T13:20:00.000Z","mills":1692883200000}]

I'd rather expect the downloader to recognize, that there's no new data available and leave the DB untouched. This adding of zeros might lead to unexpected behavior of other software, that fetches nightscout data through the API (like my Garmin watchface).

Thanks for your time.
Trenar

Requirements to get this working against LibreLinkup

Hi,

So I have got Nightscout set up in Azure, and it is running fine but I wanted to use the nightscout-connect to pull data from Librelinkup and i just cant get it to pull any data through to Nightscout. No errors, just no data.

I am running Nightscout 14.2.6

And in Nightscout I have added the following variables (only showing the ones I have used for nightscout-connect)

ENABLE = connect
SHOW_PLUGINS = connect
CONNECT_SOURCE=linkup
CONNECT_LINK_UP_USERNAME=
CONNECT_LINK_UP_PASSWORD=

I haven't entered anything for the region as I am based in the UK (so I am assuming this is regarded as EU in this case even though we have left the EU).... Actually is there a UK region?

Steps to get this working?

I am probably missing something very obvious, but I did the following on my Heroku Nightscout install:

Add 'connect' to the ENABLE config var list.
Added new config vars for: CONNECT_SOURCE, CONNECT_LINK_UP_USERNAME, CONNECT_LINK_UP_PASSWORD, CONNECT_LINK_UP_REGION, CONNECT_LINK_UP_PATIENT_ID

There is no data coming into the Nightscout site from my Libre 3. Any thoughts on the best way to move forward?

Glooko: filter out pump timestamps

Treatments are delivered with pump-timestamps as notes. Maybe it's possible to avoid this.