Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libre2 sync raw #3371

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

jodli
Copy link

@jodli jodli commented Feb 28, 2024

Following up on #1686.
I've fixed the commit history and solved the review requests (@tolot27) from the original PR.

Let me know what you think and thanks for this awesome work! 💝

@jamorham
Copy link
Collaborator

jamorham commented Mar 4, 2024

Can you explain what problem this is intended to solve? Many thanks

@jodli
Copy link
Author

jodli commented Mar 4, 2024

From the original authors PR:

Adds synchronization of Libre2 raw values with xDrip+ Sync service.
No options added as it uses Less Common Settings > Advanced settings for Libre 2 < show Raw values in Graph to decide if sync raw values (on master) and to show them on follower.
For implementing it a new message type has been added "l2r" to xDrip+ sync sender and receiver.

Basically it adds support for syncing the raw BG readings (the little white dots) from the Libre 2/3, which sends a new value every minute. At the moment it only syncs a new value to the followers every 5 minutes.

The reason it's interesting is that you get a much better understanding of trends. If you only look at the rolling average every 5 minutes, you get a very lagged view of where the BG is going.

@jamorham
Copy link
Collaborator

jamorham commented Mar 5, 2024

Ok thanks. Which data source is this to be used with? Do you know what the interactions are with the support for 1 minute readings in xDrip?

My concern this that this will generate a lot of wake ups for network traffic which will impact on battery life. The code should also at a minimum respect the follower power saving with something like a conditional of !Pref.getBooleanDefaultFalse("plus_follower_save_power")

@jodli
Copy link
Author

jodli commented Mar 5, 2024

Ok thanks. Which data source is this to be used with? Do you know what the interactions are with the support for 1 minute readings in xDrip?

So far I only know the Libre 2 and 3 sensors that support sending new values every minute, and the data source for these has to be set to Libre2 (patched App). My son is using Juggluco to share the data to xDrip.


I've also found the Smoothing article in the docs.

Smoothing adds a delay in xDrip+ BG from raw data. The delay is about half the smoothing period. Set the delay accordingly to the sensor behavior for your safety. If you don't use a DIY closed loop system with xDrip+ providing glucose values, set it to 10 minutes.

This is exactly the case I'm experiencing: It only syncs a smoothed value every 5 minutes to xDriip followers.


My concern this that this will generate a lot of wake ups for network traffic which will impact on battery life. The code should also at a minimum respect the follower power saving with something like a conditional of !Pref.getBooleanDefaultFalse("plus_follower_save_power")

I did not know about that setting. Sure, I will add it to the code.

@jamorham
Copy link
Collaborator

jamorham commented Mar 5, 2024

Does the data source you are using support 1 minute readings? I'm not sure from your message if it does or not. I think it is important to test this with one minute readings. I thought that would disable the value smoothing. Graph smoothing is something else which doesn't affect the live data value.

@jodli
Copy link
Author

jodli commented Mar 5, 2024

Yes, the libre sensors do send a value every minute.

You can see how the graph looks on my son's xDrip:
IMG-20240305-WA0113~2.jpg

You can also see the smoothing here where it's following the small white dots which represent the raw values.

@jamorham
Copy link
Collaborator

jamorham commented Mar 6, 2024

@jodli Have you tried with the one minute readings feature enabled? see here: #2680

@jodli
Copy link
Author

jodli commented Mar 8, 2024

@jodli Have you tried with the one minute readings feature enabled? see here: #2680

I'm not really sure what that change is about. On the device receiving the data from Juggluco we already have a raw value every 1 minute. The only thing missing here is to syncing those values to the followers.

@Navid200
Copy link
Collaborator

Navid200 commented Mar 8, 2024

I'm not really sure what that change is about. On the device receiving the data from Juggluco we already have a raw value every 1 minute. The only thing missing here is to syncing those values to the followers.

Wait!
You want to make all these changes to the xDrip code and you are not even going to use xDrip as a collector? You just want to use it as a follower?

@jodli
Copy link
Author

jodli commented Mar 8, 2024

I use both actually. My son has the CGM and is using xDrip as the collector. Then he's syncing that data to his followers (me and my wife).

I'm making these changes to be able to see all values my son also sees. 😆

@Navid200
Copy link
Collaborator

Navid200 commented Mar 8, 2024

@jodli I think that's the point about the suggestion.

xDrip already provides multiple methods for follower schemes like Nightscout ot xDrip sync.
I don't have personal experience. But, if you set up your son's xDrip to receive readings once a minute, you can then try to use Nightscout or xDrip sync to follow him.
I hope that would work.
And if it doesn't that may be where we should focus on improving xDrip rather than adding yet another different follow scheme.

@jodli
Copy link
Author

jodli commented Mar 8, 2024

Now I'm confused.
This does not add another follower scheme. It's utilizing the "xDrip+ Sync Follower" Data Source.

To summarize:

On my xDrip I don't see the raw values every minute (like he does as shown here), but a smoothed value every 5 minutes.

@jamorham
Copy link
Collaborator

jamorham commented Mar 9, 2024

@jodli Mainly I am asking is because as far as I know the libre raw data handling is quite hacky and the support for one minute readings is intended to supersede this which is why I am asking if this solves the problem overall or whether there are still things missing.

@jodli
Copy link
Author

jodli commented Mar 12, 2024

Hey @jamorham! I've tested the 1 minute reading support from #2680 and it works for the Libre (patched App) data source, although it's refusing a few readings, because of a too close timestamp (59-60 seconds between 2 readings).

This results in a weird discrepancy in the 1 minute readings between Juggluco and xDrip:

Screenshot_20240312-201957.png

This does however not solve my problem, because the 1 minute readings, even though they are in xDrip, are not synced to the followers (using the xDrip+ sync follower data source).

@jodli
Copy link
Author

jodli commented Mar 18, 2024

Hey @jamorham

I've cleaned up the conditionals about when to sync raw values to followers. I hope this makes more sense now.

Thanks for taking another look!

@PhilTU
Copy link

PhilTU commented May 26, 2024

Ok thanks. Which data source is this to be used with? Do you know what the interactions are with the support for 1 minute readings in xDrip?

So far I only know the Libre 2 and 3 sensors that support sending new values every minute, and the data source for these has to be set to Libre2 (patched App). My son is using Juggluco to share the data to xDrip.

Libre 2 sensors can also have Libre Bluetooth as the Hardware data source giving one minute values.

The confusion arises here because the alternative app Juggluco is master (has control of the sensor) and feeds data into xDrip+ by emulating the patched app. The diagram showing the Libre 3 feeding into the child's xDrip+ as a CGM input is not quite reality. This is why navid suggested it was a follower scheme, because xDrip+ is following juggluco via the patched app interface.

@jamorham
Copy link
Collaborator

jamorham commented Aug 7, 2024

I wanted to give an update of where I see the roadmap for this feature. Recently google discontinued support for the messaging services we were using. A new system is in place and in live use but there are some usage limits on it and so I don't really want to add new message types at the moment.

I have been working on a much higher capacity system which looks like it will work and also is designed specifically for xDrip usage patterns so will give a lot more flexibility in terms of what we can do. I'm currently testing this but it isn't ready for roll-out yet. Tentatively I would expect it to take another month.

What I would also expect is that we can add full support for 1 minute readings (although I am hesitant to wake the device up every minute and so granularity might be 2 minutes by default perhaps) - I also expect to be able to support more background syncing of data that doesn't need to be real-time. This should allow us to be more open about syncing certain types of data because we wont have to weigh up the load on phone/battery so much as a consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants