Giter Site home page Giter Site logo

tidepool-org / uploader Goto Github PK

View Code? Open in Web Editor NEW
118.0 42.0 84.0 163.86 MB

An Electron app for uploading diabetes device data to Tidepool's backend

License: BSD 2-Clause "Simplified" License

Shell 0.27% HTML 0.04% JavaScript 96.37% NSIS 0.07% Lua 0.43% Dockerfile 0.05% Less 2.76%

uploader's Introduction

Tidepool Uploader

CircleCI

This is an Electron App that acts as an uploader client for Tidepool. It is intended to allow you to plug diabetes devices into your computer's USB port, read the data stored on them, and upload a standardized version of the data to the Tidepool cloud.

This README is focused on just the details of getting the uploader running locally. For more detailed information aimed at those working on the development of the uploader, please see the developer guide.

Table of contents


How to set it up

  1. Clone this repository.
  2. Make sure you have node v16.x installed. If you are managing node installations with nvm, which we highly recommend, you can just do nvm use when navigating to this repository to switch to the correct version of node. (In this repository, the correct version of node will always be the version of node packaged by the version of Electron that we are using and specified in the .nvmrc file.)
  3. Run npm install or, preferably, yarn
  4. Set the config for the environment you want to target (see Config below)
  5. Run the following command:
$ npm run dev

or

$ yarn dev

(This will bundle the application with webpack and watch for changes. When it stops printing output you can continue to the next step.)

NB: React components and CSS will hot load after changes (this can be confirmed by watching the JavaScript console), but changes to device drivers and other code outside of the React components will not - use 'Reload' to reload after such changes. If the compilation/hot reload of a component fails for any reason (e.g. from a syntax error) you may need to reinitialize the hot loader by reloading the application.

Docker for Linux

If you are running Linux you probably need to be using an Ubuntu distribution or derivative. To get around this for other distrubutions you can try to build a local docker image which is based on Ubuntu 18.04 and use the yarn/npm commands interactively.

NOTE: You need to add udev rules to your host for uploads to actually work. You can find the udev rules here. The file should be placed in /etc/udev/rules.d/ and the host should be rebooted.

  1. Build the image docker-compose build

  2. Run it docker-compose up -d

  3. Work with it interactively.

    Even if you kill the Tidepool Uploader GUI the container will continue to run. You can work with the yarn commands like you would locally by using docker exec.

    Examples

    Interactively select the yarn target: docker exec -it uploader bash -c "yarn run"

    Rebuild: docker exec -it uploader bash -c "yarn build"

    Start the Dev GUI: docker exec -it uploader bash -c "yarn dev"

Config

Configuration values (for example the URL of the Tidepool Platform) are set via environment variables. If you need to add a config value, modify the .config.js file. If you need to read a config value inside the app, use var config = require('./lib/config'). To set config values (do this before building the app), you can use Shell scripts that export environment variables (see config/local.sh for an example that exports the appropriate variables when running the whole Tidepool platform locally using runservers), for example:

$ source config/local.sh
$ yarn start

Debug Mode(s)

For ease of development we have several debug features that developers can turn on and off at will (and to suit various development use cases, such as working on a new device driver versus working on the app's UI). Each of these debug features is set with an environment variable, but rather than being loaded through .config.js (as we do for production configuration variables, see above), we load these through the webpack DefinePlugin (see Pete Hunt's webpack-howto for an example, although note Hunt uses the term 'feature flag').

DEBUG_ERROR

The environment variable DEBUG_ERROR (boolean) controls whether or not errors sourced in device drivers are caught and an error message displayed in the UI (the production setting) or whether they are thrown in the console (much more useful for local development because then the file name and line number of the error are easily accessible, along with a stack trace). DEBUG_ERROR mode is turned on by default in config/device-debug.sh.

This can also be toggled internally in the running Electron app via a right-click context menu available on the login screen, much like the menu for switching environments.

Local Development w/o Debug Mode(s)

All debug options are turned off by default in config/local.sh.

Tests

To run the tests in this repository as they are run on CircleCI use:

$ yarn test

or

$ yarn test

Linting & Code Style

We use ESLint to lint our JavaScript code. We try to use the same linting options across all our client apps, but there are a few exceptions in this application, noted with comments in the .eslintrc configuration file.

To run the linter (which also runs on CircleCI with every push, along with npm test), use:

$ npm run lint

Aside from the (fairly minimal) JavaScript code style options we enforce through the linter, we ask that internal developers and external contributors try to match the style of the code in each module being modified. New modules should look to similar modules for style guidance. In React component code, use existing ES6/ES2015 components (not legacy ES5 components) as the style model for new components.

NB: Please keep ES5 and ES6/ES2015 code distinct. Do NOT use ES6/ES2105 features in ES5 modules (most easily recognizable by the use of require rather than import).

Docs

Docs reside in several places in this repository, such as docs/ and lib/drivers/docs. They are built as a static site with GitBook and served at developer.tidepool.org via GitHub Pages.

See this guidance on our use of GitBook at Tidepool.

Publishing

This section is Tidepool-specific. Release management and application updates are handled via the Github provider in the electron-builder project. The recommended workflow for a new production release is as follows:

  1. When you're working on what might become a new release, increment the version number in package.json and app/package.json and commit/push (on the branch)
  2. The CI server will create a draft release in Github with the title of the version from the package.json file and will automatically attach the distribution artifacts to that draft (drafts are not publicly visible)
  3. When your pull request is approved and merged to master, go to the draft release and type in the version for the tag name, ensure that you're targeting the master branch, fill out the release notes and publish the release. This will create the tag for you.

For a non-production release (alpha, dev, etc.)

  1. Increment the version number in package.json and app/package.json and ensure that you have included the channel information after the version patch number (i.e. v0.304.0-alpha or v0.304.0-beta.2). The hyphen separated version semantic is important.
  2. The CI server(s) will create a draft release in Github with the title of the version from the package.json file and will automatically attach the distribution artifacts to that draft (drafts are not publicly visible)
  3. When you want to publish your non-production release, go to your draft and type in the version for the tag name, ensure that you're targeting the branch that you're currently releasing from, mark the release as a pre-release, fill out the release notes and publish the release. This will create the tag for you on the branch that you want.

The Uploader has a self-update mechanism that will look at the latest release and compare versions, downloading and prompting the user to update if a newer version is available. For production releases, only official releases will be considered. For non-production releases (-alpha, -beta.2, etc.) releases marked as pre-release will also be checked, matching against the string portion of the post-hyphen version segment. For more detail about this behavior see the electron-builder docs concerning auto-update options

CI server environment variables

We use the following environment variables on the CI server:

Variable OS Image Use
APPLEID MacOS Notarization
APPLEIDPASS MacOS Notarization
TEAMID MacOS Notarization
AWS_ACCESS_KEY_ID Both S3 builds and AV e-mails
AWS_SECRET_ACESS_KEY Both S3 builds and AV e-mails
CSC_FOR_PULL_REQUEST Both true, code signing for PR
CSC_KEY_PASSWORD MacOS Certificate password
CSC_LINK MacOS Code signing certificate
WIN_CSC_KEY_PASSWORD Windows Certificate password
WIN_CSC_LINK Windows Code signing certificate
DEBUG MacOS Set to electron-builder
GH_TOKEN Both For GitHub builds
PUBLISH_FOR_PULL_REQUEST Both true, build artefact for PR
ROLLBAR_POST_TOKEN Both Rollbar logging
FTP_AV_PASSWORD_TIDEPOOL Windows AV submission

Editor Configuration

Atom

apm install editorconfig es6-javascript javascript-snippets linter linter-eslint language-babel autocomplete-modules file-icons

Sublime

Others

DevTools

Toggle Chrome DevTools

  • OS X: Cmd Alt I or F12
  • Linux: Ctrl Shift I or F12
  • Windows: Ctrl Shift I or F12

See electron-debug for more information.

DevTools extension

This project includes the following DevTools extensions:

You can find the tabs on Chrome DevTools.

If you want to update extensions version, please set UPGRADE_EXTENSIONS env, just run:

$ UPGRADE_EXTENSIONS=1 npm run dev

# For Windows
$ set UPGRADE_EXTENSIONS=1 && npm run dev

CSS Modules

All .module.less files will be use css-modules.

Packaging

To package apps for the local platform:

$ npm run package
$ yarn package

To package apps with options:

$ npm run package -- --[option]

To package the app on your local machine, you need to set the ROLLBAR_POST_TOKEN environment variable to send telemetry data to Rollbar. You can get one for free from https://rollbar.com

macOS: To notarize the app so that it will run on macOS Mojave, you need to set the environment variables APPLEID, APPLEIDPASS, and TEAMID. Note that you need to set an app-specific password in https://appleid.apple.com for this to work.

Note that you'll need to build Windows builds on a Windows machine, and MacOS builds on a Mac.

Further commands

To run the application without packaging run

$ npm run build
$ npm start

To run End-to-End Test

$ npm run build
$ npm run test-e2e

Options

See electron-builder CLI Usage

Module Structure

This project uses a two package.json structure.

  1. If the module is native to a platform or otherwise should be included with the published package (i.e. bcrypt, openbci), it should be listed under dependencies in ./app/package.json.
  2. If a module is imported by another module, include it in dependencies in ./package.json. See this ESLint rule.
  3. Otherwise, modules used for building, testing and debugging should be included in devDependencies in ./package.json.

Use of LGPL libraries

Tidepool Uploader makes use of the following LGPL-licensed libraries:

These libraries are used in the following Node.js modules created by Tidepool and are dependencies of the Tidepool Uploader:

The LGPL is intended to allow use of libraries in applications that don’t necessarily distribute the source of the application. The LGPL has two requirements:

  • users must have access to the source code of the library
  • users can make use of modified versions of the library

To satisfy (1) we provide links to the relevant code repositories. To satisfy (2) we dynamically link to the library, so that it’s possible to swap it out for another version of the library.

Impact on Tidepool

Compile FFmpeg ourselves to ensure that we’re using the LGPL version and only include the minimal set of libraries Use dynamic linking (e.g. on Windows this means using a .dll, and on MacOS a .dylib) when linking to these libraries Mention that the software uses libraries from the FFmpeg project and libmtp under the LGPLv3, e.g. This software uses code of <a href=http://ffmpeg.org>FFmpeg</a> and <a href=”http://libmtp.sourceforge.net/”>libmtp</a> licensed under the <a href=a href=https://www.gnu.org/licenses/lgpl.html>LGPLv3</a> and its source can be downloaded <a href=”https://github.com/FFmpeg/FFmpeg/tree/master/libavutil”>here</a> and <a href=”https://sourceforge.net/projects/libmtp/”>here</a>

Impact on 3rd parties

If your EULA claims ownership over the code, you have to explicitly mention that you do not own FFmpeg or libmtp, and where the relevant owners can be found.

References

uploader's People

Contributors

cheddar avatar darinkrauss avatar dependabot[bot] avatar dorianscholz avatar fabricioflores avatar ginnyyadav avatar gniezen avatar gordyd avatar gralmurdok avatar greenkeeper[bot] avatar greenkeeperio-bot avatar hntrdglss avatar ianjorgensen avatar jebeck avatar jehernandezrodriguez avatar jh-bate avatar jhymermartinez avatar jorgeeduardohernandez avatar kentquirk avatar kpouget avatar krystophv avatar mgranberry avatar mrinnetmaki avatar nicolashery avatar pauloved avatar pazaan avatar sjlmejia avatar snyk-bot avatar thedukedk avatar ursooperduper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

uploader's Issues

Update error message for Medtronic Direct 5-series

Problem

  • Due to the height of the Medtronic Direct images, error messages are presented under the fold so users won't see them without scrolling.
  • We're using red to highlight pump serial number. Red is typically used for alerts and alarms.

Requested by

  • TBD

App (limit to one)

  • Tidepool Uploader

Scope

  • [ XS / S / M / L ]
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Design

  • [ Google Drive link to design file ]
  • [ https://zpl.io/1owmn4 and https://zpl.io/Z1PXc2r]

Done Criteria

  • Discussion between engineering (Chris) and design (Paul)
  • Copy:
  • Upload failed: Make sure no other software (e.g. CareLink, OpenAPS, Loop) is connected to your pump. Otherwise, please see the error details below or contact Tidepool Support.
  • Update to device images
  • Design Review Required? Y
  • [KissMetrics Events implemented]
  • [Documentation (in repo docs folder or GitBook)]

Design Review Recap

  • [ Changes to Done Criteria ]
  • Pass? [ Y / N ]

Test Strategies

  • Verify that pump & meter image displays correctly
  • Upload with an incorrect serial number and verify that the result error message is: "Make sure no other software (e.g. CareLink, OpenAPS, Loop) is talking to your pump. Otherwise, please see the error details below or contact Tidepool Support."

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: image.png | image.png | Contour-723.jpg | #509 Change Medtronic Direct device image | Screen Shot 2017-09-05 at 5.08.00 PM.png | Screen Shot 2017-09-05 at 5.11.21 PM.png

<M> Medtronic 6 History Message - Device Events <ux:0 dev:5 tst:3>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:5 tst:3>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,
  • alarms (e.g. occlusion)
  • prime events
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  1. Generate the following alarms on the Medtronic pump:
  • low insulin
  • low power
  • no delivery, by blocking the tubing and/or emptying the reservoir
  • auto off, using Utilities->Alarm-Auto Off
  • (optional) as they can be hard to trigger: over limit; no power
  1. In the Blip UI verify the following in the Medtronic Direct driver:
  • reservoir changes (tube primes and cannula fills) are displayed in the Basics as expected
  • status is suspended after reservoir changes, and no delivery and auto off
  • alarms, using _.where(window.tidelineData.grouped.deviceEvent, {subType: 'alarm'})
  • prime events, using _.where(window.tidelineData.grouped.deviceEvent, {subType: 'prime'})

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

<L> [uploader] update dependencies

Problem

A large number of the dependencies in the Uploader have fallen woefully out of date vs their latest stable releases. A number of them have had major version releases which introduce large breaking changes.

Success

  • Up to date on dependencies

Scope

  • L (appx 1 wk)

User Stories

  • As a Tidepool developer, I want my core dependencies to be up-to-date so that I am confident I'm not using a buggy release and I can easily browse the documentation.

Done Criteria

  • dependencies updated to latest stable releases
  • No regressions in app functionality.
  • Document any specific areas that need extra focus during testing in Test Strategies.

Test Strategies

  • General smoke test of app to ensure all works as expected. No specific testing necessary.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: krystophv/dep-updates | #528 Dependency Updates

Front End Design for Medtronic Direct

Problem

  • Support unpaired 600 series devices.

Success

  • Users with unpaired Medtronic 6-series pumps can upload.

App (limit to one)

Tidepool Uploader

Scope

  • M

Brainstorm

  • For design consideration:
  • Articulate that if dongle is not paired, pump serial number must be entered.
  • Where can user find serial number?

Design

User Stories

  • As a clinician with upload access, I want to be able to use a paired or unpaired device to upload Medtronic 6-series pumps so I'm not slowed down by having particular equipment

Done Criteria

For Medtronic 6-series pumps:

  • Contour NextLink 2.4
  • CareLink USB
  • UI for entering serial number
  • If the device is not paired when the user clicks upload, surface error message reminding user to enter serial number
  • Driver handshake for temporary pairing
  • Design Review Required? YES
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • Test on 630G and 640G
  • Contour NextLink
  • CareLink USB

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: upload 3/22/2017 at 7:43:00 PM.png

Medtronic 6 History Message - Manual Bolus <ux:0 dev:3 tst:3>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:3 tst:3>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,
  • normal boluses, including cancelled/interrupted boluses
  • combo/dual boluses, including cancelled/interrupted boluses
  • square boluses, including cancelled/interrupted boluses
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  1. Use a Bayer Contour Next Link 2.4 meter to upload each supported Medtronic pump classes (currently 630 and 640) to a Blip account.
  2. For each of the two following methods:
  • Visual comparison between Blip UI and Carelink UI
  • Verify that the following bolus types are accurately rendered in Blip:
    • Normal boluses, both completed and suspended
    • Dual wave boluses, both completed and suspended
    • Square wave boluses, both completed and suspended

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #368 Add history message parsing for 600-series

[uploader] Abbott FreeStyle Libre

Problem

  • Tidepool users want us to support more meters.

Requested by

  • 25+ users

See Meters to Add sheet for more details.

App (limit to one)

  • Tidepool Uploader

Scope

  • L: > 1 week (Dorian and Gerrit working together on this one)

Done Criteria

  • Libre data is uploaded successfully via platform.
  • Libre data is deduplicated correctly between uploads.

KissMetrics Events

  • Same as other meters
  • Upload attempted
  • Upload succeeded
  • Uploaded failed

Test Strategies

  • Accuracy
  • Verify correct CBG values
  • Verify correct SMBG and ketone values
  • Verify that UTC bootstrapping works as expected
  • Verify that control solution tests are not uploaded.
  • Verify that HI/LO are shown as HI/LO. HI can usually be generated by testing a drop of fruit juice.
  • OS compatibility
  • Verify successful upload on Windows 7 (32 & 64 bit), 8 (32 & 64 bit), 10; Mac OS 10.11, 10.12
  • Do a second upload to verify that data is deduplicated correctly.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #469 Support for FreeStyle Libre | #517 Support for FreeStyle Libre (2nd retry) | [platform] Add support for Abbott Libre

Large basal schedules cause upload failure

Description

When a 600-series pump has a large basal schedule (tested with 1 per hour), pump download fails.

Steps to Reproduce

  1. Create a new basal schedule on the pump with a different basal rate every hour
  2. Attempt to download data from pump

Environment

Uploader version: 0.310.0-alpha.11.135.gb0298b2e
OS: macOS

[Electron Uploader] Encrypt and store locally the user's Medtronic serial number

Problem

  • Users of Medtronic Direct will have to provide the Medtronic pump serial number. For home users, this should be stored so they don't have to type it in every time.
  • This will only be relevant for Electron Uploader, not Chrome Uploader.

Success

  • Increased frequency of Medtronic upload per user.

App (limit to one)

  • Tidepool Uploader

Scope

  • [ XS / S / M / L ]
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Architecture

  • Consider using https://github.com/atom/node-keytar. Please run any other package that will interface with the OS keychain by Darin Krauss and Howard Look. (The package choice has security implications.)

User Stories

  • As a user, I want Tidepool (the software, not the team) to know my Medtronic serial number so I don't have to type it in every time I want to upload.

Done Criteria

  • Checkbox to "Remember" serial number
  • If a valid (i.e., 6-digit) serial number is entered and "remember" is checked when the "Upload" button is clicked, then the serial number entered is stored in the OS keychain on the local machine, associated with the userId and deviceType (eg. Medtronic Direct) pair. (The userId + deviceType pair ensure that if we end up with multiple devices that need to store local "serial number" data we can do so.) The userId is the id of the user being uploaded for (not the authenticated user).
  • If user has selected "Remember" on a previous upload for that device type, the next time they are on the Upload screen (within the same session, or in a future session; with the same authenticated user or a different one), the device serial number will be auto-populated when the screen loads.
  • If a PwD data account already has one Medtronic pump serial number associated with the account, and a user with upload access (e.g., PwD, custodial, care team) enters a different valid serial number and clicks upload, the new serial number overwrites the initial serial number.
  • Permissions: Any account with upload permissions (e.g., PwD, custodial, care team) can remember the serial number.
  • Events for KissMetrics completed
  • [Documentation (in repo docs folder or GitBook)]

Events for KissMetrics

  • uploader - medtronic serial remembered

Test Strategies

Test 1

  • Enter Medtronic serial number
  • Do not click "Remember"
  • Upload
  • Log out
  • Log in
  • Verify that user serial number is not remembered

Test 2

  • Enter Medtronic serial number

  • Click "Remember"

  • Upload

  • Log out

  • Verify that user serial number has been remembered

  • [Verify events for KissMetrics]

Verification Test

https://docs.google.com/document/d/1g-jQrnbg4wAPHt3BfgCEqlyvc8HL4T63P6rrdQkdxkI/edit#

Approved for production by

  • Brandon

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: Remember Serial number mock.png | pazaan/electron-medtronic-remember-serial | #425 [WIP] Remember Medtronic pump serial numbers using `node-keytar`

<M> Medtronic 6 - Remaining Work

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • KissMetrics events
  • The pump checklist of the new Medtronic driver matches/exceeds that of the CareLink driver pump checklist
  • mmol/L and mg/dL are handled appropriately
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • Chrome Uploader - Medtronic 6 upload attempted
  • Chrome Uploader - Medtronic 6 upload successful
  • Chrome Uploader - Medtronic 6 upload failed

Related Cards

Test Strategies

  • mmol/L vs mg/dL
  • Upload a mmol/L pump with a mmol/L meter. In the Blip console, as above, check that the units and values for BG targets, ISF and BG are correct.
  • Verify KissMetrics events

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #389 WIP: Medtronic 600 documentation

Medtronic 6, 1b: Implement Basal Profiles <ux:0, dev:3, tst:1>

Problem

  • Have completed a proof of concept for basal profiles. Now we need to make it production ready.

Success

  • Uploading for Medtronic 6-series is supported

Scope

  • M

Brainstorm

  • [ link to a Google Doc ]

Prototyping, Research & Architecture Review

  • TBD

Design

  • [ Google Drive link to design file ]
  • [ Zeplin link to design file ]
  • [ screenshot ]
  • [ developers review/discuss edge cases, implementation details ]

Leader

  • TBD

Cost (breakdown of ux/dev/tst resource points)

  • (ux:0, dev:3, tst:1)

User Stories

  • As a Medtronic 6-series user, I want to upload my pump so I can review my data in Tidepool.

Done Criteria

  • Basal profile names
  • Basal profile values
  • Finished, reviewed code committed to master branch
  • Units tests
  • Documentation (in repo docs folder or GitBook)

Events for KissMetrics

  • n/a

Dependencies

Test Strategies

  • Basal profile names
  • Basal profile values (individual and summation)
  • [Verify events for KissMetrics]

Verification Test

  • [Link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #368 Add history message parsing for 600-series

OneTouch Ultra 2 and OneTouch Mini

Problem

  • Tidepool users want us to support more meters.

Requested by

  • Ultra 2 : 5 users
  • Ultra Mini : 8 users

See Meters to Add sheet for more details.

App (limit to one)

  • Tidepool Uploader

Scope

Done Criteria

  • Integrate into Electron Uploader
  • Tech work required: prepare for UTC Bootstrapping
  • Ultra 2 and Ultra Mini can upload via Tidepool Uploader
  • New checkbox on Tidepool Uploader called OneTouch Ultra (2 or Mini)
  • Design Review Required? Y
  • KissMetrics Events implemented
  • [Documentation (in repo docs folder or GitBook)]

Design Review Recap

  • [ Changes to Done Criteria ]
  • Pass? [ Y / N ]

KissMetrics Events

  • Same as other meters
  • Upload attempted
  • Upload succeeded
  • Uploaded failed

Related Cards

Test Strategies

  • Accuracy
  • Take BG test on the meters
  • Upload
  • Verify correct BG value and time appear
  • Verify that control solution tests are not uploaded. Press Up when Apply blood appears on meter to select control solution test.
  • Verify that HI/LO (below 20, above 600) are shown as HI/LO. HI can be generated by testing a drop of fruit juice (GN used undiluted orange juice)
  • OS compatibility
  • Verify successful upload on Windows 7 (32 & 64 bit), 8 (32 & 64 bit), 10; Mac OS 10.11, 10.12

Verification Test

Working draft:
https://drive.google.com/open?id=1jXfhX-59nlB0QXaMmVy0_M8dssp1-ZI9JsFbhU66w3s

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #439 Support for OneTouch UltraMini | #438 Support for OneTouch Ultra2 | #524 Enables OneTouch Ultra 2 and UltraMini | [platform] Add support for Abbott Libre

improve security: do not send credentials to remote server

Observed: In chrome-uploader, the uploader is able to make any web requests it needs to make in order to fetch information. In order to get carelink data, it collects Carelink user credentials in the app, where the code is running on the user's local machine. Then, chrome-uploader sends these credentials to a remote server that is not Carelink servers. In addition, the payload appears to be sent in the clear (although presumably over SSL transport, the message containing the passed credentials are not encrypted).

Expected: If you must collect third-party credentials, use them locally on the user's machine and delete them immediately. Eg, from chrome-uploader directly log into carelink and download the data using the permissions granted by the chrome extension. Upload the data only, not the user's credentials.

SMBGs don't appear for 670G

Description

When downloading pump data from a 670G series device, the SMBG's don't appear in the trend view or daily view.

Environment

Uploader version: 0.310.0-alpha.11.135.gb0298b2e
OS: macOS

Don't surface "Update Available" message while an active upload is in progress

Problem

  • Users of Tidepool Uploader 2.0 are prompted to install a new version while their upload is going on. When the installation is complete, they're prompted to restart the Uploader, which may disrupt the upload.

App (limit to one)

  • Tidepool Uploader

Scope

  • [ XS / S / M / L ]
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Done Criteria

  • Uploader 2.0 only surfaces updates when there is no upload in progress
  • Design Review Required? N
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • When an update is available, log into the Uploader, begin a long (e.g. pump) upload, and verify that no notification appears during the upload.
  • If the notificaiton appeared prior to the upload, don't accept. Restart the Uploader and try again faster.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

Electron Uploader - Blip Integration

Problem

  • We don't know how to make the Upload buttons in Blip
  • check if the Uploader is installed
  • launch the installer when the Uploader isn't installed
  • launch the Uploader when the Uploader is installed

Success

  • Signup to first upload metric improves!

App (limit to one)

  • Tidepool Web

Design

User Stories

  • As a clinician with custodial access or care team member access, I want to launch the Tidepool Uploader from Tidepool Web and have it launch the correct patient.
  • As a PwD, I want to launch the new Tidepool Uploader from Tidepool Web.

Done Criteria

  • After creating Data Storage Account, big central button

  • When clicked, goes to Uploader product page.

  • Under the button, add affordance that says "Already have the Tidepool Uploader? Launch it here."

  • Upload button in top navigation within data viz

  • Launches a dialog box and the Tidepool Uploader

  • Dialog box provides link to download installer

  • Upload button on Patient List screen

  • Launches a dialog box and the Tidepool Uploader

  • Dialog box provides link to download installer

  • Design Review Required? [ Y / N]

  • [KissMetrics Events implemented]

  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • Maintain as is

Verification Test

Approved for production by

  • Brandon - This is approved, but cannot go to prod until the Tidepool Uploader 2.0 is ready for release.

Tags & Release Notes

  • TBD

┆Attachments: magic_login.js | Browser Dialog.png | New Tab.png | Popup.png | image.png | krystophv/electron-launch | krystophv/protocol-handler | #436 launch Electron app based on custom URI handling | #457 Set default protocol handler | image.png

<XS> Electron Uploader - KissMetrics

Problem

  • Analysis on upload events takes a long time because each event is separated by device.

App (limit to one)

  • Tidepool Uploader

Scope

  • XS

User Stories

  • As a product manager, I want to be able to report on uploading trends in aggregate, then drill into specific device types, rather than the other way around, so my analysis goes much faster.

Done Criteria

  • See KissMetrics Events

KissMetrics Events

  • Electron Uploader - Upload Attempted
  • Property: [make]
  • Property: [model]
  • Electron Uploader - Upload Succeeded
  • Property: [make]
  • Property: [model]
  • Electron Uploader - Upload Failed
  • Property: [make]
  • Property: [model]

Test Strategies

  • Verify that for each device upload, the make and model of the device are delivered as properties in KissMetrics, and not part of the event name.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #412 Electron Uploader: Updating metrics

[uploader] Merge Guardian support PR into CareLink driver

Problem

  • Merge and smoke test #431

Requested by

  • Open Source contribution

Success

  • CareLink upload still works as expected after code is merged, Guardian CSV data imports successfully

App

  • Tidepool Uploader

Scope

  • [ XS / S / M / L ]
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Done Criteria

  • CareLink upload is smoke tested, and confirmed to still work after code merge

Test Strategies

  • Smoke test a previously supported CareLink import to verify it works after the merge
  • For Guardian, compare data in a CareLink CSV export to data from Tidepool XLS download. Sort data points chronologically and verify all data points match.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

[uploader] [timezones] as a user, i want the uploader to warn me of any difference between my device time and computer time or selected timezone in the Uploader and my computer timezone

Leader

  • Gerrit

Cost (resource & points)

  • TBD

User Stories

  • As a user, I want to get a warning message if the time on my device is not what Tidepool thinks it should be, so I don't end up with duplicate data.

Done Criteria

  • Electron only
  • Tidepool Uploader reads the current time from each device.
    Priority 1:
    • Omnipod
    • t:slim / t:flex / t:slim G4
    • Animas ping / vibe
    • Dexcom G4

Priority 2:

  • Supported BG meters

  • When the user clicks "Upload" for any device, the Tidepool Upload compares the current time on the device to the user's local time, based on the server time +/- timezone offset selected in the Tidepool Uploader UI .

  • If the times are more than 15 minutes apart, an error message is displayed that reads: "Device time: HH:mm:ss | Pacific time: HH:mm:ss | Oh booger! Is your device time set correctly? Please update the timezone your pump is in or update your device time before uploading, then [pump: suspend and resume your device | CGM: wait up to 5 minutes for a new BG reading to appear]."

Dependencies (in order do this card)

Test Strategies

  • TBD

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

Medtronic 6 History Message - Calculator Bolus <ux:0 dev:5 tst:3>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:5 tst:3>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,
  • input blood glucose value
  • carbs input in grams (if applicable in 6-series: via Wizard or Capture Event)
  • insulin on board
  • carb ratio
  • ISF
  • BG targets
  • units suggested
  • units programmed
  • units used (e.g., override/underride)

For the following boluses:

  • normal boluses, including cancelled/interrupted boluses and suggested vs. delivered
  • combo/dual boluses, including cancelled/interrupted boluses and suggested vs. delivered
  • square boluses, including cancelled/interrupted boluses and suggested vs. delivered
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  • Upload Medtronic pump and verify that the wizard events as described in done criteria are uploaded correctly.
  1. Compare Blip UI to CareLink UI and pump history to verify the following :
  • input blood glucose
  • carbs input in grams
  1. In the Blip console (using _.filter(window.tidelineData.grouped.bolus, function(n) {return _.has(n,'wizard')}); and expanding the wizard property) verify the following:
  • insulin on board
  • carb ratio
  • ISF
  • BG targets
  • units used (where available)

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #368 Add history message parsing for 600-series

<S> <1:ux 3:dev 1:tst> [Electron Uploader] Update Tidepool Uploader Login Screen & Footer

Problem

  • Tidepool JDRF agreement includes acknowledgement of JDRF.
  • Clinics are interested to see other organizations that work with Tidepool.

Scope

  • S

Design

Cost Detail (breakdown of ux/dev/tst resource points)

  • <1:ux 3:dev 1:tst>

Done Criteria

Throughout experience, update design to:

  • Get Support
  • color: grey
  • Hover: see style guide
  • Click: see style guide
  • links to support.tidepool.org
  • Privacy and Terms of Use
  • color: grey
  • Hover: see style guide
  • Click: see style guide
  • links to tidepool.org/legal/
  • Made possible by JDRF
  • grey
  • Use JDRF logo as shown in spec
  • Remove "beta"
  • Move version to bottom center, under all other links
  • Sign up colors
  • Purple
  • Hover: see style guide
  • Click: see style guide
  • Change "T" to "Tidepool"
  • Add word "Uploader" under Tidepool
  • Update background color to spec
  • Make "Login" two words -> "Log in"
  • Increase spacing between logo and text fields
  • Increase spacing between Signup and Tidepool logo
  • Change "Forgot your password?" to "Forgot password" (i.e., remove "your")
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • Verify links go to expected locations as defined in done criteria
  • Verify designs meet spec for log in screen
  • Verify footer designs meet spec for end user experience on the following pages:
  • Select patient
  • Choose devices
  • Upload
  • Verify footer designs meet spec for VCA user experience on the following pages:
  • Select patient
  • Add new
  • Choose devices
  • Upload

Verification Test

  • [Include link to test document]

Related Cards

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: krystophv/electron-branding | #395 Electron Login and Footer rebranding

several problems with european medtronic files

i tried importing a european medtronic file with chrome-uploader/lib/carelink/cli/csv_loader.js and I had several issues:

ISSUE-1: medtronic csv export fileformat from carelink.minimed.eu is different if you have another language selected in your user preferences:

E.g. English header
Index,Date,Time,Timestamp,New Device Time,BG Reading (mmol/L),Linked BG Meter ID,Temp Basal Amount (U/h),Temp Basal Type,Temp Basal Duration (hh:mm:ss),Bolus Type,Bolus Volume Selected (U),Bolus Volume Delivered (U),Bolus Duration (hh:mm:ss),Prime Type,Prime Volume Delivered (U),Suspend,Rewind,BWZ Estimate (U),BWZ Target High BG (mmol/L),BWZ Target Low BG (mmol/L),BWZ Carb Ratio (grams),BWZ Insulin Sensitivity (mmol/L),BWZ Carb Input (grams),BWZ BG Input (mmol/L),BWZ Correction Estimate (U),BWZ Food Estimate (U),BWZ Active Insulin (U),Alarm,Sensor Calibration BG (mmol/L),Sensor Glucose (mmol/L),ISIG Value,Daily Insulin Total (U),Raw-Type,Raw-Values,Raw-ID,Raw-Upload ID,Raw-Seq Num,Raw-Device Type

If you change your language prefence to Dutch you get:
Index,Datum,Tijd,Tijdstempel,Nieuwe apparaattijd,BG-meetwaarde (mmol/l),ID gekoppelde BG-meter,Tijdel. basaalsnelheid (E/H),Tijdel. basaaltype,Tijdel. basaalduur (hh:mm:ss),Bolustype,Geselecteerd bolusvolume (E),Afgegeven bolusvolume (E),Bolusduur (hh:mm:ss),Vultype,Afgegeven vulvolume (E),Stoppen,Terugdraaien,Bolus Wizard-schatting (E),Bolus Wizard streef-BG hoog (mmol/l),Bolus Wizard streef-BG laag (mmol/l),Bolus Wizard KH-ratio (gram),Bolus Wizard insulinegevoeligheid (mmol/l),Bolus Wizard KH-invoer (gram),Bolus Wizard BG-invoer (mmol/l),Bolus Wizard geschatte correctiebolus (E),Bolus Wizard geschatte maaltijdbolus (E),Bolus Wizard actieve insuline (E),Alarm,Sensorkalibratie-BG (mmol/l),Sensorglucose (mmol/l),ISIG-waarde,Insuline-dagtotaal (E),Onbewerkt: type,Onbewerkt: waarden,Onbewerkt: ID,Onbewerkt: upload-ID,Onbewerkt: volgnummer,Onbewerkt: apparaattype

I assume you won't support other languages than English. Be sure to warn European users of this issue.

ISSUE-2: even with language on English, my medtronic export uses "," instead of "." as a seperator for real values. E.g. RATE=0,9 instead of RATE=0.9.
BasalProfileStart,"PATTERN_NAME=standard, PROFILE_INDEX=0, RATE=0,9, START_TIME=0, ACTION_REQUESTOR=pump"

ISSUE-3: Unfortuately, when I fix this in the input csv file (regexp in VI :%s/([A-Z_][A-Z])=([-0-9][0-9]),([-0-9][0-9]* )/\1=\2.\3/g) I still encounter problems, such as:

CareLink CLI: Loading CareLink CSV...
No local session found
POST /auth/login
Session saved
CareLink CLI: Loading using the timezone CET
CareLink CLI: Loading for user xxx
CareLink CLI: Reading /xxx/CareLink-Export-test-uk.csv
CareLink CLI: Error processing CareLink data: { [TypeError: Cannot read property 'start' of undefined] step: 'processData' }
TypeError: Cannot read property 'start' of undefined
at processParts (/home/xxx/tidepool-org/chrome-uploader/lib/carelink/carelinkSimulator.js:221:38)
at pushBasalClockForward (/home/xxx/tidepool-org/chrome-uploader/lib/carelink/carelinkSimulator.js:299:14)
at Object.basalScheduled (/home/xxx/tidepool-org/chrome-uploader/lib/carelink/carelinkSimulator.js:366:7)
at Array.3 (/home/xxx/tidepool-org/chrome-uploader/lib/carelink/basal.js:60:21)
at /home/pieterb/tidepool-org/chrome-uploader/lib/drivers/carelinkDriver.js:331:28
at Array.forEach (native)
at Object.processData (/home/xxx/tidepool-org/chrome-uploader/lib/drivers/carelinkDriver.js:323:38)
at processData (/home/xxx/tidepool-org/chrome-uploader/lib/driverManager.js:135:16)
at fn (/home/pieterb/tidepool-org/chrome-uploader/node_modules/async/lib/async.js:641:34)
at Object._onImmediate (/home/xxx/tidepool-org/chrome-uploader/node_modules/async/lib/async.js:557:34)

Any clue how to fix this?

<S>UPLOADER - Kissmetrics clean up

Problem

  • We can't measure, for people who are using Tidepool in clinic, how many are also using Tidepool at home.
  • Saleh will be presenting Tidepool to the T1D Exchange clinic members in early April. We'd like to show data for home user engagement of Profiles create in Saleh's clinic.

Success

  • Tidepool can measure, for patients whose data is uploaded in the clinic (i.e., uploaded by a VCA account to the patient profile), how many are later uploading or logging in from home and viewing data (i.e., from their own account to their own profile).

Research / Reference Document

Scope

  • S

User Stories

  • As a product manager, I want to understand how uploading in clinics translates to end user engagement at home, so I can establish expectations with clinicians interested in using Tidepool.

Done Criteria

The event will have two hashed user ids, one for the authenticated user (eg. the clinician) and one for the target user (ie. the patient that the clinician is uploader data for). The authenticated user should already be sent with any metric, so we just need to add the target user.

  1. Remove device name from the Event_Name
  • e.g., instead of Chrome uploader - upload successful bayercontournextusb, the Event_Name should just be Chrome uploader - upload successful. Device name is already identified as a Property called Source.
  1. Pass the hashed user id of the target user in each event below
  • Chrome uploader - upload successful
  • Chrome uploader - upload attempted
  • Chrome uploader - upload failed
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • See done criteria

Test Strategies

Test 1

  • For each supported device, upload and verify that that KissMetrics captures at least two of three below, without device name.

Test 2

  • Using a custodial account that has not been claimed by an end user, upload a device as a custodian and verify that the target hashed user id comes through as a property. Record the hashed user id.
  • As an end user, claim the account that was just uploaded to. Upload as the end user, instead of as the custodian. Verify that that the user uploading matches the hashed user id that was passed as the property in the previous upload.
  • Log back into the Uploader as the former custodian, who is now just a careteam member. Upload to the same target user account. Verify that the same target hashed user id is again passed as a property to Kissmetrics.

Verification Test

  • [Include link to test document]

Related Cards

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

Clinic unable to see email and editing claimed or patient-shared account in Clinic Uploader fails silently.

What:

A) Clinics cannot add MRN#'s to claimed patient accounts. The field is accessible, editable, and fails silently (related to our muting of the error that would appear when a clinician edited timezone.)

B) If an account is patient-created, and shared with the clinic, the email for the patient does not appear in the edit info page for the clinic - so it appears that there is no email. it is not possible to add an MRN or edit the email clinic side.

This is more of an issue in that we believe that the patient email should be visible, but we may be mistaken. (Chris M and I)

Who
UCSF first brought up this issue - though it will be an issue for all clinics.If a patient account is shared with the clinic, or if the patient claims the clinic-created account, there is no way to add an MRN#.

https://secure.helpscout.net/conversation/403789158/2278/?folderId=834034

Screenshots:

┆Attachments: image.png | image.png

[uploader] OneTouch Verio and Verio Flex

Leader

  • Gerrit

Cost (resource & points)

TBD

User story

As a Tidepool user, I want to be able to upload my Verio and Verio Flex meters so I can see their data in Blip.

Done criteria

  • Upload both Verio and Verio Flex successfully

Test Strategies

  • Upload Verio and Verio Flex - verify that BG readings are correct.

Demo Strategies

  • TBD

Tags & Release Notes

  • TBD

upload issue

I tried to use this today and got it to recognize my dex and my account, but it didn't upload properly. It gave the following error, but there was no record of any errors in the apple console (is there some other console that should be checked?):

connected
success
Fetching profile.
success
{"fullName":"JB","patient":{"birthday":"19xx-xx-xx","diagnosisDate":"19xx-xx-xx"}}
Discovered Dexcom G4 CGM
Found DexcomG4
Some sort of error occurred (see console).

Medtronic 6 History Message - SMBG Values <ux:0 dev:3 tst:3>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • S

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:3 tst:3>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,
  • manually entered blood glucose values
  • linked (meter) blood glucose values
  • out-of-range (LO/HI) are not displayed as values
  • discards control solution tests from meter
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  1. Perform a control solution test and a regular BG test on a linked meter and check that only the regular BG reading is synced to the pump.
  2. In Blip verify that:
  • manually entered blood glucose values are the same between Blip and Pump History (on device or in CareLink)
  • linked blood glucose values are the same between Blip and Pump History (on device or in CareLink)
  1. Try to send a HI/LO reading (possibly using fruit juice to generate HI reading) from the Bayer meter, upload again and verify that it does not appear in Blip.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #368 Add history message parsing for 600-series

[uploader] Add G5 support for Tandem pumps

Requested by

  • Gerrit

App (limit to one)

  • Tidepool Uploader

Scope

  • S: 2-3 days

User Stories

  • As a PwD, I want see my Dexcom G5 data when I upload my Tandem X2 pump with G5 support.

Done Criteria

  • Dexcom G5 data is uploaded successfully from Tandem X2.
  • Tandem driver is updated to adhere to changes in the four most recent spec revisions.

Test Strategies

  • Generate three calibration events: HI (620), LO (5), regular (120)
  • CGM events should also include HI (>400) and LO (<40).
  • Upload Tandem X2 with G5 data.
  • Verify that CGM data displays as expected, including HI/LO and calibration.
  • Smoke test Tandem t:slim G4 and verify that CGM data appears as expected.

Verification Test

https://docs.google.com/a/tidepool.org/document/d/17X8t82fhD3Djmwykp5yGb7Nf4KdKAt3SKoaFA1we39o/edit?usp=sharing

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #512 Support for Dexcom G5 CGM events on Tandem X2

Medtronic 6 History Message - CGM Data <ux:0 dev:3 tst:3>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:3 tst:3>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,
  • CGM readings from pump are displayed in Blip.
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  • Check that CGM data appears as expected
  • Check that calibration events appear in Blip console: _.where(window.tidelineData.grouped.deviceEvent, {subType: 'calibration'}) and that value corresponds with SMBG reading

TBD: See Low Glucose Suspend (LGS) testing in this card https://trello.com/c/zlAnS0iw and determine relevance for 6-series testing.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #368 Add history message parsing for 600-series

Abbott Freestyle support on OS X

Hi,

I'd like to work on adding OS X support to the Abbott (Freestyle) driver but to be honest, I'm not sure where to start. What I know so far:

  • The upload product page shows that Abbott devices are only supported on Windows, and
  • http://developer.tidepool.io/serial-ports/ mentions that Abbott devices use a custom serial cable.
  • Some information about the Freestyle protocol is available here and the ABNF protocol here

Since are no unit tests currently, I thought creating some might be useful for the project and as a teaching tool for myself. What do you think? Are there any Tidepool documentation or other resources that would be useful on this subject?

Electron Uploader - Device Support

Problem

  • When we move over to Electron, we will not have access to Chrome's USB APIs anymore.

Success

  • Upon release of Electron Uploader, we expect increased rate of first Uploader log in from users who have just signed up and created data storage.

App (limit to one)

  • Tidepool Uploader

Scope

  • M (without extensive testing), L (with testing on all OS variants)
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Brainstorm

Done Criteria

  • All the devices we currently support upload successfully on both Mac and Windows.
  • Design Review Required? N
  • [KissMetrics Events implemented]
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • Install Uploader
  • Install driver
  • One 1 Mac and 1 Windows machine:
  • Test all devices
  • Verify success and data appears
  • On all variants of Mac and Windows, test:
  • Serial: Upload 1 Animas and 1 other serial device
  • HID: Upload Bayer Contour Next Link and Medtronic
  • IBF: Upload Omnipod

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

[platform] Add support for Medtronic 600-series

Problem

Enable Medtronic 600-series devices for platform upload and deduplication.

Manufacturer     Models
------------     ------
Medtronic        1510, 1511, 1512, 1710, 1711, 1712, 1715, 1780

Requested by

  • Lennart/Eric

App (limit to one)

  • Backend

Scope

  • XS: < 1 days

Done Criteria

  • Platform allows above mentioned Medtronic devices to upload and use the appropriate deduplicator.

Dependent Cards (that rely on this card getting done first)

  • N/A

Test Strategies

  • Confirm that the existing device uploads to the platform work as expected.
    • Upload a supported Animas device and ensure it works as expected.
    • Upload an older supported Medtronic Direct device (one of 523, 723, 551, 751, 554, 754) and ensure it works as expected.
  • Once the Uploader enables uploading Medtronic 6-series, upload via the Tidepool Uploader and verify it works as expected for each of 1510, 1511, 1512, 1710, 1711, 1712, 1715, 1780. (This step could be considered part of testing the Medtronic 6-series in the Uploader.)

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

┆Attachments: #158 Support additional Medtronic devices | 723-upload.png | vibe-upload.png | vibe-console.png | 723-console.png

Electron Uploader - Develop Installer for Mac and Windows

Problem

  • We need a Windows installer for the new Electron App.
  • We need a macOS installer for the new Electron App.

App (limit to one)

  • Tidepool Uploader

Scope

  • M

User Stories

  • As a Windows user, I want to be able to install the Tidepool Uploader so I can get my data to Tidepool and analyze it.

Done Criteria

  • Test users can install the Tidepool Uploader without interacting with code.
  • Design Review Required? YES
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • Test installer on Windows
  • Note: Testing on a complete set of OS versions will be conducted as part of an overall testing card for Electron Uploader.
  • Test installer on a Mac
  • Note: Testing on a complete set of OS versions will be conducted as part of an overall testing card for Electron Uploader.

Testing number of times installed

  • Windows: After installing, check c:\Users\<current user>\AppData\Local\Temp\TidepoolUploader.ini for numbers of times installed
  • Mac: After installing check /tmp/TidepoolUploader.cnt for number of times installed

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

<L> Medtronic 6-series CareLink USB driver

Problem

  • There is a new CareLink USB stick for 2.4 that needs to be supported

Success

  • Users uploading 6-series through CareLink USB stick for 2.4 (i.e., not the Bayer Contour NextLink 2.4) can successfully upload

App (limit to one)

  • Tidepool Uploader

Scope

  • L
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Done Criteria

  • Research effort to embed custom Medtronic driver into Electron app and use the Medtronic driver's API
  • Driver for CareLink USB stick to communicate with medtronic 6-series pumps is included in the Windows and Mac Driver package
  • Design Review Required? NO
  • [Documentation (in repo docs folder or GitBook)]

Test Strategies

  • Smoke test upload of 6-series device using CareLink USB stick (not Bayer Contour NextLink). Verify upload is complete and data appears. No need to verify data. That will be tested separately.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

<1:ux 5:dev 3:tst> [uploader] Electron Uploader (part 2)

Problem

  • Porting the Uploader to Electron presents a new App ecosystem, build tools and developer tools that we need to adapt our Uploader to.

Success

  • Tidepool launches a new version of our Uploader that is not reliant on Google Chrome apps.

Scope

  • L

Cost Detail (breakdown of ux/dev/tst resource points)

  • <0:ux 5:dev 3:tst>

User Stories

  • As a user, I want to upload my data from my diabetes devices after Chrome apps are no longer supported so I can continue to use Tidepool web to analyze my data.

Done Criteria

  • Have a functional version of the Uploader running in Electron using the electron-react-boilerplate project as a basis for porting
  • Use react-router as provided by boilerplate in place of our "fake page" system in order to bring the Uploader to parity with Blip for consistency across repos

Dependencies

Test Strategies

  • Smoke test device upload from every supported device on Mac (10.10, 10.11) and Windows (7, 8, 10).

  • In depth data quality test (compare JSON is OK) for 1 insulin pump upload.

  • Smoke test non-VCA functionality

  • Select a patient

  • Edit devices

  • Set timezone

  • Smoke test no DSA access

  • Error message for no DSA

  • Smoke test VCA functionality

  • Add a patient

    • Home invite sent
    • Choose devices
    • Set timezone
  • Search

  • Choose a patient

  • Edit patient info

  • Verify events for KissMetrics are coming through as expected

  • Log in

  • Upload attempt (for a particular device)

  • Upload failed (for a particular device)

  • Upload successful (for a particular device)

  • VCA functionality

  • Verify that UI and UX/interactions are the same as prod uploader

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: krystophv/electron | krystophv/electron

Electron Uploader - Auto-update for Tidepool Uploader

Problem

  • The current Tidepool Uploader auto-updates via Chrome. The Electron Uploader should do the same, though not through Chrome.

App (limit to one)

  • Tidepool Uploader

Scope

  • M
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Brainstorm

  • Dropdown to check, or periodic check against a known distribution point (S3 bucket, release of Github)

User Stories

  • As a clinician with custodial access, I want my Tidepool Uploader to update automatically so I can have the the latest patches and most secure, best performing Tidepool Uploader without investing time in updates.

Design

Done Criteria

  • This will need to be interwoven with: https://trello.com/c/3T4aKFZX
  • There are three types of app update checks:
    • App startup: automatically performed at app startup only, checks for latest version available, automatically downloads the update (and deletes any previously downloaded update after successful download - we don't want these to accrue), displays "Updates available" messaging on main uploader page (@skrugman exact UX needed). Interacting with the "Updates available" messaging is the same as selecting "Check for Updates..." from the menu.
    • Manual: user initiated from "Check for Updates..." menu, checks for latest version available, prompts user with messaging in any case (see below).
    • Required: performed when user clicks "Upload" for any device, checks current version against minimum required version (via API call), if current version < minimum required version, then messages user and will not let upload proceed. (@skrugman exact UX needed).
  • The Tidepool Uploader electron app will have a "Check for Updates..." menu item in the app menu. If the user selects it, there will be an immediate check for any updates to the app.
    • If no update is available (current version == latest version), then the user will be notified that the app is at the latest version (including the version number) with an OK button (@skrugman exact UX needed).
    • If an update is available (current version < latest version), then the user will be notified that an update is available (with current version and latest available version). Notification will include message that the app must be restarted.
      • If the update is required (current version < minimum required version), then the user will told it is a require update and given the option to Install or Cancel. (@skrugman exact UX needed).
        • Install will download the update (if it is not already downloaded - this probably needs some UX) and restart the app to install the update. If the Install is cancelled at any time (say, during download) then it will act as if the user clicked Cancel (below).
        • Cancel will do nothing, but the next automatic, forced, or manual update check will display the same message. (The user will not be allowed to do an upload without installing the update - Required update check.)
      • If the update is not required (current version >= minimum required version), then the user will be told it is optional and given the option to Install, Cancel, or Dismiss. (@skrugman exact UX needed). SK @darinkraus why do we need both a Cancel and Dismiss - from a UX perspective is seems like it accomplishes the same thing unless I'm missing something.
        • Install will download the update (if it is not already downloaded - this probably needs some UX) and restart the app to install the update. If the Install is cancelled at any time (say, during download) then it will act as if the user clicked Cancel (below).
        • Cancel will do nothing, but the next automatic, forced, or manual update check will display the same message. (The user will be allowed to upload.)
        • Dismiss will do nothing and the next automatic or forced update will not display the same message (until a newer latest version comes along or they install an update). A manual update will still display the same message.
  • Optional updates will be presented through the standard auto-update mechanism (via electron-builder's S3 check)
  • Required updates will be checked via the minimum supported version (as it is today)
  • App Startup and Manual checks will check for both Optional and Required updates.
  • Required check will only check for Required updates
  • Design Review Required? YES
  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • Electron Uploader - Auto-update occurred
  • Electron Uploader - Unsupported screen displayed

Dependencies (in order do this card)

Test Strategies

On Mac:

On Windows:

  • Create a non-admin Windows account and log in.

  • Follow steps above and check how installation is handled.

  • [Verify KissMetrics Events]

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: krystophv/electron-update

Electron: Support multiple USB PID/VID combos per driver

Problem

Google Chrome only allowed a single USB PID/VID combo per device, which meant that:

  • we only support a single cable per device, so it's not possible to use both the Abbott cables and the 3rd party FTDI cables to upload an Abbott meter
  • We have multiple selections for Bayer devices, and we cannot use the precise USB PID/VID combo to filter for a specific device. For more details on collapsing Bayer selections, see https://trello.com/c/06aRAIAq.

Now that we're using Electron, we can use multiple USB PID/VID combos , so we can support multiple cables per device and properly collapse device selections to simplify the Choose Devices screen.

Requested by

  • Gerrit

App (limit to one)

  • Tidepool Uploader

Scope

User Stories

  • As a PwD, I want to be able to use more than one supported cable to upload my device

Done Criteria

  • Abbott meters can be uploaded with both the Abbott cable and the 3rd party FTDI cable
  • BCN meters are all under a single selection
  • Abbott FreeStyle Lite & FreeStyle Freedom Lite are under a single selection
  • All Bayer & Abbott meters report the correct model number in upload record

Dependencies (in order do this card)

Test Strategies

  • After creating test account, use current production version (v2.0.2) to select all the Bayer meters and both the FreeStyle and FreeStyle Freedom Lite meters in Choose Devices.
  • When loading test version (v2.1.0) using the same account, verify that:
    • all the Bayer selections have now collapsed under "Bayer Contour Next",
    • that there's a single selection for the FreeStyle meters (on Windows) and
    • that there are no "Unknown Device"s
  • Upload both FreeStyle meters with both the Abbott cable and the generic FTDI cable (Nick should have generic cable)
  • Verify in Tidepool Web that the correct deviceModel is reported in the upload record. Use window.tidelineData.grouped.upload in the web console.
  • Upload all supported Bayer meters. Again, verify in Tidepool Web that the correct deviceModel is used.

Verification Test

Working draft:
https://drive.google.com/open?id=1ikyCBdUe33uwpq385hjmAsx4lh8up5kf99r5_YblcJ8

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: gniezen/multiple-pid-vid | #526 Support multiple USB PID/VID combos | [uploader] Collapse Bayer meters into a single "Bayer Contour" selection / prevent "Unknown Device" | #522 ⁃ OneTouch Ultra 2 and OneTouch Mini | [platform] Add support for Abbott Libre

<S> [uploader] Medtronic 6 - Driver copy for Choose Devices screen

Scope

  • S

Done Criteria

  • Medtronic (CareLink import)
  • Medtronic 523, 723, 530G (Bayer Contour Next Link)
  • Medtronic 630G, 640G, 670G (Bayer Contour Next Link 2.4)

Test Strategies

  • Verify copy appears as defined in Done criteria
  • Verify successful uploads from the expected selection
  • Verify user cannot upload a 5-series pump when only 6-series is selected
  • Verify user cannot upload a 6-series pump when only the 5-series is selected

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

┆Attachments: #441 Modify device screen copy

Medtronic 6 History Message - Basals <ux:0 dev:3 tst:5>

Problem

  • Once we've demonstrated the ability to extract data from the 6-series pump, we need to pull all history.

Success

  • Tidepool team will be confident that we can have a full, robust upload for the 6-series.

Scope

  • M

Leader

  • Lennart

Cost (breakdown of ux/dev/tst resource points)

  • <ux:0 dev:3 tst:5>

User Stories

  • As a Medtronic 6-series user, I want to be able to upload my data in Tidepool so I can use Tidepool software to analyze it.

Done Criteria

  • For Medtronic 630 and 640 pumps,

  • scheduled basals (including flat rate basals)

  • temp basals (including cancelled and suppressed info)

  • suspended basals (including suppressed info)

  • suspend/resume events

  • final (most recent) basal

  • [Documentation (in repo docs folder or GitBook)]

KissMetrics Events

  • none

Related Cards

Test Strategies

  1. Change the active schedule on the pump and then a few minutes later schedule a temp, to make sure we're tracking the schedule changes properly
  2. Compare the following between the Blip UI and CareLink UI, verify they are the same:
  • scheduled basals
  • temp basals, including cancelled and suppressed info
  • suspended basals, including suppressed info and resume events
  1. Verify that flat rate basals are truncated after 5 days.

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Demo Strategies

  • TBD

Pull Requests

  • TBD

Tags & Release Notes

  • TBD

┆Attachments: #377 [WIP]: NGPHistoryParser and medtronic600Simulator code complete

[BUG] VCA gets inappropriate error message when trying to create user account.

Problem

  • VCA attempted to create a patient account.
  • After completing name, DoB, MRN, and email, this error appeared:
  • "We can't save your device and timezone selection right now."

Helpscout

Screenshot

App (limit to one)

  • Backend

Scope

  • [ XS / S / M / L ]
  • Reference:
    • XS: <= 1 day
    • S: 2-3 days
    • M: <= 1 week
    • L: > 1 week

Research

Done Criteria

  • Triage bug. Understand extent of problem.
  • Design Review Required? [ Y / N]
  • [KissMetrics Events implemented]
  • [Documentation (in repo docs folder or GitBook)]

Design Review Recap

  • [ Changes to Done Criteria ]
  • Pass? [ Y / N ]

Test Strategies

Verification Test

  • [Include link to test document]

Approved for production by

  • [Howard / Brandon]

Tags & Release Notes

  • TBD

Recommend Projects

  • React photo React

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

  • Vue.js photo Vue.js

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

  • Typescript photo Typescript

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

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

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

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.