We are reaching out to share information on an anticipated disruption of CGM data in your Sugarmate account.
Regrettably, our Sugarmate app is no longer receiving Dexcom CGM data for our customers outside the United States . To date, Sugarmate has utilized a legacy channel to access Dexcom CGM data and as a result of regular Dexcom CGM updates to enhance scalability and performance, this channel is no longer available. We are still working to understand if this disruption will extend to Sugarmate app users in the United States in the near future, and if so for what duration. Customers in the U.S. will be notified at least 24 hours in advance if a disruption in service will occur.
We are collaborating closely with our partners at Dexcom to restore CGM data to the Sugarmate app. We know Sugarmate will need to be updated in order to work with official Dexcom channels and are committed to moving as quickly as we can, but do not currently anticipate having Sugarmate accounts outside of the United States reconnected before the end of the year.
We will continue to keep you updated through regular communications. In the meantime, we encourage you to utilize the G6 and Follow applications from Dexcom for your daily care.
We thank you for your patience and understanding and please accept our sincerest apologies.
Sincerely,
The Sugarmate Team
It doesn’t affect US users yet, though it’s not clear why. Yet another problem with Dexcom use; I rely on SugarMate for sensible alerts, I find the Dexcom ones unusable/useless even with the Apple improvements to control alerts on a per-app basis.
It’s about time Dexcom had an official, supported, on-phone interface for other monitoring apps; it is completely ridiculous for apps to have to obtain Dexcom data from the same device over the internet. That interface must exist or loop control wouldn’t work. I wonder how TidePool does it; Apple Health was receiving G6 30 minutes delayed last time I checked.
I just got an email from SugarMate (well, actually, it’s a bulk mailing from Tandem, the owners of SugarMate). The email suggests US users will lose G6 access soon:
Unfortunately, we are anticipating that CGM data will be interrupted beginn=
ing as early as Thursday, November 4, at 1:00 PM PT. To date, Sugarmate has=
utilized a legacy channel to access Dexcom CGM data and as a result of reg=
ular updates to enhance the scalability and performance of Dexcom CGM, this=
channel is no longer available.
What seems weird is that they haven’t fixed this - after all Control-IQ uses the G6 and I assume that isn’t going to suddenly stop working! It looks like it may be a consequence of the limited G6 connectivity, from the Control-IQ page on tandemdiabetes.com:
Dexcom CGM sold separately. Transmitter can only be paired with one medical device (either a Dexcom receiver or t:slim X2 insulin pump) and one consumer device (phone or tablet) at the same time.
So the Dexcom G6 app on my phone is getting all the bluetooth messages and SugarMate can’t (I believe this is actually a restriction in the software that the operating system uses for BlueTooth). It still seems lame; a restriction that Dexcom really wouldn’t want to maintain and which can easily be handled on the device (e.g. by updating Apple Health in real time!)
I wonder if the “legacy channel” they’re talking about is for accessing data stored on the Dexcom servers. Control-IQ is listening to the local transmissions from the G6 transmitter, not reaching out over the internet to read Dexcom’s servers. Do we know whether SugarMate is doing a database access to Dexcom as its data source?
SugarMate logs in to the Dexcom servers. So, for example, does Glooko. The difference is that SugarMate gets the blood glucose within five minutes of the last reading (so it gets the current reading), whereas Glooko is something like 3 hours behind; at this moment, 22:11 PDT, my blood sugar is 161mg/dl on the G6 app, if I switch to SugarMate it gives the same answer both on my phone and on the web (sugarmate.io/home). If I go to Glooko it reports that blood glucose is around 20mg/dl and has been since the period “7pm-8pm”, it has the right number for the 6pm-7pm period.
This is consistent with Apple Health, which has readings from the G6 app but the last reading is around 6pm; in fact it seems exactly 3 hours out of date.
Draw your own conclusions about what is going on…
The only relevant thing in any of that (the rest of it strikes me as just mealy mouthing) is:
We are finalizing the development and testing required to join the Dexcom Partner Web Application Programming Interfaces (API) program to integrate directly with Dexcom CGM data.
Given that the interfaces in question were only apparently approved in the US in July of this year:
(and many other articles in the same month). The interface is still server based. There doesn’t seem to be any direct access to our own data on our own phones, where it is stored.
Curious if Dexcom provided end of support dates for the legacy channel. Typically if your on legacy technology your roadmap should include a migration path to the preferred technology.
They usually don’t turn something off without warnings.
They are waiting for approval of the app by Dexcom; the developer agreement for the new APIs requires a developer to apply for Dexcom Partner status. You or I can sign up as a developer online; I haven’t done so because of certain things in the license agreement. Developers can use the APIs for their own data or a limited number of other individuals so long as they don’t make it public (either the data or the act).
However to go public, including but not limited to releasing an app in an app store, Dexcom have to approve the app and, well, pretty much everything. The Dexcom Partner agreement is secret - you can see it if you are a developer but you can work out what happens if you speak about it in public then.
The SugarMate statements (i.e. the Suzanne McKee ones) clearly state that SugarMate is in the latter stage - partner agreement - of the process. The process is here:
but the rub is that Dexcom can simply bounce you as a data partner, so it is understandable that the McKee releases and, presumably, Josh Juster himself are running very scared.
Are you getting real time data from this? I ask because NightScout pulls its data from Dexcom Clarity and Dexcom Clarity only shows updates (on the web) every hour; the Clarity app on the iPhone doesn’t show individual readings at all.
MyGlooko (Insulet’s recommended app) has the same problem; it pulls from “Dexcom” (I assume using the same route as Dexcom’s own Clarity app) and despite this comment:
You are connected to your Dexcom account. With access to Dexcom, it may take up to 4 hours for Glooko to display your data.
In fact the last data point I can see is 02:10 this morning; it’s now 09:11, so that’s a delay of at least 7 hours. (But that is Glooko - it is supposedly connect to Insulets cloud system but it hasn’t show a single reading since February 24.)
I asked Sarah Davis on the (official) SugarMate group what she is using as an uploader; she is the only respondent on that group who asserts use of NightScout. The other group is private; we’ll see if they let me join.
Obviously other people, including people on FUD, are using NightScout and I assume some of them are using NightScout with FireFly G6 transmitters (which means any recent G6 transmitter. NightScout’s web page implies, well, pretty much states, that Dexcom Share is the only way to work with the recent G6 transmitters, but elsewhere @docslotnick says that recent versions of xDrip+ work just fine:
Also the Spike web pages don’t seem to mention any issues.
So far as I can see NightScout and SugarMate are in the same position; they both get real-time data from Dexcom Share. SugarMate, being part of Tandem Diabetes, should have a really good relationship with Dexcom, but corporations are weird. Maybe NightScout have found some way of integrating the Dexcom Web/REST API?
There’s nothing magic, in the xDrip+ sense, in what NightScout do:
So that just adds log-in information for Dexcom Share to the NightScout code running on the internet inside Heroku. That (NightScout) code is available for anyone to read (I think; it’s a while since I tried Heroku.)
Thanks, but I have a stock of both Eros and Dash pods and a RileyLink; I never got round to building the RileyLink software. If I go back to Android I’m not going to have a problem - I can just use xDrip+ as I did before. If I build Spike for the iPhone I’m not going to have a problem either. If Insulet manage to release the next OmniPod version presumably that will solve the whole Dexcom issue by directly integrating with the G6 on the phone, or do they think they can get clearance for a loop system which requires the internet?
Loop sends data directly to Nightscout. Then, you can configure Sugarmate to receive data from Nightscout. Works great and Nightscout and Sugarmate are both updated as Loop processes new data.
Right, but how does it get it out of the G6? It’s a while since I looked at loopkit; I can’t remember how it gets the G6 data and it’s not obvious from github.io. Clearly looping can’t rely on having an always present internet connection (like NightScout) because it is controlling the pump locally (NightScout itself exists in the cloud, so can reliably connect to Dexcom Share unless the whole internet goes down.)
So… loopkit is actually connecting to the same device on the same iPhone as the Dexcom app; I had been under the impression that this was not possible. The explanation is here:
Loop eavesdrops on the Bluetooth communication of the Dexcom G4/G5/G6 CGM and writes the values to the Health app for the first 3 hours
After 3 hours, the Dexcom CGM app allows other apps (including the Health app) access to its CGM data, so Loop needs to read the older Blood Glucose from the Health app
During times when there is no CGM data, the user can enter a finger stick value into the Health app Blood Glucose (BG) screen and Loop will read it, e.g., during sensor warmup
Now that is interesting. Apparently loopkit can act as a data funnel to aggregators like NightScout without needing to take control of the G6 (like Spike).
I should add that loopkit is, like Spike, something you have to do yourself - i.e. you have to bypass the Apple protections and install something that you build and certify yourself. Spike is almost certainly far, far easier for most people (but it means you take over from the Dexcom app, which your endo may not approve of, well, actually, is not permitted to approve of.)
Not permitted? Aren’t physicians permitted to approve of off-label uses of prescription-only items?
I guess that if a physician gives an off-label recommendation that may transfer some legal liability, so maybe you mean the physician’s liability insurance provider won’t permit it?
