Dexcom is returning Trend a string, not an integer in EU region

[cpitchford]

I noticed at 2021-11-30 17:45:00+UTC that the direction arrow in nightscout was incorrect (shows a <=> character)

Tracking back in my syslog I found evidence that the direction information being stored in Nightscout no longer had accurate trend information: Here's a dump of the "glucose" value after dex_to_nightscout():

This was the last working collection from Dexcom:

Entries [ {
  sgv: 62,
  date: 1638294113000,
  dateString: '2021-11-30T17:41:53.000Z',
  trend: 4,
  direction: 'Flat',
  device: 'share2',
  type: 'sgv'
} ]

Then the very next collection was broken, and the type of trend has changed to a string.

Entries [ {
  sgv: 59,
  date: 1638294412000,
  dateString: '2021-11-30T17:46:52.000Z',
  trend: 'Flat',
  direction: 'NONE',
  device: 'share2',
  type: 'sgv'
} ]

direction is now "NONE" and trend is now a string "Flat"

Working backwards it seems the payload received from Dexcom during the fetch operation has switched the Trend property from a number to a string, (in this example the value is now "Flat" instead of 4

This causes the dex_to_entry() function to return an incorrect object, trend is now a string, an direction is always "NONE"

This affects me in the eu region (I'm a UK user)

[cpitchford]

I've put together a patch to support string and integer Trend values from Dexcom here:

#51

[p-kimberley]

@cpitchford The Dexcom change also breaks the date regex pattern. The new format is: "Date(1638314763000)", whereas previously it was "/Date(1638314763000)/".

For reference, he's a raw response from the ReadPublisherLatestGlucoseValues API endpoint:

[{
    "WT": "Date(1638314763000)",
    "ST": "Date(1638314763000)",
    "DT": "Date(1638314763000+1100)",
    "Value": 94,
    "Trend": "FortyFiveUp"
}]

[bewest]

I think this is actually ok. The regex used should look for anything inside the parens.

> d = {
    "WT": "Date(1638314763000)",
    "ST": "Date(1638314763000)",
    "DT": "Date(1638314763000+1100)",
    "Value": 94,
    "Trend": "FortyFiveUp"
}
> parseInt(d.WT.match(regex)[1]);
1638314763000

[EiWasDann]

Problem is persisting and now whole EU is affected.

[aardvaaark]

This issue is now appearing in the US region as of ~5pm today (12/8)

[codelinx]

US - change effected my setup as well.