Back-filling missed data

[hightowe]

I have been using this software for a few days to stream Libre 3 data to Nightscout, and it is great. Thank you!

I have noticed a few times that when my son is away from his phone for an extended period (and therefore data is not flowing), that when he returns that this code will fill in some, but not all of the missing data. Both the LibreLink and XDip+ apps seem to fill in all of the missed data. The most items that I have seen this code fill in is 4 ("Upload of 4 measurements to Nightscout"). I am in the USA and using US endpoints.

I am wondering if the /graph API endpoint may need an additional parameter passed to request more data (further back into time) when data has been missed for a while?

[timoschlueter]

I have not noticed this myself yet but will look into it! :)

[hightowe]

@timoschlueter - just FYI, with a few more days gone by, I can confirm that I am seeing this behavior consistently. My son is a highschool basketball player and he leaves him mobile phone in the locker room during practice each day. When his phone is back in range of the Libre 3, a portion (the most recent portion) of the missed data populates, but not all of it. Just thought I'd share this additional detail to help frame the circumstances...

[emmatovar27]

I have the same issue! I'm using the FSL 3 from the US! I went outside without Internet for a couple of minutes, and when I returned to the apartment, the uploads started working again.

[timoschlueter]

Just a thought, but this might be timezone related. Maybe we do compare the LLU dates in one timezone with the Nightscout dates in another. I will try to replicate the behavior on my setup and look into it!

[hightowe]

@timoschlueter - I have not actually tried to trace or see the data flow, but getUtcDateFromString() implies that it returns UTC times and it appears to be properly used in both places (pull from LLU and write to Nightscout). A possibility that I do see is that the lastEntryDate() function does not seem to explicitly convert to UTC. That may be OK if Nightscout's API ("/api/v1/entries?count=1") only returns UTC dates, but I've not looked into that and, even if it does, and explicit conversion might still be a good idea, just in case that ever changes...

[durgok]

For ones that is able to make it work, Can you help? I hit the deploy to Heroku, although build was successful gives me a error about 'Cannot scale Dynos and free dynos are no longer available'? I even tried to subscribe to the eco plan but still see the same message. Am zero skill with programming so completely blocked.

[durgok]

This app.json script breaks since heroku no longer supports free dynos, Can we please update the script to specify as "eco" instead of free in the formation section?"

[timoschlueter]

@durgok absolutely! I will push an update later today. Since I don't use Heroku myself I wasn't aware how it all works. Thank you so much for investigating this issue.

[timoschlueter]

I just published version 1.9.1 of this app. This version should fix all Heroku related issues :) Thanks again everyone!

[durgok]

@timoschlueter Hi thanks for making the change, I have a follow up question. On my heroku dashboard, now I see 3 apps, One is what I created for nightscout which I identify very well as I created it from scratch. The other two are as follows: floating-lake-97757 and thawing-escarpment-75676. My question is that I don’t identify them explicitly but is this something that gets created implicitly due to deploying of your code that connects nightscout to Libre. Basically I want to understand if these are needed or not to run the nightscout-Libre integration successfully. A little background to this is I got an email from Heroku that I have consumed 80%of the dynos so am trying to see which ones I can optimize. Appreciate your inputs.