Feature request - Integrate alerting into Pavlok

[gregwaehner]

As a Loop Follow-er, I want to be able to automatically call one or more Pavlok API in order to physically alert the remote person.

1. LF call iOS Pavlok API or shortcut to zap, beep or vibrate the LF person. The action and variables might vary by alert.

2. LF make web call to Pavlok Webapp.
   Ability to enter a Pavlok URL and access token, and be able to assign it to one or more Loop Follow alerts.

Ability to enter multiple Pavlok URLs and respective access token.

Right now, Pavlok offers anonymous URL or Oath authorization. I’m asking Pavlok for something in the middle where we can define an access token. So initially, this request could be the public URL… and eventually the access token like the Nightscout settings.

I’m happy to walk you through Pavlok, its capabilities, the iOS app vs webapp, etc…

[jonfawcett]

I read the FB thread also. I don’t understand the need for this versus the PWD using alerts from existing apps/devices. Can you explain more?

[gregwaehner]

Thanks Jon. I’ll try to explain more background. The Pavlok is a wearable (think Fitbit) that does 3 things — physically shakes, sounds an alarm and/or gives you an electric shock (controllable). So depending on the actor, the use case varies.

Example: t1d is in some remote location (place 2) Maybe they are sleeping and not responding to audible alert. If they are wearing be device, loop follow could literally shake or shock them. LF could be on their phone or even mine (place 1). Think of a kid sleepover, camp, away on a trip where the parent is normally ‘the fail safe’ … but when they are physically remote (like 6 hours away) this provides another more intrusive fail safe for people who do not sense lows or may be asleep or just ‘too busy’ to stop and treat.

Flow 1 in my ER is for when the LF is local to the t1d wearing the device on the same iOS phone with LF and Pavlok.

Flow 2 in my ER is for when the LF is on my phone (place 2), but the t1d is somewhere else wearing Pavlok with IOS and Pavlok software.

hopefully this helps. In short, as a parent I want to be able to ‘zap’ the remote person based upon a LF alert…

[gregwaehner]

To connect the technical dot, Pavlok provides an API (webapp) that communicates with the iOS software, which interacts with the wearable. All I’m trying to do is loosely couple LF event (alarm) to an action (the Pavlok Web API) or to the local iOS API directly. Technically I guess one could ignore the IOS local API (or IOS shortcut) and always use the webapp API (just an http post) … I was simply calling out that if LF is on the person’s iOS with the Pav software (local), then LF going out to a webapp in order to come back in to the Pavlok s/w introduces unnecessary network dependency.

[gregwaehner]

Or even more generically, if LF could trigger a webhook in IFTTT, then that would work too. IFTTT has integration with Pavlok… it would simply be one more hop but would be a more generic way for LF to ‘send an event’ (Nightscout maker is not smart enough to pause events unlike LF which can snooze things)

[gregwaehner]

Update - the key Pavlok bug on iOS has been fixed. So the keep it as simple as possible, the use case is sends a webhook to IFTTT. IFTTT integrates with Pavlok and can make the wearable device physically vibrate, shock or beep. So if Loop Follow (which is very reliable and has awesome snoozing) could trigger the webhook to IFTTT, then it would be able to wake me up (wearing the device) so I could get juice for my child with t1d (who sleeps thru and turns off Loop/Dexcom alarms).

There are alternative technical flows if you don't want to trigger webhook to IFTTT website. If LoopFollow could invoke an IFTTT recipe via the IFTTT app on the same phone, then the same result occurs ... IFTTT to iPhone to Wearable.

I'm going to continue working on the NS IFTTT flow -- the issue is simply that I'm seeing delays and inconsistencies in the NS IFTTT call not making it to IFTTT...

[bjorkert]

We're tidying up the LoopFollow repo and noticed this issue has been inactive for a while. We're closing it to keep things organized. If this is still a concern or you have further insights, please don't hesitate to reopen or create a new issue.

Thanks for your understanding!