These are chat archives for nightscout/intend-to-bolus

19th
Mar 2015
diabeticgonewild
@diabeticgonewild
Mar 19 2015 00:15
@jasoncalabrese , @danamlewis , @scottleibrand , @bewest , I created a PR for the commented version of the IOB-COB code. It also has the Medtronic 530G IOB function and a customizable activityContrib, based on duration of insulin action
there may be a couple of lines with the comment marker "//" missing though. I will try to double check that I didn't miss any.
I commented the code as a favor for somebody, and I know that this can be useful.
Scott Leibrand
@scottleibrand
Mar 19 2015 00:50
do you have it running on your site, or did you just do the code offline?
diabeticgonewild
@diabeticgonewild
Mar 19 2015 00:50
did the code offline
Scott Leibrand
@scottleibrand
Mar 19 2015 00:50
it might also be worthwhile to make it two pull requests, one for just comments, and one including the new code
the comments will be easy to review and merge if they look good, without any testing
we'll need to get someone to test the actual code
diabeticgonewild
@diabeticgonewild
Mar 19 2015 00:51
OK, will do.
I don't use NS, so that's a problem, or I would test it.
I'm making an uncommented version of the code right now, just FYI.
I tested the IOB and activityContrib in MATLAB though.
Jason Calabrese
@jasoncalabrese
Mar 19 2015 02:24
What would be nice is documented tests
Prove the current formula does what we expect
diabeticgonewild
@diabeticgonewild
Mar 19 2015 02:25
Is it OK if I do that in MATLAB and put the results in an excel spreadsheet with screenshots? Or not?
I don't know a lot about github
Scott Leibrand
@scottleibrand
Mar 19 2015 03:12
@bewest you around?
@bewest I'm having trouble with mm-latest.py writing out "date": output an hour in the future if I change the pump time to PDT
the "timestamp": field has no timezone, and it's correct
Jason Calabrese
@jasoncalabrese
Mar 19 2015 03:16
Might be missing the DST offset, thats what happened in the uploader
Scott Leibrand
@scottleibrand
Mar 19 2015 03:18
yeah, it's definitely a DST thing. working through his help files and comments from the original github issue
looks like he provided a way to override timezone at least...
ah, and that was committed after the version I was still using. :)
Scott Leibrand
@scottleibrand
Mar 19 2015 03:28
hmm, except changing that doesn't change the unix date output, just the datestring
Ben West
@bewest
Mar 19 2015 03:29
hmm
Scott Leibrand
@scottleibrand
Mar 19 2015 03:31
I'm trying this syntax: /home/pi/decocare/bin/mm-latest.py 180 --parser-out /home/pi/dana.latest --rtc-out /home/pi/dana.rtc --timezone MDT
hmm, actually none of this output has timezones at all
am I missing an option to enable it?
an earlier comment on the issue mentioned --append-locale, but that isn't valid
bewest/decoding-carelink#63 that is
Scott Leibrand
@scottleibrand
Mar 19 2015 03:40
@bewest any ideas?
Ben West
@bewest
Mar 19 2015 03:43
so, trying to undersatnd
the pump is in PST/PDT?
Scott Leibrand
@scottleibrand
Mar 19 2015 03:43
so the first problem is I can't get it to write timezone output at all
Ben West
@bewest
Mar 19 2015 03:43
what zone is your pc in?
Scott Leibrand
@scottleibrand
Mar 19 2015 03:43
everything is now in PDT
Matthias Granberry
@mgranberry
Mar 19 2015 03:44
pumps in general don't understand timezones
Ben West
@bewest
Mar 19 2015 03:45
everything in same zone and it's still hour wrong?
Scott Leibrand
@scottleibrand
Mar 19 2015 03:45
yeah
it's somehow deciding to write out the epoch time as if its input time is PST
so, first question: how do I get timezone appended to isodate's?
--timezone doesn't do it
Ben West
@bewest
Mar 19 2015 03:50
which branch are you using?
bewest/decoding-carelink#65
Scott Leibrand
@scottleibrand
Mar 19 2015 03:50
I'm now on master
Ben West
@bewest
Mar 19 2015 03:50
ah
ok
lemme merge this
so git pull
ok, that's merged
Scott Leibrand
@scottleibrand
Mar 19 2015 03:52
File "/home/pi/decoding-carelink/decocare/commands.py", line 627, in getData
return lib.BangInt(data[0:2])/10.0
File "/home/pi/decoding-carelink/decocare/lib.py", line 235, in BangInt
( x, y ) = ints
ValueError: need more than 1 value to unpack
get that running mm-latest.py after a git pull of whatever you just pushed
ok, re-ran it and I now have timezones, defaulting to UTC
trying with --timezone PDT
no change, still +00:00
Ben West
@bewest
Mar 19 2015 03:58
so the time is right and in zulu time?
Scott Leibrand
@scottleibrand
Mar 19 2015 03:59
yes, it looks that way
lemme check the offset
Ben West
@bewest
Mar 19 2015 04:00
if offset is 0 it's zulu/utc
Scott Leibrand
@scottleibrand
Mar 19 2015 04:01
no, I was checking that the epoch time was correctly offset to what would've been right if the pump was on UTC. looks like it's correct.
sleibrand@diyps:~$ date -u -d null@1426708
Wed Mar 18 19:55:08 UTC 2015
and that basal was indeed issued at 19:55 local time
Ben West
@bewest
Mar 19 2015 04:02
yeah, so all these timestamps are in utc
hmm
Scott Leibrand
@scottleibrand
Mar 19 2015 04:03
so now I need to be able to tell it --timezone PDT (or better yet, have it infer it)
it's ignoring that right now
Scott Leibrand
@scottleibrand
Mar 19 2015 04:04
weird
Ben West
@bewest
Mar 19 2015 04:04
that's the expected result I think
Scott Leibrand
@scottleibrand
Mar 19 2015 04:05
why both PDT and UTC?
Ben West
@bewest
Mar 19 2015 04:05
so the thing to notice here
is that the timestamp is identical regardless of which zone it's in
which is the problem, fundamentally, with using epochs
eg, the delta between "now" and "when time started" is identical, even if it's shifted by hours, the delta is constant
Scott Leibrand
@scottleibrand
Mar 19 2015 04:06
well, epochs are great because of that, as long as you're calculating your epoch from a timezone-aware system that converts to UTC properly
Ben West
@bewest
Mar 19 2015 04:06
that's what this is doing
no, epochs are really bad
we need to be switching to using iso8601 everywhere :-)
Scott Leibrand
@scottleibrand
Mar 19 2015 04:07
epoch = "seconds since Jan 1 1970 00:00 UTC"
so as long as I know the iso8601 time, I can calculate the epoch
Ben West
@bewest
Mar 19 2015 04:07
if all you have is epoch, you have no idea when on earth it took place
whereas if you have iso8601 you know exactly
Scott Leibrand
@scottleibrand
Mar 19 2015 04:08
yeah, but that's not the problem here
this data does have the iso8601 time
but it's calculating epoch incorrectly
Ben West
@bewest
Mar 19 2015 04:08
not quit
the pump has no zone info
Scott Leibrand
@scottleibrand
Mar 19 2015 04:08
well, it is guessing at the iso8601 timezone incorrectly
which makes it calculate epoch time wrong
Ben West
@bewest
Mar 19 2015 04:09
it's like your car
Scott Leibrand
@scottleibrand
Mar 19 2015 04:09
yeah, so anyway, the workaround was to use the timezone of the uploader Pi
or allow manual --timezone
and then append that to the timezone-less time from the pump
which appears to be almost, but not quite, working
Matthias Granberry
@mgranberry
Mar 19 2015 04:10
the problem with epochs is that governments change timezones. The device (or things knowing about the device) should include what they thought the timezone was, becuase these things can and do change.
Ben West
@bewest
Mar 19 2015 04:10
right, that's whats happening I believe
the pump gives us this info as separated, individual fields: year, month, day, hour, month, seconds
Scott Leibrand
@scottleibrand
Mar 19 2015 04:11
so anyway, can you make it interpret pump time as -0700 when I do --timezone PDT?
that's what you originally proposed (and I thought you had working)
per bewest/decoding-carelink#63
Ben West
@bewest
Mar 19 2015 04:12
did you try TZ=PDT mm-latest.py ...?
Scott Leibrand
@scottleibrand
Mar 19 2015 04:13
ya
Ben West
@bewest
Mar 19 2015 04:13
this does the same thing as js's version of isoformat
which is to isoformat into utc
this seems highly desirable
Scott Leibrand
@scottleibrand
Mar 19 2015 04:14
the problem is not the output being in UTC, it's that you're interpreting the pump time as being in UTC
so unless I make dana set her pump to UTC, it will be wrong
Ben West
@bewest
Mar 19 2015 04:15
the code is claiming to swap the date's zone info with the one you provide: https://github.com/bewest/decoding-carelink/pull/59/files#diff-978b2c15394117318fdfa472a1995ecdR137
Scott Leibrand
@scottleibrand
Mar 19 2015 04:16
does it honor --timezone for you?
anything I should run to debug why it's not for me?
a python command to make sure the date libraries aren't screwed up or something?
Ben West
@bewest
Mar 19 2015 04:18
I'm still confused
Scott Leibrand
@scottleibrand
Mar 19 2015 04:18
want to talk voice?
Ben West
@bewest
Mar 19 2015 04:18
hmm, I should run to dinner probably
Scott Leibrand
@scottleibrand
Mar 19 2015 04:19
heh
Ben West
@bewest
Mar 19 2015 04:19
going to run to dinner, starving, sorry
Scott Leibrand
@scottleibrand
Mar 19 2015 04:19
This message was deleted
Ben West
@bewest
Mar 19 2015 04:19
didn't realize so late
Scott Leibrand
@scottleibrand
Mar 19 2015 04:20
ok, I'll revert to the other branch and change the pump back to PST
Ben West
@bewest
Mar 19 2015 04:20
the isoformat function tends to force people into representation in UTC
eg, in js new Date( ) is in your locale
but same deal (new Date( )).toISOString( ) is in zulu
Scott Leibrand
@scottleibrand
Mar 19 2015 04:21
that's fine for output. we need to figure out a way to make it treat the input from the pump as PDT
Ben West
@bewest
Mar 19 2015 04:21
I believe that's what the replace does
Scott Leibrand
@scottleibrand
Mar 19 2015 04:21
so we just need to debug and see why it's not working
Ben West
@bewest
Mar 19 2015 04:21
replaces a date's zone info with new zone info
Scott Leibrand
@scottleibrand
Mar 19 2015 04:21
but, dinner first
Ben West
@bewest
Mar 19 2015 04:21
:+1: