-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MiniMed 715 history parsing fails #18
Comments
Things that would help:
|
Have tried filling the pump memory with known to work events and that seems to result in the pump working for a few hours, after which some event appears that breaks the event parsing fully. Another observed symptom is, sometimes an event is parsed in a manner where fetching the history only produces partial history, causing IOB to be calculated wrong. I'm observing the latter is due to the date parsing fail, where the parser stops returning events after hitting an event that's mis-parsed as too old. |
@sulkaharo we had a fix for some date parser issues a few months ago - what version of decocare are you using? Just making sure its not a version problem. Ill try to check later that the change made it into master too make sure your mm-decode file has this after the datetime import - that helped me tremendously on time parsing issues import datetime the other thing that is possible to do - but a bit risky - is to trap errors in mm-decode and still spit out the rest that do decode - problem is you could potentially miss one ... |
@kenstack Latest master from this repo. Another thing that could help is porting the data dump tools in decocare to work on radios newer than the CareLink. Realized I currently only have working computers with USB 3 ports, which are incompatible with the old USB 1 CareLink stick. |
@sulkaharo sorry added a comment above :) |
@sulkaharo I did the PR for json.JSONEncoder.default = lambda self,obj: (obj.isoformat() if isinstance(obj, datetime.datetime) else None) - could it have broken things on the 715? Perhaps comment it out and try it again - I tested with a 723 and a 722 not a 715 .... I doubt it but something to try |
Will try, thanks! I also found a spare Pi & CareLink stick, will try to run Ben's data gathering status_quo.sh on the problematic pump tomorrow. |
Ok read through the decocare documentation with more thought and found the instructions how to dump the memory into files, which are now here: https://github.com/sulkaharo/715debugging Based on trying to run the decoder on the files, some files do produce errors. The nice this is, this is now reproducible. :) |
I used list_history.py and list_opcodes.py to process the files and put the results to the repo. Looking at the output, many of the files parse ok (or at least produce some results), while 20 of the 37 pages immediately terminate the processing with MISSING DATETIME error. This is an old pump that's been in use for years, so I doubt any of the pages are actually empty. |
@kenstack mm-decode-history-page.py has the line and it doesn't make a difference to the decoding whether it's there or commented out. The two errors that appear during decoding are
|
If @bewest feels like looking at the data files mentioned above, that'd be amazing. |
I'm not sure about this, but it seems each page stores a different set of records. I've done some testing, I get this error on any page above 6, using "openaps use pump read_history_data #": Traceback (most recent call last): |
Small update: looks like official Medtronic software can read this pump without glitches, which indicates the issue is with Decocare. |
I'm trying to get a 715 working with OpenAPS and it's clear the decocare history page parsing doesn't actually support this pump. Some of the events do parse correctly but not all. The two stack traces I've seen so far are:
and
I logged some of the packets and the date error seems to be caused by the date parser being handled bytes that cannot possibly be a date, resulting in the parsing completely failing or the date being bogus (year deciphered anywhere between 1970 to 2056).
The text was updated successfully, but these errors were encountered: