Carelink follow no longer works

[EarthDevour]

It seems after latest medtronic maintenance xdrip is unable to use carelink follower as source.

[tadejkan]

Same issue here

[tadejkan]

By adding CareLinkFollowDL:v,CareLinkFollowDP:v in extra tags for logging, I can see the error is in processing data (at least for me)
: Not connected to pump => time can be wrong, leave processing!

And of course the official follower app is displaying data correctly.

[Navid200]

@EarthDevour According to that status page, you are not using the version of xDrip that includes the latest fix for CareLink.
You can always have a look at the release notes for something like that:
https://navid200.github.io/xDrip/docs/ReleaseNotes.html

[DrCR77]

For me the latest nightly (Jan 07) does not solve the issue.

[Algirdas-Z]

Yes I was a bit too quick to judge :) issue is still there. What is weird that sometimes xdrip gets new data for a brief period of time. However it is unusable at this point

[DrCR77]

FGOS: the latest nightly build incl. carelink fix does NOT fix the issue after the recent Medtronic update. I am not a developer, how can this be established as proper issue for Xdrip?

[Navid200]

@DrCR77 It is not going to make any difference.
I need an issue when there is something that I may forget. There are items that can be fixed by different individuals. Having a list of issues lets them see what needs their attention.

Carelink can only be fixed by one individual who has already been notified. We have to be patient for him to find time to attend to it if he can.
Changing this to an issue is not going to expedite that.

[DrCR77]

Thanks for the clarification! Good to know and lets hope he can find the time. For many Medtronic users with iOS patient's phone Xdrip with carelink follower is crucial.

[tadejkan]

Updated, same issue.

[tadejkan]

Actually, I was mistaken - it does work, there are simply some intermittent pump disconnects, which is why I was still seeing those messages (and which is why I'm not getting live data) - but that's probably just normal Medtronic issue.
I'll report back if there are more issues.
Thanks for now :)

[EarthDevour]

Actually, I was mistaken - it does work, there are simply some intermittent pump disconnects, which is why I was still seeing those messages (and which is why I'm not getting live data) - but that's probably just normal Medtronic issue. I'll report back if there are more issues. Thanks for now :)

Now it seems it is working partially. Xdrip gets some data, then sits there with "signal missed" for 60 minutes etc.

[kukuchta]

In my case, since like one hour xDrip is able to get the RecentData json object from the usual Carelink API endpoint every 5 minures, but latest readings have value of 0 and there are no proper timestamps.

At the same time, the original Carelink Connect app gets and displays the latest readings. Sounds like it was switched to some other API endpoint.

Before that there was a period of time when new readings in RecentData were present, but the pumpCommunicationState flag was set to false and that caused the CareLinkDataProcessor to skip the readings (my pump was in phone range all the time).

[ranvens]

I've updated to the latest release, haven't received data.
Installed to a new device and doesn't get data either.
Region for carelink is Australia if that makes any difference.

[kukuchta]

There is new version of service discovery endpoint at:

https://clcloud.minimed.eu/connect/carepartner/v11/discover/android/3.3
(previously it was 3.2)

That leads to updated oauth configuration file:

https://carelink.minimed.eu/configs/v1/oauth20_sso_carepartner_eu_v6.json

Its structure has changed significantly and there are some urls missing that are used in current authentication flow.
Unfortunately we need to find out how the new flow looks like.
@benceszasz

[AntoineKoeman]

I'm getting the same error with latest xDrip release. It did get some data last night, but since an hour of 5 it has no recent bg readings (they are set to 0).
Manually posting to https://clcloud.minimed.eu/connect/carepartner/v6/display/message results in
pumpCommunicationState is set to false even tho the follower device is connected (& can see the data). And bg readings:
"sg": 0, "kind": "SG", "version": 1, "relativeOffset": 256

[AntoineKoeman]

That seems to be working.

{
        "kind": "SG",
        "version": 1,
        "sg": 121,
        "sensorState": "NO_ERROR_MESSAGE",
        "timestamp": "2025-01-15T11:17:00"
      },

[AntoineKoeman]

Settings still point to the same ble endpoint. Strange

[kukuchta]

Yup, thats what we need to change in the Carelink Follower. But when I simply replace it in the follower code inside the xDrip i get 403 response for RecentData.

The point is that it works in the python client prepared by Ondrej. We need to carefully analyze the login flow there and see what are the other differences.

https://github.com/ondrej1024/carelink-python-client

[ranvens]

Should this be registered as an issue?

[DrCR77]

Yes please. I hope @benceszasz can look into this as most carelink followers cannot use Xdrip at the moment. The original Medtronic carelink connect just s***s.

[Navid200]

@benceszasz

[tloczekt]

There is interesting thing with this issue, that sometimes XDRIP can read data once with 2-4h break. I discovered that its probably happened when pump is disconnected with the system. I could make a proper (somehow) connection with the Carelink server for my own project using Ondrej solution and https://clcloud.minimed.eu/connect/carepartner/v11/discover/android/3.2. New received JSON data says that structure of data is changed. Main change is [patientData] root branch, datetime without zone and no indexes in the markers. They are using timestamp instead of it. So I think the problem with Xdrip is that this application can't find indexes and datetime fields because there is a timestamp now. System can't fetch data because recentData.markers are null. If you have isNGP is false (no pump state) then application skips index processing and correcting time shifting. Then Xdrip can read data somehow. This is my idea only and I can be wrong, but I would like to share info with you to make faster some solution. czw., 16 sty 2025 o 05:21 Navid ***@***.***> napisał(a):

…

@benceszasz <https://github.com/benceszasz> — Reply to this email directly, view it on GitHub <#3855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ7FLDGNRFIHANMMMWUKG2D2K4XVLAVCNFSM6AAAAABVFWPPOKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBVGAZTSOI> . You are receiving this because you commented.Message ID: ***@***.*** .com>

[PhilTU]

May be helpful to someone..

one hint from my side.
After the latest changes done by Medtronic for Carelink follower ,BG comes to xdrip from time to time .Just noticed that it's somehow related to accesing the Minimed app by the main user.
This morning when my son entered his bolus , I've got his bg on xdrip (after many hours of missing it).
I'm not sure if someone can use this hint to figure out about fixing the issue 🤗

[tloczekt]

I think rather when your son were using pump there was no communication with server for a while and then xdrip can read data. What it confirms my idea that status of pump influences for possibility of readings data.

[benceszasz]

The issue is caused by the BLE data endpoint used for following MiniMed 7xxG pumps. The endpoint url (v6) provided by CareLink in the country settings is outdated, it is not stable anymore.
The old BLE data endpoint very often indicates that the pump is not connected and the data it provides is not updated. Then, for some reason, it starts working again.
The new endpoint is the v11 version, which is used by the official follower application:
https://clcloud.minimed.eu/connect/carepartner/v11/display/message
I don't know where the offical application gets this endpoint address yet, but it could be used as a fixed value as a first step, since the old one worked well for a very long time: using the v11 url instead of sessionCountrySettings.blePereodicDataEndpoint when calling the getConnectDisplayMessage method in the CareLinkClient class.
Unfortunately, the structure of the data provided by the new endpoint differs from the old one in many ways. What's worse is the times. The times associated with each event were always a weak point: either there was no time at all or only an index (the past 24 hours broken down into 5-minute indexes), or the time zone was not included or the time zone was incorrect. Because of this, there was a complex time zone determination and time correction logic in the CareLinkClient.correctTimeInRecentData method.
However, the logic applied here does not work with the new data, so a new logic must be build to convert the times of events into time zone correct data.
I started working on it, but unfortunately currently I have very limited time, so if someone else has the capacity, please do not hesitate. It is important to note that the old logic still works well for Guardian Connect and Guardian 3 sensors, so you only need to use different logic for the data returned by the BLE endpoint, otherwise older standalone sensors will not work.

[kukuchta]

I have prepared working solution using new JSON format on my branch:

https://github.com/kukuchta/xDrip/tree/medtronic_maintenance_fix

Unfortunately it breaks the compatibility with Guardian Connect and Guardian 3, so it is not yet ready to be included in the official app, please treat it as a base concept that needs to be tested and integrated. And yes, there are still some null pointer exceptions to be resolved in the Log.

Unfortunately I cant spend more time on this now, i would gladly pass it over to any volunteer ;)

[benceszasz]

Nice work!
Unfortunately, compatibility must be maintained, as many people use it with a standalone sensor. Furthermore, I'm not sure that the change affects all regions, and I'm not sure that the time formats are the same. The reason there are so many formats for parsing dates is because there were so many different date formats depending on the region, device, and uploader phone used. There used to be complete chaos between date formats and sometimes even values. I'm not sure that a single sample will be enough to cover all cases. Of course, the situation may have improved and now everything is uniform, but I still have vivid memories of when it wasn't.
I'm also working on a basic version, in which I tried to maintain compatibility, but there's still a lot of work to do, currently I only have CGM and pump data, markers (insulin, carbs, bg) are still missing.

[kukuchta]

I'm totally aware of that, and it makes it much more difficult. Thats just the one small step;)
I hope they made a cleanup in the timestamps area and it just became as simple as it seems. But still Im not sure if we can rely on the cliendDateTime from metadata as it is the only field that holds any time zone information.

Another thing, I need to check how it behaves when pump is disconnected.

I can provide sample JSON for my setup and location.

[benceszasz]

I have completed my version:
2baa087

I am unsure about the date handling and correction, but we will see. In the US it uses the endpoint provided by CareLink, outside the US it uses a region dependent fix endpoint URL.

[benceszasz]

I finally manage to test the time zone correction of the new data structure, which is in the CareLinkClient.correctTimeInDisplayMessage method. On my test phone, I changed the time zone to US time zone, and comparing lastConduitDateTime to lastConduitUpdateServerDateTime detected a -9 hour difference and shifted the timestamps.

[benceszasz]

This issue only affects users outside the US or US region is also affected?

[kukuchta]

Im not sure, Im EU based. For now I just went with replacing v6 with v11 in url near the client.

[kukuchta]

Also not sure how will it behave in other time zones.

[rsallar]

I'm in Spain.

[benceszasz]

Ok, so it seems, that the new endpoint is only required outside US.

[Harrinator]

I am based in Germany and face the same problem: I do receive data (as follower), but usually about 2 hours late. It's a bit like receiving the weather forecast for yesterday...
I hope this can be fixed soon.

[benceszasz]

I have completed a backward compatible new version, which works with old standalone sensors, uses the old endpoint in case of US.
I have also created an installer for it, which can be downloaded from the following link for testing:
https://drive.google.com/file/d/17RAAIUqv0_JG8O-Rwg2h1nWgCTNdsqGZ/view?usp=sharing

This is a custom variant, the application name is xDrip+ variantX, so it does not conflict with the already installed xdrip application: the official xDrip+ application does not need to be deleted from the phone and it can be updated later.
I have tested with:

• available data: EU (Hungary) - 780G pump and standalon Guardian 3 sensor accounts
• no current data: US - 780G pump and standalon Guardian 3 sensor accounts

[kukuchta]

Working great in Poland, 780g and Simplera 😉

[patrikpozzolini]

I have tested for an hour with 780 + G4 sensor in Sweden. All works fine! 👌🏻

[benceszasz]

Thanks for testing, I will create a pull request to merge the changes into the offical version.

[patrikpozzolini]

I have tested for an hour with 780 + G4 sensor in Sweden. All works fine! 👌🏻

Seems I now get authentication errors and have to sign in again.

[DrCR77]

There is one oddity now: every treatment appears twice, consequently IOB etc is wrong

. I currently only run the xdrip instance once, all other uploaders are disabled.

[tloczekt]

Hi. I can confirm that Xdrip is working ok, but can't send data to watch. I tested few watchfaces of Xdrip and no success. Other watchfaces complication can be set with variables in the settings, but no data either. I will test more maybe reason is different sob., 18 sty 2025, 01:40 użytkownik mitchnic ***@***.***> napisał:

…

Running this for the last half an hour and the variant is working for me, values being received from Carelink etc. Will keep on testing. — Reply to this email directly, view it on GitHub <#3855 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ7FLDABEBETWJYDSG4YAB32LGPGNAVCNFSM6AAAAABVFWPPOKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBXGI3DEOI> . You are receiving this because you commented.Message ID: ***@***.*** .com>

[PhilTU]

Hi. I can confirm that Xdrip is working ok, but can't send data to watch. I tested few watchfaces of Xdrip and no success.

You should start a separate topic for your watch issue. If it is a problem with the current mainstream xDrip. Which watch and similar data should be included.

[tloczekt]

There was my wrong settings in the Xdrip. We can forget about it. This variant X XDrip is working smoothly with watch.

[EarthDevour]

Thank you all who participated :) final question, will be there nightly release with this fix anytime soon?

[Navid200]

It's already merged. That usually means there will be a release today.

[Harrinator]

It works! You guys are great. Thank you!!!

[JordiAlvaro]

It works! Thanks a lot for your support!

[DrCR77]

Hi Bence,Could my issue of double or even triple treatments entries be related to the recent changes?My set up: patient iPhone > Medtronic > Xdrip carelink follower > Nightscout. I do not download treatments from Nightscout to Xdrip, that feature is disabled. I reinstalled xdrip and also Nightscout (now 15.0.2). This is a snapshot of recent treatments in the mongodb. The 2 entries differ by 1 second. Since timestamps are relevant I thought it could be related?Cheers,Christoph Am 18.01.2025 um 11:43 schrieb Bence Szász ***@***.***>: Thanks for testing, I will create a pull request to merge the changes into the offical version. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[CenGo86]

Hi Bence,Could my issue of double or even triple treatments entries be related to the recent changes?My set up: patient iPhone > Medtronic > Xdrip carelink follower > Nightscout. I do not download treatments from Nightscout to Xdrip, that feature is disabled. I reinstalled xdrip and also Nightscout (now 15.0.2). This is a snapshot of recent treatments in the mongodb. The 2 entries differ by 1 second. Since timestamps are relevant I thought it could be related?Cheers,Christoph Am 18.01.2025 um 11:43 schrieb Bence Szász @.>: Thanks for testing, I will create a pull request to merge the changes into the offical version. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.>

Since the last update I have had the same problem with duplicate entries in the Xdrip app. I also upload data from Xdrip Carelink Follower > Nightscout