Nightscout API: Support for Libre 3

[swissalpine]

The Libre 3 stores a value every minute. This leads to problems of watchfaces etc. which are designed to evaluate one value every 5 minutes. It should be possible to continue to retrieve only values in 5-minute intervals via the API, either in principle or via an additional option (e.g. fiveMin=yes).

Example of current retrieval (entries):

"2022-04-01T04:39:29.000Z" 1648787969000 139 "Flat" 
"2022-04-01T04:38:30.000Z" 1648787910000 139 "Flat" 
"2022-04-01T04:37:29.000Z" 1648787849000 138 "Flat" 
"2022-04-01T04:36:30.000Z" 1648787790000 136 "Flat" 
"2022-04-01T04:35:29.000Z" 1648787729000 136 "Flat" 
"2022-04-01T04:34:29.000Z" 1648787669000 136 "Flat" 
"2022-04-01T04:33:30.000Z" 1648787610000 136 "Flat" 
"2022-04-01T04:32:29.000Z" 1648787549000 136 "Flat" 
"2022-04-01T04:31:30.000Z" 1648787490000 137 "Flat" 
"2022-04-01T04:30:29.000Z" 1648787429000 138 "Flat" 

Example of current retrieval (/entries/sgv.json):

[pavelvanecekcz]

I originally came across this problem, so I'll just allow myself a little clarification of how it happened. I used the script https://github.com/timoschlueter/nightscout-librelink-up for data transfer librelinkup - NS. And of course a big thank to the author for it. In case the user loses online connectivity via BT and the data is later read back from the sensor, then the intervals are every 5 minutes. When the user is online via BT, then the current values are loaded every 1 minute. As a result, the NS contains a mixture of values in 5 minutes and 1 minute intervals .

[whooze]

In my humble opinion this should be dealt with on the uploader-side. Nightscout digests anything that is thrown at it

[bewest]

Thanks for all the discussion and information provided. While signal loss can be frustrating Nightscout accepts glucose values whenever they are available. Could someone be more clear about the problem at hand? Is it that there are too many dots, or dots missing sometimes? Changing the polling interval won't change the number of data points available, and it's not clear why or how to ignore or transform some data points. I could imagine some potentially funny artifacts on watch displays filling in up to 9 dots at a time which might be discussed with the watch authors?

[swissalpine]

There are numerous applications that rely on the API. Even after Pepple, there are watchfaces that access the first example. These watchfaces only get the data points of the last 10 minutes with the typical query, instead of the last 50. I myself develop watchfaces, data fields etc. for Garmin devices. Here the amount of data of the queries in a background process is so limited (the whole process including the query must not exceed 32 KB) that I can download a maximum of 18 data sets of the 2nd example, so Libre3 users get only 18 minutes displayed on the graph, while Libre2 and Dexcom users see 90 minutes history here due to the 5 minute interval. Also, Garmin can only start such a process every 5 minutes, so reloading is also very difficult. But since the Libre 3 (which I do not use) but every minute a CGM value captured, stored and sent, probably all uploaders will also send every minute and Nightscout will digest it - why not? Therefore, it would be good if a 5-minute interval could be requested in the query in Nightscout - with a view to all the many applications that currently work with this standard interval ...

[pavelvanecekcz]

Not only watchfaces have a problem with the higher frequency of data provided. If I use xDrip as a follower, it is probably limited to the number of points and shows only the last 8 hours, which is probably about 480 points. If the API provided a secondary dataset, as an average of values after 5 minutes, it would probably be sufficient for these purposes. Of course, there is also a variant that the original uploader from librelinkup would average the delivered values.

[sulkaharo]

Chiming in - yea Nightscout and a lot of associated apps have been implemented with the assumption the CGM data interval is 5 minutes. The V1 REST API we have now is a simple wrapper on top of MongoDB queries and just passes the Mongo data back to the requester exactly as it's been stored and a bunch of apps also rely on this behavior, so there's no clear simple way to solve this that would not break some apps. FWIW I have been considering there should be an API call similar to the /api/v2/properties endpoint, which would collect core data most watch faces need, so it'd be possible to just make one REST request to Nightscout and get all data needed for visualising the last 8 hours or so with this single call.

[swissalpine]

That would be a great idea! However, Garmin watches cannot process a data volume of 8 hours in background processes (which are necessary for watchfaces). But surely there are ways to reduce this query if necessary. From the default query /api/v1/entries/sgv.json the amount of data of 18 records can be processed without out of memory error.

However, Pavel's problem has since been resolved because the uploader has reduced the data to a 5 minute interval. But others will surely want to exhaust the minutely libre 3 values ...