You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ps2 Here is a write-up on what appears to be the problem. I can put up a pull request if you like but would like your feedback beforehand.
LoopDataManager Currently Expects Device Token to be Persisted: In LoopDataManager.storeSettings(), the deviceToken is overridden by whatever is persisted in LoopSettings. Since LoopSettings doesn't persist the deviceToken, that is always nil. This was discussed in a possible solution in Store device token to LoopSettings #1494. That was declined though since the token should not be persisted per iOS guidelines.
NightScout Uploader is Created Lazily: When onboarding, the uploader will be set to nil in its lazy getter. This is not set again until rebooting the app (since lazy). This leads to the upload failing when the notification prompt is agreed to during onboarding.
registerForRemoteNotifications() only called during Onboarding: If you are offline during onboarding or setup Nightscout after onboarding, the deviceToken will not be pushed to Nightscout. Nothing seems to trigger registerForRemoteNotifications() later so there doesn't seem to be an opportunity to get the token again. Also, the token may change as discussed in the PR 1494, so it seems we need to allow the token to get updated. didFinishLaunchingWithOptions may be the place to put it per StackOverflow.
For number 1, I am using the token that gets fetched, rather than the token persisted at LoopSettings. Number 3 also helps with this to make sure we always fetch the token on startup. I did review Pete's suggested solutions in PR Store device token to LoopSettings #1494 but I think this change handles those same concerns.
For number 2, I removed the lazy getter. Instead I update the Nightscout uploader when the api key and url are set. This can be improved more by hooking into the flow in that class that sets all credentials. but I didn't want to spend a lot of time refactoring the setup of the uploader before any feedback. (Not sure if the case is handled of changing Nightscout credentials without reboot -- only if Settings get submitted when Nightscout service gets setup).
For number 3, I'm fetching the remote token on startup to ensure we always have a token. This doesn't handle the case of setting up Nightscout after onboarding but would be readily fixed with an app reboot for now.
I tried to modify the dev version with PR 1494 + your hack but always the same issue error. I tried to restart NS and re-compile Loop but no change. I seems unable to register the device token. Do I need to do a fresh install ?
@avouspierre This commit contains the updated solution LoopKit/LoopWorkspace@17bb9b6 Note there are changes to the NightscoutSerivce and Loop projects respectively.
Looking to use this also, but not totally sure how to build with this commit, any help is appreciated. Been missing the remote overrides :)
Thanks!
Ben
Is this still the only fix for remote overrides in Dev?
Symptoms: remote overrides don't do anything after Dev install. Locally set overrides also do not upload to NS Treatments table so they are not on the NS graph. I'm not sure if both of these are caused by the same issue since I haven't found mentions of the second. I haven't started my own debugging yet to figure out what's going on because I found this old issue.
I do not think this fixes the issue of overrides not showing on the Nightscout graph (missing the tape). This fix is in the remote bolus branch. I'm not sure of other fixes or what has made it into dev.
I noticed that @ps2 has fixed #2 mentioned above (NightScout Uploader is Created Lazily) in dev with the below commit. I'm not sure about the other issues I mentioned in this PR.
commit eb97cb140a7ddc27ed497ab414c30cfba44a68d1
Author: Pete Schwamb <pete@schwamb.net>
Date: Mon Feb 21 20:39:38 2022 -0600
Adding fetch of therapy settings, and fixing bug with uncalled completion handlers
I believe the issues described here are now fixed. There remain reports of Loop overrides not being triggered even when the notification arrives and is displayed on the user's phone. As best I can tell, this seems to be an issue with dasd not allowing Loop to be launched for some reason, and this behavior appears to be resolved with iOS 15.4 (beta).
Prior to this pull and build from today I was unable to enact remote overrides from Nightscout. As of this code it is working as expected. I can enact a remote override in Nightscout and it is invoked and appears in the Loop app. Before I would enact the override and nothing would happen on the app.
I'm not sure if this observation is part of this issue? I couldn't find another and hadn't opened one yet.
Activity
gestrich commentedon Aug 29, 2021
@ps2 Here is a write-up on what appears to be the problem. I can put up a pull request if you like but would like your feedback beforehand.
deviceToken, that is always nil. This was discussed in a possible solution in Store device token to LoopSettings #1494. That was declined though since the token should not be persisted per iOS guidelines.Don't persist the device token LoopKit#1536
gestrich commentedon Aug 29, 2021
Here's how I'm handling these various issues in the remote bolus branch for now LoopKit/LoopWorkspace@17bb9b6
avouspierre commentedon Aug 29, 2021
I tried to modify the dev version with PR 1494 + your hack but always the same issue error. I tried to restart NS and re-compile Loop but no change. I seems unable to register the device token. Do I need to do a fresh install ?
gestrich commentedon Aug 29, 2021
@avouspierre This commit contains the updated solution LoopKit/LoopWorkspace@17bb9b6 Note there are changes to the NightscoutSerivce and Loop projects respectively.
[-]Overrides Not Working in Dev[/-][+]Remote Overrides Not Working in Dev[/+]avouspierre commentedon Aug 29, 2021
Thank a lot @gestrich . The patch is perfect and allows to do remote overrides with NS
blameitonben commentedon Aug 29, 2021
Willbumster commentedon Aug 29, 2021
jonfawcett commentedon Feb 20, 2022
Is this still the only fix for remote overrides in Dev?
Symptoms: remote overrides don't do anything after Dev install. Locally set overrides also do not upload to NS Treatments table so they are not on the NS graph. I'm not sure if both of these are caused by the same issue since I haven't found mentions of the second. I haven't started my own debugging yet to figure out what's going on because I found this old issue.
Trpl7ca commentedon Feb 20, 2022
I don't use remote overrides, but my local overrides have not been showing up either in NS while using dev or dash-integration.
gestrich commentedon Feb 21, 2022
I do not think this fixes the issue of overrides not showing on the Nightscout graph (missing the tape). This fix is in the remote bolus branch. I'm not sure of other fixes or what has made it into dev.
gestrich commentedon Feb 27, 2022
I noticed that @ps2 has fixed #2 mentioned above (NightScout Uploader is Created Lazily) in dev with the below commit. I'm not sure about the other issues I mentioned in this PR.
ps2 commentedon Feb 28, 2022
#1614 should fix the token uploading issue and the issue with not calling registerForRemoteNotifications on startup.
ps2 commentedon Mar 4, 2022
I believe the issues described here are now fixed. There remain reports of Loop overrides not being triggered even when the notification arrives and is displayed on the user's phone. As best I can tell, this seems to be an issue with
dasdnot allowing Loop to be launched for some reason, and this behavior appears to be resolved with iOS 15.4 (beta).jgefaell commentedon Mar 6, 2022
Prior to this pull and build from today I was unable to enact remote overrides from Nightscout. As of this code it is working as expected. I can enact a remote override in Nightscout and it is invoked and appears in the Loop app. Before I would enact the override and nothing would happen on the app.
I'm not sure if this observation is part of this issue? I couldn't find another and hadn't opened one yet.
github-actions commentedon Aug 29, 2023
This issue is stale because it has been open for 30 days with no activity.
github-actions commentedon Sep 13, 2023
This issue was closed because it has been inactive for 14 days since being marked as stale.