[Feature] Set Temporary BG Correction Overrides Remotely via Nightscout

[kenstack]

I've created some code (links below) to allow Loop to receive temporary BG correction targets remotely (from nightscout, though using IFTTT etc is fine) using Loop's override functionality for glucose targets. Instead of writing over user created preMeal and workout ranges, I created a new override called remoteTempTarget. It functions in the same way. I am very new to Swift, Xcode and Loop and Im far from a professional programmer so I'm sure this will need quite a lot of code review from the experts here, if the community wants such a feature in the first place. This opens up the usual security issues, but as far as I know no one has had any negative situations on the openAPS side which has this same feature. I think this feature will be particularly useful for those with small kids in a variety of situations, and for those of us who simply want to set some new targets remotely (ie not getting out of bed) if our PWD is trending high or low and we want to increase or decrease insulin for a period of time via changing the target. Again, the community obviously needs to decide if we want to open the door to allowing remote commands to be sent. So Ill put the idea out there for debate and discussion.

I've been running it for a few days now and @Kdisimone has tried it as well. Ive been setting temp targets via NightScout and so far so good. Im 100% sure the code could be cleaner and Im wide open to advice and criticism as Im using this to learn Loop. This same idea of course can be applied to other remote commands, but I think this one is the most basic.

Right now the code ignores the "type" of override sent from NS - eating soon etc - any Temporary Target events that are sent to Treatments are applied to remoteTempTarget and do not overwrite preMeal or workout, but that was just my thought. The requirements on this also need a lot of input from the community. This is a first cut.

https://github.com/kenstack/Loop/tree/nstemptarget
https://github.com/kenstack/LoopKit/tree/nstemptarget

if you want to try it you need to update carthage as there are a few small changes to loopkit which I couldn't figure out how to avoid - see #3 below - Im hopeful someone can point me in the right direction on how to keep all the changes in loop. The cartfile should point correctly to my github branch but let me know if there are issues.

There are some issues Id like to discuss if people are interested in the feature

1. I could not find a clean way to set the ranges of an override - I can set duration, etc but I could not set the range without editing the "rawValues" directly. Im guessing either I missed how to do this with the available methods or its probably better to create an extension to do this cleanly. I tried the latter but failed...

2. Once an override expires, ie duration has ended, the UI doesn't remove the blue bar. The actual correction target returns to normal (so the math is fine), but until the code does a clearOverride the blue bar remains. I tried hard to follow this but I couldnt figure out how the charts know the override has expired. Im happy to investigate this but I probably need some direction.

3. I had to add the new override in loopkit because I couldnt figure out how to do an extension in Loop, which is clearly a cleaner way to do it to avoid loopkit / carthage issues, but like above I failed (though I tried a few times..). If this is indeed possible and anyone can spend a few minutes pointing me in the right direction it would be much appreciated.

4. I struggled to decide where to call this functionality from. At the moment its in device manager and its called every time you loop (so once every 5 min) but Im wide open to moving it and if there is a more appropriate way/time/place to call it please suggest it.

Thanks to @Kdisimone for testing and lots of input and help with getting to know Loop and github. Thanks for reading :)

[scottleibrand]

Safety note: in OpenAPS we limit targets to >= 80 and <= 200 mg/dL - I would suggest similar limits for remote temp targets in Loop if they’re not already in place.

[kenstack]

Good idea @scottleibrand - will add some in an update.

[ELUTE]

+1 on this! I would like 70 to be the lower limit personally.

[lydiaoxley]

I would love to have this feature and the ability to set a higher weekend target for my 16yo daughter to combat the lows she experiences from her “school” basal. It was very helpful when we were using OpenAPS. I hope all kinks are ironed out soon and it becomes part of the code.

[elnjensen]

@kenstack Regarding your point 2 above, about the UI not updating when the override expires, that's actually an issue with the main branch, too, e.g. if you set workout mode the blue bar doesn't disappear when the target expires. (It does eventually, but there's definitely a post-expiration time window when it's still there.). I haven't filed this as an issue since it's pretty minor, but it's possible that fixing it overall would fix it for your new case as well.

[kenstack]

@elnjensen thank you for the insight! Yes Im sure fixing it in the main branch would. I just noticed it during ym testing since I was setting lots of short ones and initially I was scared the target was wrong (it seems fine). I think it stems from the fact that when an override expires, nothing resets it to nil, and the charting therefore thinks its still alive. Other option would be to have the chart only display the actual duration not the distant future duration. As you say, not a big deal.

[kenstack]

FYI - after some discussions with @Kdisimone I found out that the NS careportal is mg/dL only. mmol/L users have to enter temp target ranges in mg/dL, even for OpenAPS and then they are converted to the chosen unit type. Ill add this shortly but Ill need to find an mmol/L user to help me test as I believe Loop sets the units off the Dexcom data and I only have access to mg/dL.

[kanserh]

This would be a useful feature for me. I am often going to settings in Loop and changing my Workout temp correction range so that I can drive Loop to give a little more or less insulin before either exercise, meals, important work presentations, event where you simply can't go low etc. etc. etc. Having the ability to set a temp target through NS would make this easier for me to setup a small handful of common temp targets via IFTTT DoButtons.

[ELUTE]

I have been using this for a while and LOVE it! I think it would help so many people.

[ps2]

I think it's time to revisit this. The original holdups for this feature, as I discussed with several of you, were insecure nightscout setups (non-https, and running old versions w/o auth required), and it also seemed this feature should really be based on push notifications. Lastly, I wanted to make sure the experience of the user on the Loop side was respectful, letting the user know when one was enabled, and offering the ability to cancel.

I believe most users do have secured nightscout sites now, that require auth, so that is no longer a worry.

Nobody stood up to do an APNS implementation, or thought it would be too hard for users to set up. I've reviewed the current process for setting up APNS and thought about how users would need to configure NS to support it, and I think that it's no more difficult than the steps they already perform. They would need to log into apple developer account, create a push key, which is just a few clicks, and copy it to a Heroku environment variable. The bigger part is that this would basically be a rewrite of the feature Ken originally developed, and code to send apple push notifications would need to be written for NS, and code to handle them written for Loop.

The other thing that is changed since this ticket was opened is Michael Pangburn's Overrides. This is a natural feature to tie in if we are going to support remote overrides. The override presets are already being synced to Nightscout via the profiles datatype, so we can use that for offering NS users options of which preset to enable. The current override with details is also being synced to Nightscout via profiles, so we can use that to confirm remote engagement or cancellation.

This is one of the main remaining features that is causing people to use and maintain long running side branches, which contribute to user confusion about which branch to use and rework in terms of migrating fixes. It would be nice to have an option for users who need this ability in mainline Loop, and I'm willing to dig into implementation to make it happen.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.