Giter Site home page Giter Site logo

nielsmaerten / gluco-check Goto Github PK

View Code? Open in Web Editor NEW
24.0 7.0 8.0 11.81 MB

Use Nightscout with Google Home: "Hey Google, check my sugar"

Home Page: https://glucocheck.app

License: MIT License

JavaScript 7.31% TypeScript 91.46% Shell 0.16% HTML 1.01% CSS 0.06%
google-home google-assistant diabetes nightscout blood-sugar

gluco-check's Introduction

Welcome to Gluco Check

⚠️Archived repository

Following Google's decision to sunset Conversational Actions,
Gluco Check's repository has been archived and its services disabled.


Nightscout for Google Home and Google Assistant.
Watch a demonstration on YouTube (2m50s).
Formerly known as Nightscout Status.

Getting started

  1. Link your Nightscout site
  2. Say: "Hey Google, talk to Gluco Check"
  3. (Optional): Set up a Routine to make invoking Gluco Check easier
    For example: "Hey Google, check my sugar"

Things you can ask Gluco Check

  • Blood sugar
  • Insulin on Board
  • Carbs on Board
  • Sensor age
  • Infusion set age
  • Pump battery level
  • Pump reservoir level
  • And more

Protip: Using a shorter invocation

Use Routines to turn "Hey Google, ask Gluco Check my blood sugar" into
"Hey Google, check my sugar".

Note: Routines are not supported in all languages.


Contributing

Pull requests are welcome.
For detailed tech docs, check CONTRIBUTING.md

CI / CD CodeFactor codecov

License & Privacy Policy

Gluco Check is licensed under the MIT License
Copyright (c) 2021 Niels Maerten & David D'Amico

Privacy Policy

gluco-check's People

Contributors

ddamico avatar nielsmaerten 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

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

gluco-check's Issues

Using default invocation mentions missing metrics

Note: This repository's issues are reserved for feature requests and bug reports.
For support questions, please use the #WeAreNotWaiting Discord (I'm Emperor Cookie#7238)

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:

  • What is the expected behavior?

  • What is the motivation / use case for changing the behavior?

  • Please tell us about your environment:

    • What device are you using?
      • A dedicated device: (Google Home, Nest, ...)
      • A phone: (Which model? Version of Android / iOS?)
    • Language and Country:
  • Other information that could help us solve this issue: (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Auto-generate Nightscout tokens

  • I'm submitting a ...
    Feature request

  • What is the current behavior?
    The distinction between API secrets and tokens isn't clear to everyone.
    This results in some users entering their API Secret and then being puzzled it doesn't work.

  • What is the expected behavior?
    We were expecting users to enter tokens. But there are 2 issues with that:

    • Creating a token is cumbersome
    • Not everyone gets that there's a difference. Nightscout for example, lets you enter your token OR api secret when you're signing in. We should do the same.
  • What is the motivation / use case for changing the behavior?

    • API secrets are sensitive. We don't want to store these in our db
    • The solution is straightforward: if someone enters their API secret... Gluco Check can use it to create its own token.

If we add a way for the validation endpoint to detect when a 'token' is actually an 'api secret', it could transparently add a token on its own and use that instead. We can discard the api token immediately after that's done, which is better than the current behavior where we store it in our DB thinking its a token

Clarifying the nightscout validation endpoint

onblur of token and url fields, validation endpoint is called and response is used to:

  • if canReadStatus is false then
    • ??? fail silently? seems like any failure here should just not interrupt user, I think?
  • if canReadStatus is true then
    • populate glucoseUnits
    • either update defaultMetrics to block metrics that are not available, OR if user has incompatible site but options already selected, update helper text to indicate that only glucose will be read
    • add warning helper text to token field if token is invalid
    • update url field with returned parsedUrl
    • update token field with returned parsedToken

Pull COB and IOB from /pebble instead of /devicestatus

  • I'm submitting a ...
    Refactoring request

  • What is the current behavior?
    GlucoCheck pulls IOB and COB from the properties openaps or loop in api/v3/devicestatus.
    This is undesirable because users who don't use openaps/aaps/loop will not be able to check their COB/IOB

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:
    Try asking COB or IOB for someone who's not using Loop/OAPS/AAPS. @Diaolou discovered this issue.

  • What is the expected behavior?
    COB / IOB should be pulled from the /pebble endpoint, because that's available to everyone.

Insulin Input

It'd be great to be able to tell Nightscout when I'm taking insulin and how many units.

Refactoring

As the project is nearing beta.1, I think it might be a good idea to review the codebase as a whole.
Here are a few issues that are relatively easy to resolve now, and might save us a bunch of technical debt down the line:

  • Reconsider names
    Now that the responsibilities of classes is mostly solidified, some of the names don't cover the function as well
    For example: I think the concept of a 'DiabetesPointer' can more accurately be expressed as a 'Metric' (TBD)

  • Improve test coverage
    Review code that's uncovered by test cases. If it's difficult/irrelevant to test, exclude it from coverage reporting.
    And if it is relevant, add a spec to cover it

  • Restructure architecture
    A few classes are starting to violate the SRP. Those should be split up. (For example: DiabetesQueryResolver shouldn't be responsible for generating a full AssistantResponse. It should just be building a Snapshot that then can be used to build an AssistantResponse)

Remove unused React imports.

Now that we're on React 17, any spot where we're importing React in a component or test but not explicitly using it can be removed.

Account deletion (GDPR, ...)

Is your feature request related to a problem? Please describe.
Although we're way to small for legislation like GDPR to come after us, I think it's just good UX to give user who want to delete their information that option.

Describe the solution you'd like

  1. We could add another line to the footer (or somewhere else) that says, eg: "Delete my account". It could look like this.
  2. When a user clicks this link, we should show some message to ask for confirmation. It could say something along the lines of: "Are you sure you want to delete your account? If you're having trouble using Gluco Check, you may want to check out FAQ or our Discussion forum...."
  3. If the user confirms: add a new document to Firestore at the following location: '/deletion-requests/{user id}'.
    This should then kick off a backend function that scrubs the user from our systems.
  4. Sign the user out

Describe alternatives you've considered
Currently, the 'official' way of deleting your info is logging in an entering a dummy url/token to overwrite the ones you entered previously.

Additional context
I looked at the db of Nightscout Status for this, and it turns out there's actually a non-zero number of people who go through the trouble of entering dummy data to 'delete' their account. They may be few, but I still feel like we should offer them a clean exit if they want to.

Request: Remove urls from translation.json

Hey David,

I've added translation.json to Crowdin, so we can start translating the frontend from there.
Would it be possible to move URLs like these into a constants file instead?

I think strings that contains urls should be considered non-translatable. Because you could compute them like this:

/*PSEUDOCODE*/
const currentLng = getCurrentLng() // => en-US; nl-NL; ...
const url = '/terms/' + currentLng // => /terms/en-US; /terms/nl-NL; ...

Fallback to generic English fails for non en-US locales

  • I'm submitting a ...
    Bug report

  • What is the current behavior?
    Invoking the Action fails if the Assistant is set to "en-CA"

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:

    1. Set Google Assistant's language to "en-CA"
    2. Invoke the Action
    3. The webhook crashes and fails to return a response. (Action quits immediately)
  • Other information that could help us solve this issue:
    The webhook works fine when the Assistant is set to "en-US".
    The cause of this bug is that the webhook no longer successfully falls back to generic English when it's invoked from a device that's set to non-US English

This bug was discovered by @many7695

"What's my IOB" fails

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Asking Gluco Check for IOB fails

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:
    Say: "Hey Google, ask Gluco Check for my IOB". The call fails without returning a response

  • What is the expected behavior?
    Gluco Check says how much insulin is currently on board

  • Possible reason
    IOB requests are done by looking up the latest 'devicestatus'. But not all devicestatus objects include IOB. So if the latest document in the devicestatus collection does not contain the IOB field, the call fails.

  • Other information that could help us solve this issue:
    Possible solution: stop using v1 API altogether and switch to v3 so we can filter documents to only the ones containing the IOB field

Update documentation

Documentation (READMEs, CONTRIBUTING) should be updated with:

  • Frontend
  • Short descriptions of packages in contributing. Longer ones in their own readmes
  • Validation endpoint with auto-token creation ?

Replace /api/v1/entries/current with /pebble

  • I'm submitting a ...
    Refactoring request

  • What is the current behavior?
    To find someone's bloodsugar, Gluco Check queries the endpoint: /api/v1/entries/current
    If we were to replace this with a call to /pebble, we could potentially get the same information,
    while also reducing the number of API calls needed if the user has also requested IOB/COB.

  • What is the motivation / use case for changing the behavior?
    Eliminating an API call would speed up the response time

  • Other information that could help us solve this issue:
    Not yet sure if /pebble provides all the required info. This must be validated before switching can be considered

GlucoseUnit is not detected properly

Describe the bug
Reported via Reddit: https://www.reddit.com/r/diabetes/comments/nlt6xj/hey_google_check_my_sugar/gzo60si/?utm_source=reddit&utm_medium=web2x&context=3
I went to check the db, and it turns out there are several users with their Nightscout set to mg/dl, but we have their unit set to mmol/L.

Looks like detection of the glucoseUnit isn't working.
Not sure yet if this is a backend/frontend bug, but I'll enable glucoseUnitField on prod as a temporary fix.

To Reproduce
TBD

Expected behavior
When signing up with a Nightscout site using mg/dl, the settings in Gluco Check should copy that value

Additional context
Adding a hotfix to deal with this by always showing glucoseUnitField, even on prod.

Prevent multiple inits of singletons

Logs indicate the UserProfileClient gets initialized multiple times. But this class should be a singleton. Is there an easy way to prevent multiple inits? eg by setting the defaultScope in Inversify?

Add bèta link to Nightscout Status homepage

I'm submitting a ...

  • feature request

Description

  • We should add a link to the homepage of Nightscout Status, informing users that Gluco Check is now in beta and they can try it out

Tasks

  • Add beta message to Nightscout Status homepage
  • Write instructions to join beta (md file in repo?)

Maybe?

  • Add (inactive) message at the end of Nightscout Status action responses, notifying users of Gluco Check ?
  • When someone invokes Nightscout Status, send them an email to introduce Gluco Check ?

Invocations

Continuation of #59

This issue will serve to finalize all possible invocations. Both in the docs (README, frontend) and in the YAML files that make up the action.

Originally posted by @ddamico in #59 (comment)

New translation: Swedish

This issue tracks the release of Gluco Check in Swedish.
Translation contributed by @CarlRosell
Acceptance criteria to close this issue:

  • Swedish support available in Production

TODO:

  • Translation merged from Crowdin
  • Action Definition updated and deployed
  • Frontend: translation deployed
  • Backend: translation deployed
  • ...

Additional items to check:

  • Action definition
  • TODOs in code
  • Fulfillment URL
  • Beta test working?

Release phases:

  • Deploy to Google Assistant Alpha Channel
  • Live testing in Alpha
  • Proofreading / Fixing issues
  • Submit for approval by Google
  • Release to Google Assistant Production Channel

Voice not recognized

I have the glucocheck set up for my Goggle Assistant for my son's Nightscout site. I also set it up on his Google Assistant. During the initial tests it seems to work, but now when we ask for results it comes back and says it doesn't recognize us. I can ask Google who I am right before I ask about the blood sugar. It will respond with my name, but then won't give me the BG level.
Sometimes it will work and when it does it's great.
I even set up a Routine to make it easier to say so Google should get less confused about any pronunciation.
Ideally if I could have it just say the number regardless of who asks that would the best case for us.
Thanks

Bug: crash when query contains 0 resolved metrics

  • I'm submitting a ...
    Bug report

  • What is the current behavior?

  1. Invoke the action with "Ask Gluco Check for my bge" (note the typo: bge should be bg)
  2. The app crashes
  • What is the expected behavior?
    When no metrics can be resolved from the query, fall back to default metrics

Read COB, IOB, ... from Loop

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    If you're using Loop (instead of AndroidAPS/OpenAPS) you can't request IOB, COB and possibly other values

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:
    For a Loop user, ask: 'Hey Google, Ask Gluco Check for my carbs on board'

  • What is the expected behavior?
    "There are X carbs on board as of y minutes ago"

  • What is the motivation / use case for changing the behavior?
    Lot's of people use Loop ;)

  • Please tell us about your environment:
    iPhone with Loop

  • Other information that could help us solve this issue:
    Loop stores these values in a different schema than OpenAPS/AndroidAPS. The system needs to either fall back to using this schema if the user is not using OpenAPS, or needs to check which app the user has, and then look up the values accordingly

Remove potentially sensitive information from logs

  • I'm submitting a ...
    Refactoring request

  • What is the current behavior?
    Logs currently include the full DmQuery. This includes a user's token, email address and nightscout url.
    This information can be looked up when needed for troubleshooting, and has little value inside our logs.

  • What is the expected behavior?
    This info should be censored in logfiles.

  • What is the motivation / use case for changing the behavior?
    Only 2 people have access to the logs, but nonetheless... I believe we should try to operate with as close to zero-knowledge as we reasonably can.

Submit v1 for review

  • Privacy policy & terms added to frontend
  • All issues in https://github.com/nielsmaerten/gluco-check/milestone/1 resolved
  • FAQ document written + link to Discussions
  • Routines video published on frontend
  • Frontend deployed to production
  • Backend deployed to production
  • No more TODOs in code
  • URLs updated (terms, nightly/prod, ...)
  • Medical disclaimer active
  • Google Actions Pre-launch checklist completed
    • Reviewed invocations
    • Added directory info
    • Added testing instructions
    • Reviewed previous reasons for rejection

Read pump's reservoir level

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Gluco Check can't tell you how much insulin is left in the pump's reservoir

  • What is the expected behavior?
    Asking "Hey Google, ask Gluco Check about the pump reservoir" would be answered with something along the lines of: "The pump has 123 units remaining"

  • What is the motivation / use case for changing the behavior?
    I'd like to be able to know how much is left in my pump just by asking Google :) Don't wanna fumble around with those annoying tiny buttons.

  • Other information that could help us solve this issue:
    This would require adding another DiabetesPointer (eg PumpReservoir) and extending Nightscout-Queries. We can probably use the same call as COB, IOB and PumpBattery (= DeviceStatus). It will also need another Type in the Action

New translation: German

German translation by @utzaki - Thank you! 👏

We’re now looking for someone to test the new language on their own Google Home (or other Google Assistant-enabled device)
Can you help? Leave a message below or email [email protected]


Tasks:

  • Frontend: Deploy to nightly
  • Backend: Deploy to nightly
  • Update action definition
  • Test in simulator
  • Deploy to beta/alpha channel
  • Test on real device
  • ...

Update frontend to better integrate secret-to-token behaviour

** update react-hook-form either before this or as part of it, looks like there are changes in there that relate specifically to some of the behaviour changes we want to do https://react-hook-form.com/migrate-v6-to-v7/ **

Per conversation on Apr. 17th, the plan here is to...

  • validate input on submission instead of on change
  • switch the form label to token or api secret
  • add some copy explaining that we’re not going to retain secret, but will use it to generate token
  • update the field value to the "cleaned" value returned from the validation endpoint

Pump battery level not available for Loop-accounts

  • I'm submitting a ...

    • bug report
    • feature request
    • support request => Please do not submit support request here, see note at the top of this template.
  • What is the current behavior?
    Loop does not upload the pump's battery level to Nightscout, so the user can't ask for it.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem:
    Say: "Ask Gluco Check for everything" or "Ask Gluco Check for the battery level"
    Assistant says: "Pump's battery level is at percent" - There's no value, so the placeholder is just empty.

  • What is the expected behavior?
    TBD.

  • Please tell us about your environment:
    Use a Loop-account (= an account connected to a Nightscout site that's using Loop, not OpenAPS)

Point Nightscout Status users to Gluco Check

Gluco Check v1.0 is now generally available 🥳

How are we going to notify people currently using Nightscout Status (NS) to switch? Couple ideas:

  • When someone invokes NS, they receive an email informing them of Gluco Check.
    • That email should only be sent once, and when someone actively uses NS.
    • The email should only be sent if NS was invoked with a language that's already generally available (so just English for now)
    • Tracking this task here: nielsmaerten/nightscout-assistant#116
  • Add a message on the NS website (English users only)

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.