Support basic custom alarm thresholds set via env variable

[scottleibrand]

No description provided.

[gregwaehner]

Scott - I'm happy to help as I can. I'm not the expert node.js developer, but i think you're heading down the path that you and I chatted about in the forum re: pushover pushes based upon environment variable threshold.

[scottleibrand]

Thanks @gregwaehner. I think this might be exactly your idea: sorry I'd forgotten who came up with it. :-)

I don't think we'll want to do push notifications in this first iteration, but simply getting the alerts configurable will be a big win and address a problem shared by a lot of people.

[gregwaehner]

Thanks Scott. Let me know where I can help. Via email, I'll let a test file... I stubbed out how the process and the existing URLs, etc. for how (in my mind) the alerting would work. And I've confirmed the pushover library in the existing build... looking forward to it.

[gregwaehner]

@scottleibrand For the basic alarm thresholding that you're talking about, are you thinking...

1. environment variable "BG_LOW" and "BG_HIGH" (or something like that)
2. modify client.js line 909 to use the env variables rather than 180 and 70?

[scottleibrand]

It's more complicated than just that, but yes, that's the first thing that
needs done. Feel free to PR that if you want, and then I'll do the
additional stuff to change the actual alarms (which are logarithmic math)
to use the thresholds.
On Sat, Nov 22, 2014 at 10:39 AM Greg Waehner notifications@github.com
wrote:

@scottleibrand https://github.com/scottleibrand For the basic alarm
thresholding that you're talking about, are you thinking...

1. environment variable "BG_LOW" and "BG_HIGH" (or something like that)
2. modify client.js line 909 to use the env variables rather than 180 and
   70?

—
Reply to this email directly or view it on GitHub
#271 (comment)
.

[gregwaehner]

@scottleibrand Here's what I've pulled together regarding alerting and PushOver design.

Environment Variables

PUSHOVER_LOW_BG null = do not alert
Design Considerations: Assuming, the PR has a new environment variables for "custom low" and "custom high" that integrate into cgm-remote-monitor GUI, but user may choose to not alarm for high or low in the GUI. So, if this design was to follow that model, then PUSHOVER would only trigger based upon the browser setting for alarming high or low. That simply feels too loose since there could be multiple devices to the same website which could impact that setting, and the entire premise for PushOver alerting is to have reliable alerting.

If PUSHOVER_LOW_BG was a separate fixed BG, such as 70, then it's more reliable... fewer combinations of user settings, devices, etc. And the user could have a "low and high" for cgm-remote-monitor GUI, but have a separate PUSHOVER notification for, maybe, extreme low or high. I'm thinking conceptually like standard deviation... cgm-remote-monitor alarm browser after 1 standard deviation; PUSHOVER low and high set at 2 standard deviations... I think the two concepts need to be separate.

Could have LOW_DEFAULT_PRIORITY_BG (80) vs LOW_HIGH_PRIORITY_BG (70) vs. LOW_EMERGENCY_PRIORITY_BG (60), but then you would need to consider which threshold level the BG falls into, and if you snooze in default priority, but then BG goes to high priority, do you override snooze. For now, keeping one threshold for low and high should suffice, letting the user define the priority of each.

Finally, the PushOver alerting should be the specific BG from dexcom, not forecasted -- keep it simple, and allow cgm-remote-monitor render forecasting.

PUSHOVER_LOW_PRIORITY (default value of 2 to bypass "quiet" hours, and force acknowledgement)
Design Considerations: Default value should be at least 1 to bypass "quiet hours." If you are telling the system to notify you, need to ensure it's not blocked by mis-configuration. I think the default value should be 2 which requires acknowledgement, treating the PUSHOVER LOW like BG 60, but cgm-remote-monitor alarm "custom low" for bg 80...

PUSHOVER_LOW_SOUND null = user device default
Design Consideration: adding for future use, but not the focus for initial release. Could be used in the future to complement "pebble alerting"

PUSHOVER_LOW_SNOOZE_MINUTES default = 30 minutes
Design Consideration:
1. need to account for the reality that a low will take some time before treatment recovers situation. If the user "snoozes," then don't send another alert until that time elapses.
2. There could be a hyperlink in the alert to "snooze" which would post to the site, and record the timestamp in a new variable for a LOW timestamp and a HIGH timestamp, but it would become overly complicated as you consider PUSHOVER distribution, viewing on Pebble watch, etc. The actual human factor makes it not realistic. The "snoozing" needs to be automated and not require user interaction.

PUSHOVER_HIGH_BG null = do not alert
Design Considerations: [same as LOW]

PUSHOVER_HIGH_PRIORITY (default value of 1 to bypass "quiet" hours)
Design Considerations: [same as LOW]

PUSHOVER_HIGH_SOUND null = user device default
Design Considerations: [same as LOW]

PUSHOVER_HIGH_SNOOZE_MINUTES default = 60 minutes
Design Consideration: [same as LOW]

Event Trigger

When cgm-remote-monitor "gets" the BG from the collection, logic should be called. Doing it from the "read" of the collection will cover Mongo and REST API methods.

Function Call

The function call should include the LOW vs. HIGH attribute such as sendPushOverAlert("LOW") or sendPushOverAlert("HIGH") in order to let the function call know and not have to figure it out again. Simple case statement or IF/THEN.

When call PushOver API for "non-emergency acknowledgement", the response is
{"status":1,"request":"e460545a8b333d0da2f3602aff3133d6"}

If you sent a priority=2 notification, you will also receive a receipt parameter in your response that can be used with our receipts API.
{"status":1,"request":"e460545a8b333d0da2f3602aff3133d6", "receipt":"......"}

SPECIAL CASE: Emergency Notification (Priority 2)
----------------------
1. Make API call, including "callback" parameter URL.
2. Get response from PushOver and parse both REQUEST and RECEIPT
3. Snooze 

Design Consideration: The emergency acknowledgement can be queried via API by cgm-remote-monitor, but you must provide the "receipt" id. I would rather have PushOver "push" the acknowledgement to us (plus it's "data in" so it's free in Azure) via it's API emergency callback. This would be used simply to record in CarePortal that there was an explicit acknowledgement action performed by someone, since the "alert being sent" is logged in CP. (see CarePortal integration)

Call Back URL is defined in the "emergency pushover alert" creation.
    Call Back URL... is POST ... example ... /pushoverCallBack

    PushOver system sends the following in the POST.
    receipt = (your receipt ID)
    acknowledged = 1
    acknowledged_at = 1360019238 (a Unix timestamp of when the notification was acknowledged)
    acknowledged_by = (user key) (the user key of the user that first acknowledged the notification)
Now "post to Care Portal" rather than writing the document to mongo collection.

Pushover Alert Object Parameters

device = Nightscout
title = Low/High BG
message = Low/High BG of . You will not receive another alert for minutes.
retry = 30 (seconds) () only used for emergency notification
expire = 1800 (seconds) = 30 minutes () only used for emergency notification
callback = http:///pushoverCallBack (*) only used for emergency notification
sound = if low vs. high ENV VAR

        Design Consideration: 
        Pushover "url" and "url_title" for supplementary URLs are not supported by iOS and should not be used for primary content. 

Alert Snooze (one global ... snoozing or not)

timestamp in Application / Global Variables using now() + <snooze in minutes>
    var date/time (epoch) PushOverAlertSnoozeUntil      "end time" of pushover alert snooze;

Data Definition
    1. Null means no snooze --> can send alert
    2. Time in the past means, no current snooze --> can send alert
    3. Time in the future means, current active snooze --> do not send alert

CarePortal Integration for Treatment Logging

If env(ENABLE)=careportal, then

1. Send PushOver alert, get the receipt id, and then post the "high" or "low" as CGM (sensor) readings in careportal (with the receipt in notes; CP priority of 0)
2. Acknowledgement of emergency notification (with priority of high to ensure multi recipients know that someone has taken action)

I have sample forms that model the process. (and HTML file that can't be uploaded here).... So here is copy/paste

/_/
/_* COPY INTO A SEPARATE FILE /
/****/

<title>Pushover Test</TITLE>

---

Preparation - Edit the stub file

1. Search/Replace %PUSHOVER_API_TOKEN% with your PUSHOVER token
2. Search/Replace %PUSHOVER_USER_KEY% with your PUSHOVER token
3. Search/Replace %SITE% with your website (https://name.azurewebsites.net -- no trailing /)

---

1. Create a Pushover alert

Title:
Message:
Token:
User:
Device:
Priority:	No Alert Default High Priority Emerg Notification
Retry:	(*)for Emergency Notification only
Expire:	(*)for Emergency Notification only
Submit:

Note: Copy the Response ID for Step 2 and Step 3

---

Step 2: To record the Pushover Alert BG into Care Portal

Entered By:
Event Type:
Glucose Value
Glucose Type:
Notes:
Submit:

Note: Need to be able to pass in "priority = -2". This is already recorded in PR 266 (#266)


Note: Copy the Request ID from Step 1 into "Notes"

---

Step 3: Simulate Response to Emergency Notification & record response

Entered By:
Event Type:
Notes:
Submit:

Note: Need to be able to pass in "priority = 1". This is already recorded in PR 266 (#266) Want to send close-out alert in the close of emergency notification.


Notes: Copy the Request ID from Step 1 into "Notes"

[jasoncalabrese]

I'm going to have some extra time over the next couple weeks and would like to take this on.

[scottleibrand]

Great! I haven't had any time to work on it yet, but would happy to help
and/or review what you come up with.

-Scott

On Thu, Dec 18, 2014 at 11:05 AM, Jason Calabrese notifications@github.com
wrote:

I'm going to have some extra time over the next couple weeks and would
like to take this on.

—
Reply to this email directly or view it on GitHub
#271 (comment)
.

[gregwaehner]

I’m going to finally get some vacation starting next week and I’m hoping to be able to focus on the pushover alerting that I was pushing as well… I’m nowhere as good as you guys, but I’ll be digging in.

•      Greg
  

From: Scott Leibrand [mailto:notifications@github.com]
Sent: Thursday, December 18, 2014 2:23 PM
To: nightscout/cgm-remote-monitor
Cc: Greg Waehner
Subject: Re: [cgm-remote-monitor] Support basic custom alarm thresholds set via env variable (#271)

Great! I haven't had any time to work on it yet, but would happy to help
and/or review what you come up with.

-Scott

On Thu, Dec 18, 2014 at 11:05 AM, Jason Calabrese <notifications@github.com mailto:notifications@github.com >
wrote:

I'm going to have some extra time over the next couple weeks and would
like to take this on.

—
Reply to this email directly or view it on GitHub
#271 (comment)
.

—
Reply to this email directly or view it on GitHub #271 (comment) . https://github.com/notifications/beacon/AHUcSf2lv-b5bCLNiWfKP3KU_yxmrP75ks5nYyERgaJpZM4C_UUc.gif

[jasoncalabrese]

@gregwaehner lets open a new issue for pushover based alarms, we can work on putting that together for E