nightscout / cgm-remote-monitor Goto Github PK

nightscout web monitor

License: GNU Affero General Public License v3.0

Makefile 0.19% JavaScript 85.47% Shell 0.34% HTML 5.11% CSS 8.48% Dockerfile 0.04% EJS 0.36% Procfile 0.01%

cgm-remote-monitor's Introduction

Nightscout Web Monitor (a.k.a. cgm-remote-monitor)

This acts as a web-based CGM (Continuous Glucose Monitor) to allow multiple caregivers to remotely view a patient's glucose data in real time. The server reads a MongoDB which is intended to be data from a physical CGM, where it sends new SGV (sensor glucose values) as the data becomes available. The data is then displayed graphically and blood glucose values are predicted 0.5 hours ahead using an autoregressive second order model. Alarms are generated for high and low values, which can be cleared by any watcher of the data.

Looking for documentation?

End user?

Nightscout documentation is currently split to two locations. This page lists all the configuration options in Nightscout and is useful for users who've already gone through the installation process. IF you're looking for the documentation that looks like it's written for non-programmers, that's located at nightscout.github.io.

Older documentation is available at nightscout.info.

Developer?

See CONTRIBUTING.md

#WeAreNotWaiting and this is why.

Table of Contents

Install
Development
Usage

Install

Supported configurations:

Nightscout Setup (recommended)

While you can install Nightscout on a virtual server or a Raspberry Pi, we do not recommend this unless you have at least some experience hosting Node applications and development using the toolchain in use with Nightscout.

If you're a hosting provider and want to provide our users additional hosting options, you're welcome to issue a documentation pull request with instructions on how to setup Nightscout on your system.

Recommended minimum browser versions for using Nightscout:

Our browserslist policy is documented in .browserlistrc.
We currently support approximately 91% of all browsers globally used. These include:

Android Chrome: 104 or later (and_chr)
Google Chrome: 101 or later (chrome)
Microsoft Edge: 103 or later (edge)
Mozilla Firefox: 102 or later (firefox)
Apple Safari on iOS: 15.5 or later (ios_saf)
Opera Mini on Android: 63 or later (op_mini)
Opera: 88 or later (opera)
Apple Safari for macOS 10.15 Catalina or later: : 15.5 or later (safari)
Samsung Internet on Android: 17.0 or later (samsung)
Internet Explorer 11 : not supported

Older versions or other browsers might work, but are untested and unsupported. We'll try to to keep Nightscout compatible with older iPads (e.g. Safari on iOS 10.3.4), but note that those devices are not supported by Apple anymore and have known security issues. Debugging these old devices gets harder due to Apple not supporting debugging the old devices on Macs that have been updated. Some features may not work with devices/browsers on the older end of these requirements.

Installation software requirements:

Node.js Latest Node v14 or v16 LTS. Node versions that do not have the latest security patches will not be supported. Use Install instructions for Node or use bin/setup.sh)
MongoDB 4.2 or 4.4.

As a non-root user clone this repo then install dependencies into the root of the project:

$ npm install

Installation notes for users with nginx or Apache reverse proxy for SSL/TLS offloading:

Your site redirects insecure connections to https by default. If you use a reverse proxy like nginx or Apache to handle the connection security for you, make sure it sets the X-Forwarded-Proto header. Otherwise nightscout will be unable to know if it was called through a secure connection and will try to redirect you to the https version. If you're unable to set this Header, you can change the INSECURE_USE_HTTP setting in nightscout to true in order to allow insecure connections without being redirected.
In case you use a proxy. Do not use an external network interfaces for hosting Nightscout. Make sure the unsecure port is not available from a remote network connection
HTTP Strict Transport Security (HSTS) headers are enabled by default, use settings SECURE_HSTS_HEADER and SECURE_HSTS_HEADER_*
See Predefined values for your server settings for more details

Installation notes for Microsoft Azure, Windows:

If deploying the software to Microsoft Azure, you must set ** in the app settings for WEBSITE_NODE_DEFAULT_VERSION and SCM_COMMAND_IDLE_TIMEOUT before you deploy the latest Nightscout or the site deployment will likely fail. Other hosting environments do not require this setting. Additionally, if using the Azure free hosting tier, the installation might fail due to resource constraints imposed by Azure on the free hosting. Please set the following settings to the environment in Azure:

WEBSITE_NODE_DEFAULT_VERSION=16.16.0
SCM_COMMAND_IDLE_TIMEOUT=300

See install MongoDB, Node.js, and Nightscouton a single Windows system. if you want to host your Nightscout outside of the cloud. Although the instructions are intended for Windows Server the procedure is compatible with client versions of Windows such as Windows 7 and Windows 10.
If you deploy to Windows and want to develop or test you need to install Cygwin (use setup-x86_64.exe and make sure to install build-essential package. Test your configuration by executing make and check if all tests are ok.

Development

Want to help with development, or just see how Nightscout works? Great! See CONTRIBUTING.md for development-related documentation.

Usage

The data being uploaded from the server to the client is from a MongoDB server such as [MongoDB Atlas][https://www.mongodb.com].

Updating my version?

The easiest way to update your version of cgm-remote-monitor to the latest version is to use the update tool. A step-by-step guide is available [here][http://www.nightscout.info/wiki/welcome/how-to-update-to-latest-cgm-remote-monitor-aka-cookie]. To downgrade to an older version, follow [this guide][http://www.nightscout.info/wiki/welcome/how-to-deploy-an-older-version-of-nightscout].

Configure my uploader to match

Use the autoconfigure tool to sync an uploader to your config.

Nightscout API

The Nightscout API enables direct access to your data without the need for Mongo access. You can find CGM data in /api/v1/entries, Care Portal Treatments in /api/v1/treatments, and Treatment Profiles in /api/v1/profile. The server status and settings are available from /api/v1/status.json.

By default the /entries and /treatments APIs limit results to the the most recent 10 values from the last 2 days. You can get many more results, by using the count, date, dateString, and created_at parameters, depending on the type of data you're looking for.

Once you've installed Nightscout, you can access API documentation by loading /api-docs/ URL in your instance.

Example Queries

(replace http://localhost:1337 with your own URL)

100's: http://localhost:1337/api/v1/entries.json?find[sgv]=100
Count of 100's in a month: http://localhost:1337/api/v1/count/entries/where?find[dateString][$gte]=2016-09&find[dateString][$lte]=2016-10&find[sgv]=100
BGs between 2 days: http://localhost:1337/api/v1/entries/sgv.json?find[dateString][$gte]=2015-08-28&find[dateString][$lte]=2015-08-30
Juice Box corrections in a year: http://localhost:1337/api/v1/treatments.json?count=1000&find[carbs]=15&find[eventType]=Carb+Correction&find[created_at][$gte]=2015
Boluses over 2U: http://localhost:1337/api/v1/treatments.json?find[insulin][$gte]=2

The API is Swagger enabled, so you can generate client code to make working with the API easy. To learn more about the Nightscout API, visit https://YOUR-SITE.com/api-docs/ or review swagger.yaml.

Environment

VARIABLE (default) - description

Required

MONGODB_URI - The connection string for your Mongo database. Something like mongodb://sally:[email protected]:99999/nightscout.
API_SECRET - A secret passphrase that must be at least 12 characters long.
MONGODB_COLLECTION (entries) - The Mongo collection where CGM entries are stored.
DISPLAY_UNITS (mg/dl) - Options are mg/dl or mmol/L (or just mmol). Setting to mmol/L puts the entire server into mmol/L mode by default, no further settings needed.

Features

ENABLE - Used to enable optional features, expects a space delimited list, such as: careportal rawbg iob, see plugins below
DISABLE - Used to disable default features, expects a space delimited list, such as: direction upbat, see plugins below
BASE_URL - Used for building links to your site's API, i.e. Pushover callbacks, usually the URL of your Nightscout site.
AUTH_DEFAULT_ROLES (readable) - possible values readable, denied, or any valid role name. When readable, anyone can view Nightscout without a token. Setting it to denied will require a token from every visit, using status-only will enable api-secret based login.
IMPORT_CONFIG - Used to import settings and extended settings from a url such as a gist. Structure of file should be something like: {"settings": {"theme": "colors"}, "extendedSettings": {"upbat": {"enableAlerts": true}}}
TREATMENTS_AUTH (on) - possible values on or off. Deprecated, if set to off the careportal role will be added to AUTH_DEFAULT_ROLES

Data Rights

These are useful to help protect your rights to portability and autonomy for your data:

OBSCURED - list, identical to ENABLE, a list of plugins to obscure.
OBSCURE_DEVICE_PROVENANCE - Required, a string visible to the companies deciding to filter based on your data. For example, my-data-rights.

Alarms

These alarm setting affect all delivery methods (browser, Pushover, IFTTT, etc.). Values and settings entered here will be the defaults for new browser views, but will be overridden if different choices are made in the settings UI.

ALARM_TYPES (simple if any BG_* ENV's are set, otherwise predict) - currently 2 alarm types are supported, and can be used independently or combined. The simple alarm type only compares the current BG to BG_ thresholds above, the predict alarm type uses highly tuned formula that forecasts where the BG is going based on it's trend. predict DOES NOT currently use any of the BG_* ENV's
BG_HIGH (260) - the high BG outside the target range that is considered urgent (interprets units based on DISPLAY_UNITS setting)
BG_TARGET_TOP (180) - the top of the target range, also used to draw the line on the chart (interprets units based on DISPLAY_UNITS setting)
BG_TARGET_BOTTOM (80) - the bottom of the target range, also used to draw the line on the chart (interprets units based on DISPLAY_UNITS setting)
BG_LOW (55) - the low BG outside the target range that is considered urgent (interprets units based on DISPLAY_UNITS setting)
ALARM_URGENT_HIGH (on) - possible values on or off
ALARM_URGENT_HIGH_MINS (30 60 90 120) - Number of minutes to snooze urgent high alarms, space separated for options in browser, first used for pushover
ALARM_HIGH (on) - possible values on or off
ALARM_HIGH_MINS (30 60 90 120) - Number of minutes to snooze high alarms, space separated for options in browser, first used for pushover
ALARM_LOW (on) - possible values on or off
ALARM_LOW_MINS (15 30 45 60) - Number of minutes to snooze low alarms, space separated for options in browser, first used for pushover
ALARM_URGENT_LOW (on) - possible values on or off
ALARM_URGENT_LOW_MINS (15 30 45) - Number of minutes to snooze urgent low alarms, space separated for options in browser, first used for pushover
ALARM_URGENT_MINS (30 60 90 120) - Number of minutes to snooze urgent alarms (that aren't tagged as high or low), space separated for options in browser, first used for pushover
ALARM_WARN_MINS (30 60 90 120) - Number of minutes to snooze warning alarms (that aren't tagged as high or low), space separated for options in browser, first used for pushover

Core

MONGO_TREATMENTS_COLLECTION (treatments) -The collection used to store treatments entered in the Care Portal, see the ENABLE env var above
MONGO_DEVICESTATUS_COLLECTION(devicestatus) - The collection used to store device status information such as uploader battery
MONGO_PROFILE_COLLECTION(profile) - The collection used to store your profiles
MONGO_FOOD_COLLECTION(food) - The collection used to store your food database
MONGO_ACTIVITY_COLLECTION(activity) - The collection used to store activity data
PORT (1337) - The port that the node.js application will listen on.
HOSTNAME - The hostname that the node.js application will listen on, null by default for any hostname for IPv6 you may need to use ::.
SSL_KEY - Path to your ssl key file, so that ssl(https) can be enabled directly in node.js. If using Let's Encrypt, make this variable the path to your privkey.pem file (private key).
SSL_CERT - Path to your ssl cert file, so that ssl(https) can be enabled directly in node.js. If using Let's Encrypt, make this variable the path to fullchain.pem file (cert + ca).
SSL_CA - Path to your ssl ca file, so that ssl(https) can be enabled directly in node.js. If using Let's Encrypt, make this variable the path to chain.pem file (chain).
HEARTBEAT (60) - Number of seconds to wait in between database checks
DEBUG_MINIFY (true) - Debug option, setting to false will disable bundle minification to help tracking down error and speed up development
DE_NORMALIZE_DATES(true) - The Nightscout REST API normalizes all entered dates to UTC zone. Some Nightscout clients have broken date deserialization logic and expect to received back dates in zoned formats. Setting this variable to true causes the REST API to serialize dates sent to Nightscout in zoned format back to zoned format when served to clients over REST.

Predefined values for your browser settings (optional)

TIME_FORMAT (12)- possible values 12 or 24
DAY_START (7.0) - time for start of day (0.0 - 24.0) for features using day time / night time options
DAY_END (21.0) - time for end of day (0.0 - 24.0) for features using day time / night time options
NIGHT_MODE (off) - possible values on or off
SHOW_RAWBG (never) - possible values always, never or noise
CUSTOM_TITLE (Nightscout) - Title for the main view
THEME (colors) - possible values default, colors, or colorblindfriendly
ALARM_TIMEAGO_WARN (on) - possible values on or off
ALARM_TIMEAGO_WARN_MINS (15) - minutes since the last reading to trigger a warning
ALARM_TIMEAGO_URGENT (on) - possible values on or off
ALARM_TIMEAGO_URGENT_MINS (30) - minutes since the last reading to trigger a urgent alarm
SHOW_PLUGINS - enabled plugins that should have their visualizations shown, defaults to all enabled
SHOW_FORECAST (ar2) - plugin forecasts that should be shown by default, supports space delimited values such as "ar2 openaps"
LANGUAGE (en) - language of Nightscout. If not available english is used
- Currently supported language codes are: bg (Български), cs (Čeština), de (Deutsch), dk (Dansk), el (Ελληνικά), en (English), es (Español), fi (Suomi), fr (Français), he (עברית), hr (Hrvatski), hu (magyar), it (Italiano), ko (한국어), nb (Norsk (Bokmål)), nl (Nederlands), pl (Polski), pt (Português (Brasil)), ro (Română), ru (Русский), sk (Slovenčina), sv (Svenska), tr (Turkish), zh_cn (中文（简体)), zh_tw (中文（繁體))
SCALE_Y (log) - The type of scaling used for the Y axis of the charts system wide.
- The default log (logarithmic) option will let you see more detail towards the lower range, while still showing the full CGM range.
- The linear option has equidistant tick marks; the range used is dynamic so that space at the top of chart isn't wasted.
- The log-dynamic is similar to the default log options, but uses the same dynamic range and the linear scale.
EDIT_MODE (on) - possible values on or off. Enables the icon allowing for editing of treatments in the main view.

Predefined values for your server settings (optional)

INSECURE_USE_HTTP (false) - Redirect unsafe http traffic to https. Possible values false, or true. Your site redirects to https by default. If you don't want that from Nightscout, but want to implement that with a Nginx or Apache proxy, set INSECURE_USE_HTTP to true. Note: This will allow (unsafe) http traffic to your Nightscout instance and is not recommended.
SECURE_HSTS_HEADER (true) - Add HTTP Strict Transport Security (HSTS) header. Possible values false, or true.
SECURE_HSTS_HEADER_INCLUDESUBDOMAINS (false) - includeSubdomains options for HSTS. Possible values false, or true.
SECURE_HSTS_HEADER_PRELOAD (false) - ask for preload in browsers for HSTS. Possible values false, or true.
SECURE_CSP (false) - Add Content Security Policy headers. Possible values false, or true.
SECURE_CSP_REPORT_ONLY (false) - If set to true allows to experiment with policies by monitoring (but not enforcing) their effects. Possible values false, or true.

Views

Nightscout allows to create custom, simplified views using a predefined set of elements. This option is available under [+] link in the main menu.

List of available items:

SGV - Sensor Glucose Value
SGV age - time since the last SGV read
SGV delta - change of SGV in the last 5 minutes
Trend arrow - icon of the SG trend
Time - current time
Line break - invisible item that will move following items to the next line (by default all are showing on the same level)

All visible items have Size property which allows to customize the view even more. Also, all items may appear multiple times on the view.

Apart from adding items, it is possible to customize other aspects of the views, like selecting Color or Black background. The first one will indicate current BG threshold (green = in range; blue = below range; yellow = above range; red = urgent below/above). Show SGV age option will make SGV age item appear Always or only if the predefined threshold is reached: Only after threshold. Breaching SGV age threshold will also make Color background turn grey and strike through SGV. Clock view configurator will generate an URL (available under Open my clock view! link) that could be bookmarked.

There are a few default views available from the main menu:

Clock - Shows current BG, trend arrow, and time of day. Grey text on a black background.
Color - Shows current BG and trend arrow. White text on a color background.
Simple - Shows current BG. Grey text on a black background.

If you launch one of these views in a fullscreen view in iOS, you can use a left-to-right swipe gesture to exit the view.

Split View

Some users will need easy access to multiple Nightscout views at the same time. We have a special view for this case, accessed on /split path on your Nightscout URL. The view supports any number of sites between 1 to 8 way split, where the content for the screen can be loaded from multiple Nightscout instances. Note you still need to host separate instances for each Nightscout being monitored including the one that hosts the split view page - these variables only add the ability to load multiple views into one browser page. To set the URLs from which the content is loaded, set:

FRAME_URL_1 - URL where content is loaded, for the first view (increment the number up to 8 to get more views)
FRAME_NAME_1 - Name for the first split view portion of the screen (increment the number to name more views)

Plugins

Plugins are used extend the way information is displayed, how notifications are sent, alarms are triggered, and more.

The built-in/example plugins that are available by default are listed below. The plugins may still need to be enabled by adding to the ENABLE environment variable.

Default Plugins

These can be disabled by adding them to the DISABLE variable, for example DISABLE="direction upbat"

`delta` (BG Delta)

Calculates and displays the change between the last 2 BG values.

`direction` (BG Direction)

Displays the trend direction.

`upbat` (Uploader Battery)

Displays the most recent battery status from the uploader phone. . Use these extended setting to adjust behavior:

UPBAT_ENABLE_ALERTS (false) - Set to true to enable uploader battery alarms via Pushover and IFTTT.
UPBAT_WARN (30) - Minimum battery percent to trigger warning.
UPBAT_URGENT (20) - Minimum battery percent to trigger urgent alarm.

`timeago` (Time Ago)

Displays the time since last CGM entry. Use these extended setting to adjust behavior:

TIMEAGO_ENABLE_ALERTS (false) - Set to true to enable stale data alarms via Pushover and IFTTT.
ALARM_TIMEAGO_WARN (on) - possible values on or off
ALARM_TIMEAGO_WARN_MINS (15) - minutes since the last reading to trigger a warning
ALARM_TIMEAGO_URGENT (on) - possible values on or off
ALARM_TIMEAGO_URGENT_MINS (30) - minutes since the last reading to trigger a urgent alarm

`devicestatus` (Device Status)

Used by upbat and other plugins to display device status info. Supports the DEVICESTATUS_ADVANCED="true" extended setting to send all device statuses to the client for retrospective use and to support other plugins.

`errorcodes` (CGM Error Codes)

Generates alarms for CGM codes 9 (hourglass) and 10 (???).

Use extended settings to adjust what errorcodes trigger notifications and alarms:
- ERRORCODES_INFO (1 2 3 4 5 6 7 8) - By default the needs calibration (blood drop) and other codes below 9 generate an info level notification, set to a space separate list of number or off to disable
- ERRORCODES_WARN (off) - By default there are no warning configured, set to a space separate list of numbers or off to disable
- ERRORCODES_URGENT (9 10) - By default the hourglass and ??? generate an urgent alarm, set to a space separate list of numbers or off to disable

`ar2` (AR2 Forecasting)

Generates alarms based on forecasted values. See Forecasting using AR2 algorithm

Enabled by default if no thresholds are set OR ALARM_TYPES includes predict.
Use extended settings to adjust AR2 behavior:
- AR2_CONE_FACTOR (2) - to adjust size of cone, use 0 for a single line.

`simplealarms` (Simple BG Alarms)

Uses BG_HIGH, BG_TARGET_TOP, BG_TARGET_BOTTOM, BG_LOW thresholds to generate alarms.

Enabled by default if 1 of these thresholds is set OR ALARM_TYPES includes simple.

`profile` (Treatment Profile)

Add link to Profile Editor and allow to enter treatment profile settings. Also uses the extended setting:

PROFILE_HISTORY (off) - possible values on or off. Enable/disable NS ability to keep history of your profiles (still experimental)
PROFILE_MULTIPLE (off) - possible values on or off. Enable/disable NS ability to handle and switch between multiple treatment profiles

Advanced Plugins:

`careportal` (Careportal)

An optional form to enter treatments.

`boluscalc` (Bolus Wizard)

`food` (Custom Foods)

An option plugin to enable adding foods from database in Bolus Wizard and enable .

`rawbg` (Raw BG)

Calculates BG using sensor and calibration records from and displays an alternate BG values and noise levels. Defaults that can be adjusted with extended setting

DISPLAY (unsmoothed) - Allows the user to control which algorithm is used to calculate the displayed raw BG values using the most recent calibration record.
- unfiltered - Raw BG is calculated by applying the calibration to the glucose record's unfiltered value.
- filtered - Raw BG is calculated by applying the calibration to the glucose record's filtered value. The glucose record's filtered values are generally produced by the CGM by a running average of the unfiltered values to produce a smoothed value when the sensor noise is high.
- unsmoothed - Raw BG is calculated by first finding the ratio of the calculated filtered value (the same value calculated by the filtered setting) to the reported glucose value. The displayed raw BG value is calculated by dividing the calculated unfiltered value (the same value calculated by the unfiltered setting) by the ratio. The effect is to exagerate changes in trend direction so the trend changes are more noticeable to the user. This is the legacy raw BG calculation algorithm.

`iob` (Insulin-on-Board)

Adds the IOB pill visualization in the client and calculates values that used by other plugins. Uses treatments with insulin doses and the dia and sens fields from the treatment profile.

`cob` (Carbs-on-Board)

Adds the COB pill visualization in the client and calculates values that used by other plugins. Uses treatments with carb doses and the carbs_hr, carbratio, and sens fields from the treatment profile.

`bwp` (Bolus Wizard Preview)

This plugin in intended for the purpose of automatically snoozing alarms when the CGM indicates high blood sugar but there is also insulin on board (IOB) and secondly, alerting to user that it might be beneficial to measure the blood sugar using a glucometer and dosing insulin as calculated by the pump or instructed by trained medicare professionals. The values provided by the plugin are provided as a reference based on CGM data and insulin sensitivity you have configured, and are not intended to be used as a reference for bolus calculation. The plugin calculates the bolus amount when above your target, generates alarms when you should consider checking and bolusing, and snoozes alarms when there is enough IOB to cover a high BG. Uses the results of the iob plugin and sens, target_high, and target_low fields from the treatment profile. Defaults that can be adjusted with extended setting

BWP_WARN (0.50) - If BWP is > BWP_WARN a warning alarm will be triggered.
BWP_URGENT (1.00) - If BWP is > BWP_URGENT an urgent alarm will be triggered.
BWP_SNOOZE_MINS (10) - minutes to snooze when there is enough IOB to cover a high BG.
BWP_SNOOZE - (0.10) If BG is higher then the target_high and BWP < BWP_SNOOZE alarms will be snoozed for BWP_SNOOZE_MINS.

`cage` (Cannula Age)

Calculates the number of hours since the last Site Change treatment that was recorded.

CAGE_ENABLE_ALERTS (false) - Set to true to enable notifications to remind you of upcoming cannula change.
CAGE_INFO (44) - If time since last Site Change matches CAGE_INFO, user will be warned of upcoming cannula change
CAGE_WARN (48) - If time since last Site Change matches CAGE_WARN, user will be alarmed to to change the cannula
CAGE_URGENT (72) - If time since last Site Change matches CAGE_URGENT, user will be issued a persistent warning of overdue change.
CAGE_DISPLAY (hours) - Possible values are 'hours' or 'days'. If 'days' is selected and age of canula is greater than 24h number is displayed in days and hours

`sage` (Sensor Age)

Calculates the number of days and hours since the last Sensor Start and Sensor Change treatment that was recorded.

SAGE_ENABLE_ALERTS (false) - Set to true to enable notifications to remind you of upcoming sensor change.
SAGE_INFO (144) - If time since last sensor event matches SAGE_INFO, user will be warned of upcoming sensor change
SAGE_WARN (164) - If time since last sensor event matches SAGE_WARN, user will be alarmed to to change/restart the sensor
SAGE_URGENT (166) - If time since last sensor event matches SAGE_URGENT, user will be issued a persistent warning of overdue change.

`iage` (Insulin Age)

Calculates the number of days and hours since the last Insulin Change treatment that was recorded.

IAGE_ENABLE_ALERTS (false) - Set to true to enable notifications to remind you of upcoming insulin reservoir change.
IAGE_INFO (44) - If time since last Insulin Change matches IAGE_INFO, user will be warned of upcoming insulin reservoir change
IAGE_WARN (48) - If time since last Insulin Change matches IAGE_WARN, user will be alarmed to to change the insulin reservoir
IAGE_URGENT (72) - If time since last Insulin Change matches IAGE_URGENT, user will be issued a persistent warning of overdue change.

`bage` (Battery Age)

Calculates the number of days and hours since the last Pump Battery Change treatment that was recorded.

BAGE_ENABLE_ALERTS (false) - Set to true to enable notifications to remind you of upcoming pump battery change.
BAGE_DISPLAY (days) - Set to hours to display time since last Pump Battery Change in hours only.
BAGE_INFO (312) - If time since last Pump Battery Change matches BAGE_INFO hours, user will be warned of upcoming pump battery change (default of 312 hours is 13 days).
BAGE_WARN (336) - If time since last Pump Battery Change matches BAGE_WARN hours, user will be alarmed to to change the pump battery (default of 336 hours is 14 days).
BAGE_URGENT (360) - If time since last Pump Battery Change matches BAGE_URGENT hours, user will be issued a persistent warning of overdue change (default of 360 hours is 15 days).

`treatmentnotify` (Treatment Notifications)

Generates notifications when a treatment has been entered and snoozes alarms minutes after a treatment.

TREATMENTNOTIFY_SNOOZE_MINS (10) - Number of minutes to snooze notifications after a treatment is entered
TREATMENTNOTIFY_INCLUDE_BOLUSES_OVER (0) - U value over which the bolus will trigger a notification and snooze alarms

`basal` (Basal Profile)

Adds the Basal pill visualization to display the basal rate for the current time. Also enables the bwp plugin to calculate correction temp basal suggestions. Uses the basal field from the treatment profile. Also uses the extended setting:

BASAL_RENDER (none) - Possible values are none, default, or icicle (inverted)

`bolus` (Bolus Rendering)

Settings to configure Bolus rendering

BOLUS_RENDER_OVER (0) - U value over which the bolus labels use the format defined in BOLUS_RENDER_FORMAT. This value can be an integer or a float, e.g. 0.3, 1.5, 2, etc.
BOLUS_RENDER_FORMAT (default) - Possible values are hidden, default (with leading zero and U), concise (with U, without leading zero), and minimal (without leading zero and U).
BOLUS_RENDER_FORMAT_SMALL (default) - Possible values are hidden, default (with leading zero and U), concise (with U, without leading zero), and minimal (without leading zero and U).

`connect` (Nightscout Connect)

Connect common diabetes cloud resources to Nightscout. Include the keyword connect in the ENABLE list. Nightscout connection uses extended settings using the environment variable prefix CONNECT_.

CONNECT_SOURCE - The name for the source of one of the supported inputs. one of nightscout, dexcomshare, etc...

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=

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 development, production, for api.glooko.work, and externalapi.glooko.com, respectively.
CONNECT_GLOOKO_SERVER the hostname server to use - api.glooko.com by default.

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.

`bridge` (Share2Nightscout bridge)

Deprecated Please consider using the connect plugin instead.

Fetch glucose reading directly from the Dexcom Share service, uses these extended settings:

BRIDGE_USER_NAME - Your username for the Share service.
BRIDGE_PASSWORD - Your password for the Share service.
BRIDGE_INTERVAL (150000 2.5 minutes) - The time (in milliseconds) to wait between each update.
BRIDGE_MAX_COUNT (1) - The number of records to attempt to fetch per update.
BRIDGE_FIRST_FETCH_COUNT (3) - Changes max count during the very first update only.
BRIDGE_MAX_FAILURES (3) - How many failures before giving up.
BRIDGE_MINUTES (1400) - The time window to search for new data per update (the default value is one day in minutes).
BRIDGE_SERVER (``) - The default blank value is used to fetch data from Dexcom servers in the US. Set to (EU) to fetch from European servers instead.

`mmconnect` (MiniMed Connect bridge)

Deprecated Please consider using the connect plugin instead.

Transfer real-time MiniMed Connect data from the Medtronic CareLink server into Nightscout (read more)

MMCONNECT_USER_NAME - Your user name for CareLink Connect.
MMCONNECT_PASSWORD - Your password for CareLink Connect.
MMCONNECT_INTERVAL (60000 1 minute) - Number of milliseconds to wait between requests to the CareLink server.
MMCONNECT_MAX_RETRY_DURATION (32) - Maximum number of total seconds to spend retrying failed requests before giving up.
MMCONNECT_SGV_LIMIT (24) - Maximum number of recent sensor glucose values to send to Nightscout on each request.
MMCONNECT_VERBOSE - Set this to "true" to log CareLink request information to the console.
MMCONNECT_STORE_RAW_DATA - Set this to "true" to store raw data returned from CareLink as type: "carelink_raw" database entries (useful for development).
MMCONNECT_SERVER - Set this to EU if you're using the European Medtronic services

`pump` (Pump Monitoring)

Generic Pump Monitoring for OpenAPS, MiniMed Connect, RileyLink, t:slim, with more on the way

Requires DEVICESTATUS_ADVANCED="true" to be set
PUMP_ENABLE_ALERTS (false) - Set to true to enable notifications for Pump battery and reservoir.
PUMP_WARN_ON_SUSPEND (false) - Set to true to get an alarm when the pump is suspended.
PUMP_FIELDS (reservoir battery) - The fields to display by default. Any of the following fields: reservoir, battery, clock, status, and device
PUMP_RETRO_FIELDS (reservoir battery clock) - The fields to display in retro mode. Any of the above fields.
PUMP_WARN_CLOCK (30) - The number of minutes ago that needs to be exceed before an alert is triggered.
PUMP_URGENT_CLOCK (60) - The number of minutes ago that needs to be exceed before an urgent alarm is triggered.
PUMP_WARN_RES (10) - The number of units remaining, a warning will be triggered when dropping below this threshold.
PUMP_URGENT_RES (5) - The number of units remaining, an urgent alarm will be triggered when dropping below this threshold.
PUMP_WARN_BATT_P (30) - The % of the pump battery remaining, a warning will be triggered when dropping below this threshold.
PUMP_URGENT_BATT_P (20) - The % of the pump battery remaining, an urgent alarm will be triggered when dropping below this threshold.
PUMP_WARN_BATT_V (1.35) - The voltage (if percent isn't available) of the pump battery, a warning will be triggered when dropping below this threshold.
PUMP_URGENT_BATT_V (1.30) - The voltage (if percent isn't available) of the pump battery, an urgent alarm will be triggered when dropping below this threshold.
PUMP_WARN_BATT_QUIET_NIGHT (false) - Do not generate battery alarms at night.

`openaps` (OpenAPS)

Integrated OpenAPS loop monitoring, uses these extended settings:

Requires DEVICESTATUS_ADVANCED="true" to be set
OPENAPS_ENABLE_ALERTS (false) - Set to true to enable notifications when OpenAPS isn't looping. If OpenAPS is going to offline for a period of time, you can add an OpenAPS Offline event for the expected duration from Careportal to avoid getting alerts.
OPENAPS_WARN (30) - The number of minutes since the last loop that needs to be exceed before an alert is triggered
OPENAPS_URGENT (60) - The number of minutes since the last loop that needs to be exceed before an urgent alarm is triggered
OPENAPS_FIELDS (status-symbol status-label iob meal-assist rssi) - The fields to display by default. Any of the following fields: status-symbol, status-label, iob, meal-assist, freq, and rssi
OPENAPS_RETRO_FIELDS (status-symbol status-label iob meal-assist rssi) - The fields to display in retro mode. Any of the above fields.
OPENAPS_PRED_IOB_COLOR (#1e88e5) - The color to use for IOB prediction lines. Colors can be in #RRGGBB format, but other CSS color units may be used as well.
OPENAPS_PRED_COB_COLOR (#FB8C00) - The color to use for COB prediction lines. Same format as above.
OPENAPS_PRED_ACOB_COLOR (#FB8C00) - The color to use for ACOB prediction lines. Same format as above.
OPENAPS_PRED_ZT_COLOR (#00d2d2) - The color to use for ZT prediction lines. Same format as above.
OPENAPS_PRED_UAM_COLOR (#c9bd60) - The color to use for UAM prediction lines. Same format as above.
OPENAPS_COLOR_PREDICTION_LINES (true) - Enables / disables the colored lines vs the classic purple color.

Also see Pushover and IFTTT Maker.

`loop` (Loop)

iOS Loop app monitoring, uses these extended settings:

Requires DEVICESTATUS_ADVANCED="true" to be set
LOOP_ENABLE_ALERTS (false) - Set to true to enable notifications when Loop isn't looping.
LOOP_WARN (30) - The number of minutes since the last loop that needs to be exceeded before an alert is triggered
LOOP_URGENT (60) - The number of minutes since the last loop that needs to be exceeded before an urgent alarm is triggered
Add loop to SHOW_FORECAST to show forecasted BG.

For remote overrides, the following extended settings must be configured:

LOOP_APNS_KEY - Apple Push Notifications service (APNs) Key, created in the Apple Developer website.
LOOP_APNS_KEY_ID - The Key ID for the above key.
LOOP_DEVELOPER_TEAM_ID - Your Apple developer team ID.
LOOP_PUSH_SERVER_ENVIRONMENT - (optional) Set this to production if you are using a provisioning profile that specifies production aps-environment, such as when distributing builds via TestFlight.

`override` (Override Mode)

Additional monitoring for DIY automated insulin delivery systems to display real-time overrides such as Eating Soon or Exercise Mode:

Requires DEVICESTATUS_ADVANCED="true" to be set

`xdripjs` (xDrip-js)

Integrated xDrip-js monitoring, uses these extended settings:

Requires DEVICESTATUS_ADVANCED="true" to be set
XDRIPJS_ENABLE_ALERTS (false) - Set to true to enable notifications when CGM state is not OK or battery voltages fall below threshold.
XDRIPJS_STATE_NOTIFY_INTRVL (0.5) - Set to number of hours between CGM state notifications
XDRIPJS_WARN_BAT_V (300) - The voltage of either transmitter battery, a warning will be triggered when dropping below this threshold.

`alexa` (Amazon Alexa)

Integration with Amazon Alexa, detailed setup instructions

`googlehome` (Google Home/DialogFLow)

Integration with Google Home (via DialogFlow), detailed setup instructions

`speech` (Speech)

Speech synthesis plugin. When enabled, speaks out the blood glucose values, IOB and alarms. Note you have to set the LANGUAGE setting on the server to get all translated alarms.

`cors` (CORS)

Enabled CORS so other websites can make request to your Nightscout site, uses these extended settings:

CORS_ALLOW_ORIGIN (*) - The list of sites that are allow to make requests

`dbsize` (Database Size)

Show size of Nightscout Database, as a percentage of declared available space or in MiB.

Many deployments of Nightscout use free tier of MongoDB Atlas on Heroku, which is limited in size. After some time, as volume of stored data grows, it may happen that this limit is reached and system is unable to store new data. This plugin provides pill that indicates size of Database and shows (when configured) alarms regarding reaching space limit.

IMPORTANT: This plugin can only check how much space database already takes, but cannot infer max size available on server for it. To have correct alarms and realistic percentage, DBSIZE_MAX need to be properly set - according to your mongoDB hosting configuration.

NOTE: This plugin rely on db.stats() for reporting logical size of database, which may be different than physical size of database on server. It may work for free tier of MongoDB on Atlas, since it calculate quota according to logical size too, but may fail for other hostings or self-hosted database with quota based on physical size.

NOTE: MongoDB Atlas quota is for all databases in cluster, while each instance will get only size of its own database only. It is ok when you only have one database in cluster (most common scenario) but will not work for multiple parallel databases. In such case, spliting known quota equally beetween databases and setting DBSIZE_MAX to that fraction may help, but wont be precise.

All sizes are expressed as integers, in Mebibytes 1 MiB == 1024 KiB == 1024*1024 B

DBSIZE_MAX (496) - Maximal allowed size of database on your mongoDB server, in MiB. You need to adjust that value to match your database hosting limits - default value is for standard Heroku mongoDB free tier.
DBSIZE_WARN_PERCENTAGE (60) - Threshold to show first warning about database size. When database reach this percentage of DBSIZE_MAX size - pill will show size in yellow.
DBSIZE_URGENT_PERCENTAGE (75) - Threshold to show urgent warning about database size. When database reach this percentage of DBSIZE_MAX size, it is urgent to do backup and clean up old data. At this percentage info pill turns red.
DBSIZE_ENABLE_ALERTS (false) - Set to true to enable notifications about database size.
DBSIZE_IN_MIB (false) - Set to true to display size of database in MiB-s instead of default percentage.

This plugin should be enabled by default, if needed can be diasabled by adding dbsize to the list of disabled plugins, for example: DISABLE="dbsize".

Extended Settings

Some plugins support additional configuration using extra environment variables. These are prefixed with the name of the plugin and a _. For example setting MYPLUGIN_EXAMPLE_VALUE=1234 would make extendedSettings.exampleValue available to the MYPLUGIN plugin.

Plugins only have access to their own extended settings, all the extended settings of client plugins will be sent to the browser.

DEVICESTATUS_ADVANCED (true) - Defaults to true. Users who only have a single device uploading data to Nightscout can set this to false to reduce the data use of the site.
DEVICESTATUS_DAYS (1) - Defaults to 1, can optionally be set to 2. Users can use this to show 48 hours of device status data for in retro mode, rather than the default 24 hours. Setting this value to 2 will roughly double the bandwidth usage of nightscout, so users with a data cap may not want to update this setting.

Pushover

In addition to the normal web based alarms, there is also support for Pushover based alarms and notifications.

To get started install the Pushover application on your iOS or Android device and create an account.

Using that account login to Pushover, in the top left you’ll see your User Key, you’ll need this plus an application API Token/Key to complete this setup.

You’ll need to Create a Pushover Application. You only need to set the Application name, you can ignore all the other settings, but setting an Icon is a nice touch. Maybe you'd like to use this one?

Pushover is configured using the following Environment Variables:

* `ENABLE` - `pushover` should be added to the list of plugin, for example: `ENABLE="pushover"`.
* `PUSHOVER_API_TOKEN` - Used to enable pushover notifications, this token is specific to the application you create from in [Pushover](https://pushover.net/), ***[additional pushover information](#pushover)*** below.
* `PUSHOVER_USER_KEY` - Your Pushover user key, can be found in the top left of the [Pushover](https://pushover.net/) site, this can also be a pushover delivery group key to send to a group rather than just a single user.  This also supports a space delimited list of keys.  To disable `INFO` level pushes set this to `off`.
* `PUSHOVER_ALARM_KEY` - An optional Pushover user/group key, will be used for system wide alarms (level > `WARN`).  If not defined this will fallback to `PUSHOVER_USER_KEY`.  A possible use for this is sending important messages and alarms to a CWD that you don't want to send all notification too.  This also support a space delimited list of keys.  To disable Alarm pushes set this to `off`.
* `PUSHOVER_ANNOUNCEMENT_KEY` - An optional Pushover user/group key, will be used for system wide user generated announcements.  If not defined this will fallback to `PUSHOVER_USER_KEY` or `PUSHOVER_ALARM_KEY`.  This also support a space delimited list of keys. To disable Announcement pushes set this to `off`.
* `BASE_URL` - Used for pushover callbacks, usually the URL of your Nightscout site, use https when possible.
* `API_SECRET` - Used for signing the pushover callback request for acknowledgments.

If you never want to get info level notifications (treatments) use `PUSHOVER_USER_KEY="off"`
If you never want to get an alarm via pushover use `PUSHOVER_ALARM_KEY="off"`
If you never want to get an announcement via pushover use `PUSHOVER_ANNOUNCEMENT_KEY="off"`

If only `PUSHOVER_USER_KEY` is set it will be used for all info notifications, alarms, and announcements

For testing/development try [localtunnel](http://localtunnel.me/).

IFTTT Maker

In addition to the normal web based alarms, and pushover, there is also integration for IFTTT Webhooks.

With Maker you are able to integrate with all the other IFTTT Services. For example you can send a tweet when there is an alarm, change the color of hue light, send an email, send and sms, and so much more.

Setup IFTTT account: login or create an account
Follow the Detailed IFTTT setup Instructions
Configure Nightscout by setting these webpage environment variables:

ENABLE - maker should be added to the list of plugins, for example: ENABLE="maker".
MAKER_KEY - Set this to your secret key (see [Detailed Instructions ) MAKER_KEY="abcMyExampleabc123defjt1DeNSiftttmak-XQb69p" This also supports a space delimited list of keys.
MAKER_ANNOUNCEMENT_KEY - An optional Maker key, will be used for system wide user generated announcements. If not defined this will fallback to MAKER_KEY. A possible use for this is sending important messages and alarms to another device that you don't want to send all notification too. This also support a space delimited list of keys.

Plugins can create custom events, but all events sent to IFTTT webhooks will be prefixed with ns-. The core events are:

ns-event - This event is sent to the maker service for all alarms and notifications. This is good catch all event for general logging.
ns-allclear - This event is sent to the maker service when an alarm has been ack'd or when the server starts up without triggering any alarms. For example, you could use this event to turn a light to green.
ns-info - Plugins that generate notifications at the info level will cause this event to also be triggered. It will be sent in addition to ns-event.
ns-warning - Alarms at the warning level with cause this event to also be triggered. It will be sent in addition to ns-event.
ns-urgent - Alarms at the urgent level with cause this event to also be triggered. It will be sent in addition to ns-event.
see the full list of events

Treatment Profile

Some of the plugins make use of a treatment profile that can be edited using the Profile Editor, see the link in the Settings drawer on your site.

Treatment Profile Fields:

timezone (Time Zone) - time zone local to the patient. Should be set.
units (Profile Units) - blood glucose units used in the profile, either "mg/dl" or "mmol"
dia (Insulin duration) - value should be the duration of insulin action to use in calculating how much insulin is left active. Defaults to 3 hours.
carbs_hr (Carbs per Hour) - The number of carbs that are processed per hour, for more information see #DIYPS.
carbratio (Carb Ratio) - grams per unit of insulin.
sens (Insulin sensitivity) How much one unit of insulin will normally lower blood glucose.
basal The basal rate set on the pump.
target_high - Upper target for correction boluses.
target_low - Lower target for correction boluses.

Some example profiles are here.

Setting environment variables

Easy to emulate on the commandline:

    echo 'MONGO_CONNECTION=mongodb://sally:[email protected]:99999/nightscout' >> my.env
    echo 'MONGO_COLLECTION=entries' >> my.env

From now on you can run using

    $ (eval $(cat my.env | sed 's/^/export /') && PORT=1337 node server.js)

Your hosting provider probably has a way to set these through their GUI.

Vagrant install

Optionally, use Vagrant with the included Vagrantfile and bin/setup.sh to install OS and node packages to a virtual machine.

host$ vagrant up
host$ vagrant ssh
vm$ ./bin/setup.sh

The setup script will install OS packages then run npm install.

The Vagrant VM serves to your host machine only on 192.168.33.10, you can access the web interface on http://192.168.33.10:1337

License

cgm-remote-monitor - web app to broadcast cgm readings
Copyright (C) 2017 Nightscout contributors.  See the COPYRIGHT file
at the root directory of this distribution and at
https://github.com/nightscout/cgm-remote-monitor/blob/master/COPYRIGHT

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published
by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

cgm-remote-monitor's People

Contributors

Stargazers

Watchers

Forkers

rqueen scottmark jolina utejahrmann wagnerpe grkacode emorin5305 permfam bagleytorri lakevue evankmarshall clayelmore brianhanifin jeffpchang satsumagurl14 rafaelomartin princsskik bscheure susanklip hoganboom33 lconaway altintx payne neallemmerman diabetes123 czettle eriaustin jenneee7 kramcgill nightscouttutorial nightscoutlouiep tomhadfield amonat baswieb jofth andrew3kids chadmmartin hwassink dexdom4d hariniv hawkeyegirl97 ksparling bmurphy1012 goblue939 fainaprager veggiemommy sarahsallade ballison41 kwcattle muffybear jennifershapiroortiz brownkkeb mmgirls lorenjon christian2008 kelliozdemir cadencgm aobcgm aaggzz987 jazzcgm nightscouttest hmm5388 r2linda martinrq tarheelpeele efincham bugalcaps maureenbouda pamamann edtorres1 diabmongo verhagenfamily susanoporter torresfamily fvsiegel copelandpatrick donatellapetretta jenandre1 drlisa lgmisla jayden928 jessicalowery bewest dboys2955 tutorea1 eplitt gregbe2000 diab123 rvcsouza ahuestis zkirk99 vandyjt t1scout lpels1 livyloo jolinahodgman addisonpaul denisemolloy rsuvalle walkingonthemoon

cgm-remote-monitor's Issues

Installation Instructions

Hi - I'm about 1 week into this, so I'm coming at this as a newbee to node.js, but with development background.

It may be me, my environment, or something - but e been working how to get cgm-remote-monitor to work. I've finally figured it, and wanted to share my feedback as I'm not sure whether it goes in the metasite (http://nightscout.github.io/posts/01-quickstart/) or here or in the rnpenguin/cgm-remote-monitor (https://github.com/rnpenguin/cgm-remote-monitor). I posted this in the latter, but then wasn't sure if that was the right spot.

I'll try to be as detailed as possible, but also write for the less technical.

My environment:

Windows 8.1 x64
Microsoft Azure hosting
Microsoft WebMatrix 3
Git Bash (http://msysgit.github.io/)
node.js (http://nodejs.org/download/)
Windows Azure Command Line & Powershell
So I started with the "let's do just the basics" to get the cgm-remote-monitor (Nightscout) up and running. I did this a couple of weeks ago using a "REV 0" installation guide. Somehow I got it to work, and since then, I've been piecing together a structured repeatable process so I can have a "staging" site for new code, etc.

Step 1: Using Nightscout Quickstart Guide (http://nightscout.github.io/posts/01-quickstart/)

When I do this, the process fails. I get an Azure "internal server error." To be clear, what I do is the following -- create a new website in Azure, configure the environment variables for mongodb and mongo_collection, setup source control deployment, choose GitHub, choose the cgm-remote-monitor and master fork, and then it does it's thing. Unfortunately, it doesn't work for me. I tried Azure East, Azure West, I tried the deployment multiple times since I figured "it worked for me once" this way, why not now. It must be me. At this point, I figured out how to get the FTP username for each of my Azure websites and downloaded them locally. I compared my working deployment website to my new website and the deployment files were different -- specifically the absence of "node_modules" directory and the absence of "bower_components" from the "new" non-working site. So I tried copying the two directories into the non-working site, uploaded to Azure, and it worked. So that gave me the source problem, but not the solution.

Step 2: Getting into Development mode
I downloaded and installed MS WebMatrix 3 and Git Bash as I read the other instructions which called for "npm" and "command line" interface. Maybe there's a way to get command line in Azure, but I couldn't find it. Somewhere in the process of downloading WebMatrix, node.js was downloaded and installed to my computer. So I figured out WebMatrix3, and got the "open from source control" and pulled the cgm-remote-monitor into a "local" test site. I did the 'run' and got the errors (as there were no "node_modules" nor "bower_components" folders.

Next I tried to figure out how to get the missing folders/files in there. I ran "npm install -g bower" from the WebMatrix3 local test website folder via command line. (\documents\mywebsites<test site). I got a TON of errors.

The top of the output told me that my "node.js" was 0.8.x, and the dependency was 0.10.x. Alright, so I found and downloaded the latest node.js (see environment above).

From there, going back to the documentation, my focus was on "npm install -g bower" in order to do "bower install".

After the upgrade to Node.js 0.10.x, I had to re-do "npm install -g bower" from anywhere on command line (for example, c:\temp). The "-g" installs the files into your 'globally' available node.js. OK. Next.

I still had the problem that the two directories were NOT in my test website. So at this point, I'm back to the installation guides within the "cgm-remote-monitor" GitHub repository (https://github.com/nightscout/cgm-remote-monitor) where I see -- in accordance with RTM -- "npm install". And magical... the two missing folders appear.

And now, things were starting to click. I was also able to quickly and easily modify the database configuration file, which means I no longer have to do it in the "Azure Management Portal."

So ... to wrap up... for most people, the Quick Start guide via the Azure Website deploy from GitHub and using the "Azure Management Portal" configuration for the database environment variables is clearly the most direct path -- but it isn't working for me, and the source goes back to the missing "node_modules" and "bower_components."

Is there a way to do the "npm install" on Azure that I'm missing? When I researched it, the only thing I found was the Azure cross-platform powershell and command line. If there's no way, then it seems like the easiest thing would be to put the two directories into the cgm-remote-monitor GitHub repository as it appears to be just doing an HTTP or FTP push of the files. But that goes against my development background. So that pushes me back to the WebMatrix3 and Git Bash, but that's the opposite of the "Azure Portal" directions.

Sorry for long question - I've been working on this for days, and it finally came together. I didn't update the document directly because I'm still not sure that I'm not missing something obvious.

Thanks!

Greg

Testing harness

A testing harness would allow for easy startup and debugging.
It could be either a mock db or just a mock data being sent from the server.
Also, accelerated time would allow features relying on data to be tested quicker.

Error Trapping on MONGO_COLLECTION variable

The Collection should be polled for the quantity of points before display is rendered. We can trap for 0, <3, or valid data instead of just displaying dashes on the rendering.

Trend line rendering issue when using Nightscout as a Home Screen App on iOS

If you save your Nightscout URL to the Home Screen on IOS, it opens full screen with no browser address bar. If the screen switches from portrait to landscape, then back to portrait, the trend line disappears. It will render properly again at the next refresh or when switching apps then back to Nightscout. The problem easily recurs if phone orientation switches the screen to landscape. A workaround is to turn on portrait screen lock.

theme, potentially "flair" support

Personally, I love the thought and design in the default theme. There are legitimate reasons for wanting to customize the theme.

The most compelling from a therapeutic perspective is:

I have installed multiple apps, how do I tell which `PWD` I'm monitoring?

An easy-ish way to handle monitoring multiple people at the same time is vary the theme, ideally with some distinguishing flair between them. Of course, it'd be nice if switching themes was a configurable option, light weight, easy to write and maintain, yada yada. It would also be nice, for the sake of parents monitoring multiple children, if some simple identifier, or flair could be added to the display to help distinguish between children. It would also be nice if these changes so happened to also support switching to eg, @jasoncalabrese 's "tropical" theme as well as potentially support other themes (I'm interested in a solarized theme). I was thinking that an idea code base would have one or maybe two "features" what would control all over this through some kind of css/bower overlay through simple environment variable switch or something. I have not managed to read up enough of @jasoncalabrese or @necroscope 's work to tell what exactly would be required or if it's possible to do in such a way.

24 Hour clock not applied to

Time on the bottom graph does not reflect the change to 24-hours when going into historical views.

Question on variable name spaces

Hey there - been working on consolidating the db config and the new bg thresholds into a single config file tonight. I modified server.js to suck in the name/value pairs. Where I'm stuck is figuring out how to get the "bgLow" and "bgHigh" variables accessible to /js/client.js... which is still executed on the server-side.

In my servlet and JSP days I had page and session and global contexts to place variables, but I can't quite figure out how to do it in this context. I'm new to node.js and searched around but there's a lot about Express, but it doesn't appear to be doing that.

Can you point me in the right direction? I'm really trying to get this done in order to make available "step 1" of the improved user configuration. I know discussion included a gui, putting into a db, etc... but I'm trying to take one step at a time.

Update 6/25 1pm ET: I went into client.js and replaced the bg values of 80 with "bgLow" and 180 with "bgHigh". Then I created two new variables within client.js (taking server.js out of the equation) for bgLow (70) and bgHigh (200) to visually confirm the lines on the graph are updated -- but they remain 80 and 180. So I'm trying to understand if I could be getting whacked by the nodeStatic caching? I can hit the /nightscout.appcache and see the cache configuration, and the setting is for 30 days or something.

Here's an example of what I'm doing...

// add a y-axis line that shows the low bg threshold
focus.append('line')
.attr('class', 'low-line')
.attr('x1', xScale(dataRange[0]))
.attr('y1', yScale(bgLow))
.attr('x2', xScale(dataRange[1]))
.attr('y2', yScale(bgLow))
// .attr('y2', yScale(80))
.style('stroke-dasharray', ('3, 3'))
.attr('stroke', 'grey');

So...

Am I editing the correct file (client.js)?
Is there a way to force clear the cache (rather than comment out the code)?

Thanks

Greg

Error Trapping on MONGO Variable

Remote monitor should validate the MONGO variable before attempting to use it. As it stands now, we get a 504 error if we are lucky, and a blank screen in many browsers.

Minor issue viewing Care Portal on IOS devices

After bringing up a care portal entry by tapping on the dot, I cannot get the pop up to go away unless I tap on another care portal entry, or manually refresh the browser window. Tapping another care portal entry just moves the active care portal popup, so the only real workaround is to refresh the browser window. The only way to refresh the screen in the full screen Home Screen view is to switch apps then back to Nightscout.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4250732-minor-issue-viewing-care-portal-on-ios-devices?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github).

Settings Interface

Obviously we are in the middle of refactoring of the API/DB code, but I wanted discuss how to provide an interface for users to customize their settings.

We could add it to the uploader app, or to the website. Would there be a time their kid is away from home and they want to switch their alert number range for example? Or would it be better for the interface be on the uploader phone?

If we want to add it to the website, maybe we could use a bar similar to these to add a settings button, and perhaps even one or more quick toggle type buttons (mobile audio enable/disable perhaps). It propose it would be a dark grey so it wouldn't distract from the important data.

High CPU usage when left open for several hours

Saw this on my wife's MBP after she said the battery was dying really fast...

help ensure cheap/free usage

mp3 alarms are the most expensive I/O

Suppress alarms when they are just eating bandwidth.

Deployment Fails on Azure

Hi,

Thanks so much for what you guys are doing with this project.

I'm having an issue trying to get this to deploy on Azure. Could you please review the error below. Thanks.

Command: bash deploy.sh
Handling node.js deployment.
KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot'
Using start-up script server.js from package.json.
Generated web.config.
Node.js versions available on the platform are: 0.6.17, 0.6.20, 0.8.2, 0.8.19, 0.8.26, 0.8.27, 0.10.5, 0.10.18, 0.10.21, 0.10.24, 0.10.26, 0.10.28, 0.10.29.
Selected node.js version 0.10.29. Use package.json file to choose a different version.
Updating iisnode.yml at D:\home\site\wwwroot\iisnode.yml
npm http GET https://registry.npmjs.org/body-parser
npm http GET https://registry.npmjs.org/bower
npm http GET https://registry.npmjs.org/errorhandler
npm http GET https://registry.npmjs.org/event-stream
npm http GET https://registry.npmjs.org/express-extension-to-accept
npm http GET https://registry.npmjs.org/express
npm http GET https://registry.npmjs.org/sgvdata
npm http GET https://registry.npmjs.org/mongodb
npm http GET https://registry.npmjs.org/socket.io
npm http 304 https://registry.npmjs.org/errorhandler
npm http 304 https://registry.npmjs.org/body-parser
npm http 304 https://registry.npmjs.org/express-extension-to-accept
An error has occurred during web site deployment.
npm http 304 https://registry.npmjs.org/bower
npm failed
npm http 304 https://registry.npmjs.org/express
npm http 304 https://registry.npmjs.org/sgvdata
npm http 304 https://registry.npmjs.org/mongodb
npm http 304 https://registry.npmjs.org/socket.io
npm http 304 https://registry.npmjs.org/event-stream
npm http GET https://registry.npmjs.org/express/-/express-4.8.3.tgz
npm http 200 https://registry.npmjs.org/express/-/express-4.8.3.tgz
npm ERR! Error: shasum check failed for C:\DWASFiles\Sites\juliecgm\Temp\npm-6984-W8igQesr\1407737516346-0.7824546734336764\tmp.tgz
npm ERR! Expected: a2c95b9079cda0473a04448f6b6c1e7fc20bf200
npm ERR! Actual: da39a3ee5e6b4b0d3255bfef95601890afd80709
npm ERR! From: https://registry.npmjs.org/express/-/express-4.8.3.tgz
npm ERR! at D:\Program Files (x86)\npm\1.4.10\node_modules\npm\node_modules\sha\index.js:38:8
npm ERR! at ReadStream. (D:\Program Files (x86)\npm\1.4.10\node_modules\npm\node_modules\sha\index.js:85:7)
npm ERR! at ReadStream.emit (events.js:117:20)
npm ERR! at _stream_readable.js:929:16
npm ERR! at process._tickCallback (node.js:419:13)
npm ERR! If you need help, you may report this entire log,
npm ERR! including the npm and node versions, at:
npm ERR! http://github.com/npm/npm/issues
npm ERR! System Windows_NT 6.2.9200
npm ERR! command "d:\Program Files (x86)\nodejs\0.10.29\node.exe" "D:\Program Files (x86)\npm\1.4.10\node_modules\npm\bin\npm-cli.js" "install" "--production"
npm ERR! cwd d:\home\site\wwwroot
npm ERR! node -v v0.10.29
npm ERR! npm -v 1.4.10
npm

Localization

As discussed with Ben and Kevin I would like to localize the three parts of Nightscout. I'm Italian and I'm supporting the Italian community in order to setup and manage Nightscout and I think it would beneficial for many to have a localized software.
I'm translating android-uploader in Italian and German via a German friend of mine.

I'm not sure how to do it for cgm-remote-monitor but maybe with a choice in the setup.

I hope I'm using the right tool to start a discussion and keep track of changes, if not please let me know.

Ivan

Release 0.3.x Issues

If you are having difficulty with one of the v0.3.x website releases here are some things to try:

The previous version of the site was too aggressive with caching the files used by the site. Important changes may not be downloaded to your browser, which would cause problems. Try viewing the site in Private Browsing or Incognito Mode. (Thanks Josh Corwin for sharing this.)
The new settings feature requires cookies, so please enable cookies. Version 0.3.4 handles this error so the data can display despite disabled cookies. (Thanks Ben West for discovering this.)
If you only see a chart, and are using Dolphin browser, upgrade your site to at least version 0.3.3 for the layout fix.
If you only see a chart, and are using a "Stock Android Browser" of some variety, please switch to Google Chrome. I do not have access to those browsers for testing. So until a developer with access to those browsers can edit the code to help us, Chrome is your best bet.

If after trying the above suggestions you still have a problem, please either post about it below. Be sure to include:

Browser name (e.g. Chrome, Safari, Firefox, Internet Explorer, Dolphin).
Platform (e.g. Windows, Mac, iPhone, Android, etc.).

Thank you everyone for your patience. This just proves how experimental all of this is, and how important it is to have as many people try out the new site as possible. The more quickly someone reports a problem, the quicker we can discover a solution.

/lib/pebble.js

Hey there - as I look to modify the cgm-pebble community code for the trend arrow, I started with input from cgm-remote-monitor /lib/pebble.js. A couple of questions to make sure I'm tracking things correctly before I start mod'ing code.

The db query for the collection pulls the last 10, but the output via pebble.js is explicitly cgmData.slice(0,6). I am assuming this is for performance to limit the amount of data pulled and processed. Can you confirm?
The JS file defines 40 minutes in milliseconds (2400000), but then in the function multiples by 5. So it could go back 200 minutes. But if the output is limited to 6, can you help me understand why the 40 minutes much less the 200 minutes? Could simply be moving parts, but I want to ensure I'm not missing a subtle data control.
The file has DIRECTIONS defined [0-9]. Do people have a preference for determining trend? The simplest is to take (now) - (last) / array length. But since you're already looping for direction, I could take the sum of each "direction" and average, and then round. A final model would be to simply show the "direction" for the last BG. Personally, I think the trend needs to be the average to account for ups and downs, but since the direction is already calculated in this file per BG, that may have been the thinking to date. ??
I noticed that when things are forecasted, my dexcom-uploader registers "10" as the BG rather than "???" from my Dexcom. Not having read through Dexcom-uploader yet, are there any business logic rules that need to be accounted for? For example, if "now" is BG 10, then stop b/c the data is bad. Or, if slice 3 is BG 10, then stop the averaging there? Likewise, it looks like direction value 8 and 9 would be cases for exception processing.
Rather than having the pebble watch face JS calculate the overall trend, I'm thinking about extending the /lib/pebble.js response to include that after the BGs -- let the appservers do the processing, pass the single value, and let cgm-pebble display. I started with the mindset of modifying the cgm-pebble codebase for everything, but tonight I'm viewing "cgm-pebble" like the View of MVC whereas "cgm-remote-monitor" is the Control in relation to pebble.

Thanks for your thoughts!

Greg ([email protected])

Dev Branch display Version Number

Dev Branch should reflect Dev/beta in the About version number to aid support personnel.

Enhancement - Design Input

Hey all - now that I've resolved my "vanishing arrows" due to my dexcom-uploader... I saw a notification come in tonight re: client.js and BG thresholds. (https://github.com/aaronjknox/cgm-remote-monitor)

I'm happy to attack this one, but would like group perspective -- to me, the BG high and low is a threshold that will be highly varied by person and style. So, to me, that is a prime candidate for an environment variable / configuration file.

What I would really like to do is rename the "database_configuration.json" to "application_variables.json" and make it a generic properties file... and then put the BG High and Low in there... a single parameter file, all loaded via server.js.

If the group doesn't like that, then Plan B would be a "bg_threshold_configuration.json" file that would contain BG High and Low values... again, loaded by server. js.

I'm a node.js rookie, so I'm assuming that I can load variables into "session namespace" via server.js and have them available to client.js... but if not, then I'd have to put the require statement in client.js.

Thoughts before I branch off and do it?

Greg

Low Alarm Not Working

Overnight last night, BG was <80 for an extended period. Rose to over 80, then back down again for a few hours. The low alarm never went off. I asked someone else to verify on their computer if the alarm was working for them viewing my site. It was not.

I was able to look at our computer and verified that the alarm was not working, even though the alarm was enabled and had been open to our site all night.

High Alarm alarms when it shouldn't

Jason -
Testing the develop branch. On computer (and phone and kindle tablet), I get the high alarm even when I have the control set for no high alarm, and I also added the "mute=true" to the URL. I've been away from computer all day, so I don't know if there was a session timeout or something that led to the high alarm alarming.

But when I hit enter and the URL in the browser, the alarming went away.

Screenshot of alarming included.

Greg

Dev Branch - Says "High" When scrolling through history

Time formats and structure differ between Mongo Collections

Hi, I'm new to the project and just starting to unwrap the data but I noticed that time is recorded in a few different ways. It would be ideal if it was standardized and documented (which format etc...). Hope this helps! I'm a big fan of this project.

Below is what I've observed:

CGM
{
...
"date": 1414370037000,
"dateString": "10/26/2014 08:33:57 PM",
...
}
devicestatus
{
...
"created_at": {
"$date": "2014-10-22T23:44:58.135Z"
}
...
}
treatment
{
...
"created_at": "2014-10-23T01:55:13.636Z",
...
}

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

New Care Portal Treatment Types - Temp Basal Start and Stop

I am very new to this group and am just getting my development environment setup and running, but I wanted to request (and prototype) a very minor addition to the care portal functionality. I was not sure exactly what changes would be required so I waited until it was running on my machine before posting here.

To maintain my son's BG using an Omnipod, we use a combination of Bolus' and Temp Basal's, so I wanted to discuss the supporting the tracking of the Temp Basal's in addition to the bolus entries already in the care portal.

So, I got the code and created a branch wip/basal, and figured out that the change was VERY simple (with the assumption that the Insulin Given would be reused and no unique field for the time period).

I tested the setup with MongoLab database and both Azure and my local Node.js and the entries came across as expected.

Anyway, I wanted to throw this up to you all for discussion. Also, I do not know how to show/point you to my branch (or if you can see it automatically).

Let me know your thoughts.

Michael McArthur

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4500649-new-care-portal-treatment-types-temp-basal-start-and-stop?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github).

Configurable history in node application?

Is it possible to configure the number of days displayed in the node application? Possibly a historical view, somehow, weekly, monthly, etc.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/5015622-configurable-history-in-node-application?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F2451736&utm_medium=issues&utm_source=github).

dev branch - mmol

no dots show when you switch to mmol in dev

CGM Data collection standardization?

Does it still make sense to have each user create a custom collection name for their CGM data? With the recent push towards API standards that create their own collections (devicestatus, treatments), is it worth considering automatically creating a "cgmdata" collection instead of a custom name? It would simplify the Mongo URI somewhat. I'm not sure how invasive this change would be given that so many people already have working (but non-standard) data collections.

Question on Development Setup

Sorry for opening an issue, but was not sure of the best method to touch base with all the developers. Figured Facebook would not be a good place to pose this type of question. Let me know if there is a forum better suited to a technical discussion on Nightscout.

I am setting up a development environment and had a question on the Node.j configuration that I have not been able to figure out.

I have Node.j up and running, connected to Mongo and pulling the data. What I can not determine is how to configure the CarePortal and API Secret on my Windows 8.1 machine. I looked through the javascript code, but could not determine where those variables were actually pulled from.

Thanks,

Michael McArthur

IE11 compatibility

The vertical resizing problem in IE11 appears to be due to failure of this line in client.js to retrieve the correct chartHeight:

var chartHeight = (document.getElementById('chartContainer').getBoundingClientRect().height) - padding.top - padding.bottom;

Whereas the prior line retrieves the correct chartWidth (always returns an integer that varies with window size), the chartHeight always returns 54.69000244140625 regardless of window height when using IE11.

In Chrome, chartHeight returns the expected integer value, which is why it works in Chrome.

Increased data use with websockets

I heard some users have hit data caps post-Cookie Monster updates. It appears that Cookie Monster uses ~5x Azure data out per idle browser remote monitor with Websockets enabled. (tested on Mac / Firefox 33, Windows 7 / IE10). This does not include uncached or cached browser session starts or manual browser refreshes.

I measured a websockets enabled CM site @ ~640 bytes/sec, websockets disabled CM site @ 143 bytes/sec, and a Brownie site @ 140 bytes/sec. Those figures are from Wireshark for at least 10 minutes per session, filtered with "ip.src == $AZURE_IP" to remove browser ACKs and other client > server overhead from the throughput figures.

Those figures translate to ~52 MB/day for Websockets, ~11.7 MB/day XHR polling w/ HTTPS, ~11.5 MB/day XHR polling w/ HTTP.

You can download my packet captures from http://bit.ly/1zFlllO

You can test yourselves using the following sites:

http://http-brownie.azurewebsites.net - Brownie 0.4.3
https://https-cookie.azurewebsites.net - CM 0.5.0 w/ Websockets
https://https-cookie-nows.azurewebsites.net - CM 0.5.0 w/o Websockets

All sites use the same Mongo store, my dev/test rig with live data. Data out for these sites is purely monitoring, no REST uploads.

Collection architecture for "devicestatus" and "treatments" breaks existing "multi-T1" deployments

Just ran into this when helping a multi-t1d family upgrade to Brownie (0.4.2). Starting with 0.4.0, the architecture assumes that the "database" is a single human being.

Currently, a lot of the multi-t1d deployments have a single database with 2 collections -- one per kid. When these people upgrade to Brownie, nothing will break, but their data will unknowingly wrong. The two "systems" (rigs + CPs) will write to a common collection respectively.

The uploader has a parameter setting for "devicestatus" but if you change that, there's no way in the website configuration to tell it to use "kid1DeviceStatus" without changing the code -- which will create problems for future releases and merging.

Additionally, the "treatments" collection for Care Portal does not have a configurable option for "kid1" vs. "kid2". As such, multiple websites using same "db" with different collections for kids will overlap each other.

Workaround - move 2nd kid to separate database within Mongo. (assuming MongoDB URI since most people have not adopted REST API yet).

Create new database with user/pwd
In Mongo, copy existing collection in db1 to new collection name in db2
Reconfigure uploader2 for new db2 with new collection name (note... collection could remain the same)
Reconfigure website for new mongo db uri with db2 and mongo_collection (if changed)

Recommended enhancement:

Make "devicestatus" a connection string DEVICESTATUS_COLLECTION.
Make "treatments" a connection string "TREATMENTS_COLLECTION".

I would prefer to put the collection parameters in the APP CONFIG but that would require moving mongo_collection to "APP CONFIG" to ensure consistency. Otherwise, put in connection string" in order to maintain "this kind of info goes here; that kind of info goes there."

Thanks.

Greg

there isn't anything to compare

We couldn't figure out how to compare these references, do they point to valid commits?

It then gives me a list to review?

 dev 3 hours ago
 wip/mbg 8 days ago
 wip/feeds 15 days ago
 wip/has_feature on Aug 11
 wip/spinner on Aug 3
 master@{1day}...master 24 hours ago

dev branch-CarePortal Mongolab Collections

Need to tie Careportal entries back to original SVG collection to allow for users with multiple T1s running in a single DB instance.

Error installing Kudu Sync

Hi, I get this error running the deploy script

Installing Kudu Sync

An error has occurred during web site deployment.
npm failed

Running npm install kudusync -g on the terminal (the command in deploy.sh that fails), I get this:

npm http GET https://registry.npmjs.org/kudusync

npm ERR! Error: failed to fetch from registry: kudusync
npm ERR!     at /usr/share/npm/lib/utils/npm-registry-client/get.js:139:12
npm ERR!     at cb (/usr/share/npm/lib/utils/npm-registry-client/request.js:31:9)
npm ERR!     at Request._callback (/usr/share/npm/lib/utils/npm-registry-client/request.js:136:18)
npm ERR!     at Request.callback (/usr/lib/nodejs/request/main.js:119:22)
npm ERR!     at Request.<anonymous> (/usr/lib/nodejs/request/main.js:212:58)
npm ERR!     at Request.emit (events.js:88:20)
npm ERR!     at ClientRequest.<anonymous> (/usr/lib/nodejs/request/main.js:412:12)
npm ERR!     at ClientRequest.emit (events.js:67:17)
npm ERR!     at HTTPParser.onIncoming (http.js:1261:11)
npm ERR!     at HTTPParser.onHeadersComplete (http.js:102:31)
npm ERR! You may report this log at:
npm ERR!     <http://bugs.debian.org/npm>
npm ERR! or use
npm ERR!     reportbug --attach /vagrant/npm-debug.log npm
npm ERR! 
npm ERR! System Linux 3.2.0-23-generic
npm ERR! command "node" "/usr/bin/npm" "install" "kudusync" "-g"
npm ERR! cwd /vagrant
npm ERR! node -v v0.6.12
npm ERR! npm -v 1.1.4
npm ERR! message failed to fetch from registry: kudusync
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /vagrant/npm-debug.log
npm not ok

Here's a /vagrant/npm-debug.log:

vagrant@precise64:/vagrant$ cat npm-debug.log 
info it worked if it ends with ok
verbose cli [ 'node', '/usr/bin/npm', 'install', 'kudusync', '-g' ]
info using [email protected]
info using [email protected]
verbose config file /home/vagrant/.npmrc
verbose config file /usr/etc/npmrc
verbose config file /usr/share/npm/npmrc
verbose cache add [ 'kudusync', null ]
silly cache add: name, spec, args [ undefined, 'kudusync', [ 'kudusync', null ] ]
verbose parsed url { pathname: 'kudusync', path: 'kudusync', href: 'kudusync' }
verbose addNamed [ 'kudusync', '' ]
verbose addNamed [ null, '' ]
silly name, range, hasData [ 'kudusync', '', false ]
verbose raw, before any munging kudusync
verbose url resolving [ 'https://registry.npmjs.org/', './kudusync' ]
verbose url resolved https://registry.npmjs.org/kudusync
http GET https://registry.npmjs.org/kudusync
ERR! Error: failed to fetch from registry: kudusync
ERR!     at /usr/share/npm/lib/utils/npm-registry-client/get.js:139:12
ERR!     at cb (/usr/share/npm/lib/utils/npm-registry-client/request.js:31:9)
ERR!     at Request._callback (/usr/share/npm/lib/utils/npm-registry-client/request.js:136:18)
ERR!     at Request.callback (/usr/lib/nodejs/request/main.js:119:22)
ERR!     at Request.<anonymous> (/usr/lib/nodejs/request/main.js:212:58)
ERR!     at Request.emit (events.js:88:20)
ERR!     at ClientRequest.<anonymous> (/usr/lib/nodejs/request/main.js:412:12)
ERR!     at ClientRequest.emit (events.js:67:17)
ERR!     at HTTPParser.onIncoming (http.js:1261:11)
ERR!     at HTTPParser.onHeadersComplete (http.js:102:31)
ERR! You may report this log at:
ERR!     <http://bugs.debian.org/npm>
ERR! or use
ERR!     reportbug --attach /vagrant/npm-debug.log npm
ERR! 
ERR! System Linux 3.2.0-23-generic
ERR! command "node" "/usr/bin/npm" "install" "kudusync" "-g"
ERR! cwd /vagrant
ERR! node -v v0.6.12
ERR! npm -v 1.1.4
ERR! message failed to fetch from registry: kudusync
verbose exit [ 1, true ]

Any idea what's wrong? I'm not familiar with node / npm.

Color on BG trend line dims over time

When viewing Nightscout in a browser window, the trend line color dims. The recent BG readings dim from bright green to a darker green. The BG cone prediction dims from a bright light blue to a dim blue. This only occurs if the browser window is refreshing automatically. If I do a manual refresh, the BG trend line and cone render properly. Running the latest dev, color, mg/dl.

Version Control in Display

With multiple users and builds in play, we need to include a version number at the bottom of the page to aid in debugging end users.

support mmol

Support for mmol.

Does not work in internet explorer.

Hi,
I fixed this and I posted code in the core dev google groups. We are just testing this on a few more devices but will submit code here soon!

Now line is 10 minutes in the future.

Now line is showing 10 minutes in the future. Blue dots are also appearing flat and not sloping correctly. This is all since I editing code to make it mmol in Master

https://github.com/Dexcgm/cgm-remote-monitor.git
Any help would be greatly appreciated.

nightscout.appcache makes changes to index.html very hard

@brianhanifin I'm thinking about pulling nightscout.appcache out. I really had to fight chrome to get rid of it yesterday, and I don't think we need it for the mp3's.

Supress data when there is no current data?

I would like to propose that when there is no current data, that the graph and BG value be suppressed entirely and a message "No data" be displayed. Currently the dots are blue and I think the BG may have a strikethrough in some versions, but this may not be enough warn the user. Not sure if this has been suggested already so feel free to remove this if it has been.

Question on new checkmark and music note

feel like a stupid question - but what does the checkmark vs. the music note do now in the interface? If I click on them, they play the alarm once. Haven't been able to play the combinations from computer vs. phone, during high vs. low, etc.

I know the code is
✓♪

So I think it's just to test it manually... just confirming.

pebble endpoint does not support trend

As a result the pebble watchface does not draw arrows, and people do love the arrows.

Dev Branch Azure Deployment Fail

New website in Azure. Pulled new "dev" branch. Deployment fails, but says "successful". Website will not load (http://gcwtest.azurewebsites.net).

Attached are:

Deployment Log
App Server Logs
Screen snip of my GitHub repo to show that I am current

// Deployment Log
Command: bash deploy.sh
Handling node.js deployment.
KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot'
Using start-up script server.js from package.json.
Generated web.config.
Node.js versions available on the platform are: 0.6.17, 0.6.20, 0.8.2, 0.8.19, 0.8.26, 0.8.27, 0.8.28, 0.10.5, 0.10.18, 0.10.21, 0.10.24, 0.10.26, 0.10.28, 0.10.29, 0.10.31.
Selected node.js version 0.10.31. Use package.json file to choose a different version.
Updating iisnode.yml at D:\home\site\wwwroot\iisnode.yml

[email protected] postinstall d:\home\site\wwwroot
node node_modules/bower/bin/bower install
npm WARN unmet dependency d:\home\site\wwwroot\node_modules\bower\node_modules\insight\node_modules\inquirer\node_modules\cli-color\node_modules\d requires es5-ext@'~0.10.2' but will load
npm WARN unmet dependency undefined,
npm WARN unmet dependency which is version undefined
npm WARN unmet dependency d:\home\site\wwwroot\node_modules\bower\node_modules\insight\node_modules\inquirer\node_modules\cli-color\node_modules\memoizee requires es5-ext@'~0.10.4' but will load
npm WARN unmet dependency undefined,
npm WARN unmet dependency which is version undefined
npm WARN unmet dependency d:\home\site\wwwroot\node_modules\bower\node_modules\insight\node_modules\inquirer\node_modules\cli-color\node_modules\timers-ext requires es5-ext@'~0.10.2' but will load
npm WARN unmet dependency undefined,
npm WARN unmet dependency which is version undefined
npm WARN unmet dependency d:\home\site\wwwroot\node_modules\bower\node_modules\insight\node_modules\inquirer\node_modules\cli-color\node_modules\memoizee\node_modules\event-emitter requires es5-ext@'~0.10.2' but will load
npm WARN unmet dependency undefined,
npm WARN unmet dependency which is version undefined
npm WARN unmet dependency d:\home\site\wwwroot\node_modules\bower\node_modules\insight\node_modules\inquirer\node_modules\cli-color\node_modules\memoizee\node_modules\lru-queue requires es5-ext@'~0.10.2' but will load
Finished successfully.
npm WARN unmet dependency undefined,
npm WARN unmet dependency which is version undefined

// App Server Logs
Application has thrown an uncaught exception and is terminated:
Error: Cannot find module 'zeparser'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (D:\home\site\wwwroot\node_modules\socket.io\node_modules\socket.io-client\node_modules\active-x-obfuscator\index.js:1:78)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)

// GitHub Repo Screenshot

Add Documentation

This project could use a lot more documentation. I believe that as a community it's something we can get started on.

Describe the ways that you can obtain CGM data, how it goes into the mongo instance, etc. A simple "How to get started" from a clone -> look at data perspective.

Care Portal

Treatment dot does not show up when entered in Chrome on mac.

{
"enteredBy": "Kate",
"eventType": "BG Check",
"glucose": "2.2",
"glucoseType": "Finger",
"carbs": "20",
"insulin": "",
"notes": "Pop",
"created_at": "2014-09-09T20:17:35.749Z",
"_id": {
"$oid": "540f605f52527df016f2495d"
}
}

Care Portal: No decimal point in Carb, Insulin Given fields

On my Samsung Galaxy S3 running Kit Kat, I get a numeric keypad when entering data in the Carb and Insulin Given fields on the Care Portal form. There is no way to add a decimal point. Probably not a big deal for carbs, but entering fractional units of insulin should be an option.

I'm not sure if this is specific to the S3 because I remember entering CP entries with fractional units on Android tablets at Best Buy last week. This problem doesn't occur on IOS.

Clock / Android Widget UI

Update: corrected typo. Changes in bold.

Create a separate people like the Pebble Watchface (at /basic?) that omits the chart portion of the full site. This would be perfect for displaying in Android widgets.

cross-browser interop

@necroscope has some useful things in progress already!

rnpenguin/cgm-remote-monitor#19

Test data option

I have the system up and running but I have yet to connect to the Dexcom (because it is with my daughter at camp :) ). Even with that not being the case, I think it would be very cool to modify the doReadAndUpload to check for a useTestData flag and send some garbage data from the android app to the cloud so that we can test prior to taking the final step of connecting to the Dex.

Overall, I am really psyched about this!!

Automatically silence alarm when SGV goes back into acceptable range

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.
Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
TensorFlow

An Open Source Machine Learning Framework for Everyone
Django

The Web framework for perfectionists with deadlines.
Laravel

A PHP framework for web artisans
D3

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
web

Some thing interesting about web. New door for the world.
server

A server is a program made to process requests and deliver data to clients.
Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Visualization

Some thing interesting about visualization, use data art
Game

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft

Open source projects and samples from Microsoft.
Google

Google ❤️ Open Source for everyone.
Alibaba

Alibaba Open Source for everyone
D3

Data-Driven Documents codes.
Tencent

China tencent open source team.

Jobs

Jooble

nightscout / cgm-remote-monitor Goto Github PK

cgm-remote-monitor's Introduction

Nightscout Web Monitor (a.k.a. cgm-remote-monitor)

Looking for documentation?

End user?

Developer?

#WeAreNotWaiting and this is why.

Install

Supported configurations:

Recommended minimum browser versions for using Nightscout:

Installation software requirements:

Installation notes for users with nginx or Apache reverse proxy for SSL/TLS offloading:

Installation notes for Microsoft Azure, Windows:

Development

Usage

Updating my version?

Configure my uploader to match

Nightscout API

Example Queries

Environment

Required

Features

Data Rights

Alarms

Core

Predefined values for your browser settings (optional)

Predefined values for your server settings (optional)

Views

Split View

Plugins

Default Plugins

delta (BG Delta)

direction (BG Direction)

upbat (Uploader Battery)

timeago (Time Ago)

devicestatus (Device Status)

errorcodes (CGM Error Codes)

ar2 (AR2 Forecasting)

simplealarms (Simple BG Alarms)

profile (Treatment Profile)

Advanced Plugins:

careportal (Careportal)

boluscalc (Bolus Wizard)

food (Custom Foods)

rawbg (Raw BG)

iob (Insulin-on-Board)

cob (Carbs-on-Board)

bwp (Bolus Wizard Preview)

cage (Cannula Age)

sage (Sensor Age)

iage (Insulin Age)

bage (Battery Age)

treatmentnotify (Treatment Notifications)

basal (Basal Profile)

bolus (Bolus Rendering)

connect (Nightscout Connect)