/lib/pebble.js

[gregwaehner]

Hey there - as I look to modify the cgm-pebble community code for the trend arrow, I started with input from cgm-remote-monitor /lib/pebble.js. A couple of questions to make sure I'm tracking things correctly before I start mod'ing code.

1. The db query for the collection pulls the last 10, but the output via pebble.js is explicitly cgmData.slice(0,6). I am assuming this is for performance to limit the amount of data pulled and processed. Can you confirm?
2. The JS file defines 40 minutes in milliseconds (2400000), but then in the function multiples by 5. So it could go back 200 minutes. But if the output is limited to 6, can you help me understand why the 40 minutes much less the 200 minutes? Could simply be moving parts, but I want to ensure I'm not missing a subtle data control.
3. The file has DIRECTIONS defined [0-9]. Do people have a preference for determining trend? The simplest is to take (now) - (last) / array length. But since you're already looping for direction, I could take the sum of each "direction" and average, and then round. A final model would be to simply show the "direction" for the last BG. Personally, I think the trend needs to be the average to account for ups and downs, but since the direction is already calculated in this file per BG, that may have been the thinking to date. ??
4. I noticed that when things are forecasted, my dexcom-uploader registers "10" as the BG rather than "???" from my Dexcom. Not having read through Dexcom-uploader yet, are there any business logic rules that need to be accounted for? For example, if "now" is BG 10, then stop b/c the data is bad. Or, if slice 3 is BG 10, then stop the averaging there? Likewise, it looks like direction value 8 and 9 would be cases for exception processing.
5. Rather than having the pebble watch face JS calculate the overall trend, I'm thinking about extending the /lib/pebble.js response to include that after the BGs -- let the appservers do the processing, pass the single value, and let cgm-pebble display. I started with the mindset of modifying the cgm-pebble codebase for everything, but tonight I'm viewing "cgm-pebble" like the View of MVC whereas "cgm-remote-monitor" is the Control in relation to pebble.

Thanks for your thoughts!

• Greg (greg@waehner.com)

[bewest]

Howdy Greg!

numbers 1 & 2 magic numbers

Re, numbers 1 & 2: keep in mind that some of this is "frankencode" and some was just done as quick as possible to get "something" to display. Specifically, when I wrote the lib/pebble.js stuff, I had access to stale data and wanted to ensure "something." The number, 6, 10, "forty minutes" times 5, etc, are all legacy. Feel free to be aggressive here, there is no magic, and no sane reason for the inconsistencies you mentioned, just hacky code :-). The actual watch js only sends one message to the pebble with just the last reading. There's no control logic here, just left-overs from very quick development.

Number 3

I'm hesitant to weigh in on this. The dexcom reports the trend, and that's what we've been using. There's no loop, the if (foo in bar) idiom just checks to against two "data models": one version of the dexcom-uploader that reports the trend to mongo, and one that does not. The check happens to help avoid errors.

Number 4 dexcom magic readings

Yes, Dexcom itself reserves a number of "special glucose readings" which are not glucose readings, but other signals.
The DIRECTION hash at the top of the file is one copy of these mappings.
Here's another list in python https://github.com/compbrain/dexcom_reader/blob/master/constants.py#L78

Number 5 pebble view

Yes, I think everyone could get on board with this. The pebble js should just prep and display some data, ideally as thin as possible.

You might get a kick out of looking over #7, which has a few objectives laid out, and some progress towards them, and may help yield some additional folk-lore/insight/perspective.

[bewest]

Closing this for now. Check out https://waffle.io/nightscout/cgm-remote-monitor, and re-open as needed.