Cgm decode enhancements

[tmecklem]

• decode new event opcodes
• Change timestamp offsets
• Implement forward offsets on current page
• Real world testing

This PR implements enhancements listed in #15. This is the result of several weeks of discovery work done while porting the decocare cgm page decoding to rileylink_ios.

Summary of changes:

• Add new relative sensor events data high, data low, sensor error, and sensor packet.
• Change timestamp offset algorithm to process events in same (reverse) byte order as page read
• Implement forward-looking relative offset from sensor timestamp when it is believed that doing so results in correct decoding
• Implement glucose history timestamp write operation + page refetch when it is believed to be necessary for accurate decoding
• Add additional metadata from cgm events nestled within the timestamp bytes
• Add fairly comprehensive decoding and timestamping test suite (nosetests tests to run suite)

[tmecklem]

Update: I've been investigating some strange results (minor gaps and duplicate entries in NS). The raw cgm json has the correct sgv entries, but certain entries get dropped somewhere during invocation of the various openaps cgm reports.

After some research, I've made a couple of changes to oref0-setup to stop pushing treatment data to the NS entries collection, and to stop calling get-ns-bg when using MDT cgm (since there's almost no chance that NS will have newer sgv than reading directly from the pump glucose history). Those two changes seem to have corrected the input to the recent-missing-entries algorithm that was returning incorrect gap ranges.

I'm running with the modified oref0-setup for a couple more days before I'm ready to check the "real world testing" box in this PR and submit the oref0-setup changes via PR to that repo.

[tmecklem]

The previously mentioned changes to the oref0 setup for MDT cgm have had the desired effect and the data is now consistently being uploaded to Nightscout without the previously encountered gaps. Backfilling works reliably in my experience so far, so I am comfortable saying this is ready for a wider audience to test.

Relevant PRs:
openaps/oref0#287
openaps/oref0#288

[Bender1061]

I ran this Tuesday with no issues. going to test this all day today and if no issue tonight. Love the part about the high blood sugar showing up at 400 (not that I get near as much of those as I used too)

[Bender1061]

@tmecklem maybe I'm going something wrong, but for some reason, trying to clone your branch does not work, and it seams to be that the name of your branch is too long. I was able to get it to work by forking your branch and copying your branch to another and just calling it dev1. Strange, but everything has been working well and I have not seen any problems.

[tmecklem]

@Bender1061 that's interesting about the branch. I'm glad you got it working!

[tmecklem]

These changes are holding up well in testing. I haven't had an opportunity to observe the newly decoded high or low glucose events yet.

I'm fairly confident that will work correctly when encountered having decoded both events from historical glucose pages in research.

[Bender1061]

Just had a High event this morning testing with this, everything worked as expected. 👍

[tmecklem]

This has been used for looping full time since the beginning of the year and it's been smooth sailing. I'd like to ship this work. Are there any remaining barriers to getting this into the dev branch?

[scottleibrand]

If anyone else who's tested it, or reviewed the code, can also give a 👍, I'm happy to merge it. Unfortunately I am not much good with python, so I can't really review it myself.

[scottleibrand]

@Bender1061 if you can give it an overall 👍 that is also good enough for me. Not sure if that's what you meant with your last comment.

[Bender1061]

👍 I've been running this branch for several Months and It's been working great for me.