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

6th
Sep 2015
Oliver Schumacher
@oschumac
Sep 06 2015 11:31
@jasoncalabrese. Hi Jason question i use a standart Nightscout side to Monitor OpenAPS. Just using Treatments which got send by the OpenAPS prozess. My Prob is that after sendeing ca. 500 Treatments within 48 hours The side stop to show them. Any Idea for a solution or workaround ?
Jason Calabrese
@jasoncalabrese
Sep 06 2015 15:03
ca. ?
Trying to see past the 2 days?
Oliver Schumacher
@oschumac
Sep 06 2015 15:27
sorry ca. is Germany means allmost.
Yes but sending every 5 min. gives 576 treatmens. Looks alike the node does not like that many treatment entries.
Jason Calabrese
@jasoncalabrese
Sep 06 2015 16:09
node or the browser
one thing that could be making it do more work is treatment are put on the timeline based on the BGs around that time
so if a treatment doesn't have the glucose and units fields it has to scan the current BGs to see what the avg is at that time
with that many treatments it would be a lot of work
try setting those even at a static level
Oliver Schumacher
@oschumac
Sep 06 2015 18:58
I use somthing like that:
{ enterdBy: 'OpenAPS Controller',
eventType: 'APS_TEMP',
glucose: 77,
glucoseType: 'fake',
insulin: 0.55,
notes: 'BZ: 331, eventualBG: 287 TBR Zeit : 30 TBR Rate U/min: 0.55 Prog Rate: 0.55 IOB: 0.27 reason: -3 und 287',
units: 'mg/dl',
created_at: '2015-09-06T20:52:51.969107' }
Jason Calabrese
@jasoncalabrese
Sep 06 2015 19:08
that should avoid the issue I was thinking of
Ali Mazaheri
@amazaheri
Sep 06 2015 19:11
@jasoncalabrese I think this is similalr to what we discussed earlier with 0.80
Jason Calabrese
@jasoncalabrese
Sep 06 2015 19:17
could be
can I look at a site that shows this?
Scott Leibrand
@scottleibrand
Sep 06 2015 22:50
@amazaheri @esteward and anyone else using openaps-js: I'm pushing that update that we discussed that puts openaps-js into "safe mode" and defaults max_iob to 0 if you don't create a max_iob.json and reference it at the end of your get-profile arguments. so if you want your openaps to high-temp and administer more insulin than the pump would if you're running high, you'll need to create a max_iob.json that looks something like: { "max_iob": 1 } and update your openaps.ini to reference it when running get-profile.
@esteward I also updated loop.sh to write out the reason to easy.log every run even (and especially) if no action is required, so we can tell why
Pete Schwamb
@ps2
Sep 06 2015 22:59
Anyone know if firmware 2.7A 1.1 0B 0B would appear to be custom firmware?
My 523 is 2.4A 1.1 0B 0B, and it’s not special, so I’d think if they used a particular scheme for denoting custom firmwares, something else would be different than the major/minor.
Ben West
@bewest
Sep 06 2015 23:03
I think the timing of the exploits were such that they actually changed firmware of 523 early on
in fact it appears european units retain sensitivity to the interesting commands
I haven't been able to map out correlation between version numbers
Scott Leibrand
@scottleibrand
Sep 06 2015 23:43
@loudnate how hard would it be to use openaps-mmhistorytools to parse pumphistory.json and prepare a json formatted for upload to nightscout? or would that be better as a separate tool?
or @oschumac perhaps you have something that does that? feels like I'd be reinventing the wheel if I write my own...
I think it'd be better to upload them to entries rather than treatments, but otherwise what you pasted above looks promising...
or maybe you're uploading enactedtemp.json rather than pumphistory.json
Nathan Racklyeft
@loudnate
Sep 06 2015 23:45
What's the formatting required for nighscout? Historytools has a very straightforward format after parsing
Scott Leibrand
@scottleibrand
Sep 06 2015 23:46
just need to add a couple keys to the json. let me scroll back and find them.
my main concern is stuff that truncates at "now"
Nathan Racklyeft
@loudnate
Sep 06 2015 23:46
From a design perspective, though, I would consider storing "as raw as possible" data
Scott Leibrand
@scottleibrand
Sep 06 2015 23:46
yeah, I'm not sure the normalized data is suitable for upload to nightscout
Nathan Racklyeft
@loudnate
Sep 06 2015 23:46
Then munging only when analyzing or displaying
Scott Leibrand
@scottleibrand
Sep 06 2015 23:47
yeah
Nathan Racklyeft
@loudnate
Sep 06 2015 23:47
Not sure I follow about truncated to now?
Scott Leibrand
@scottleibrand
Sep 06 2015 23:48
if you say "there was a 16 minute temp basal" that is truncated to 16m because it extends into the future...
Ben West
@bewest
Sep 06 2015 23:48
FWIW original NS supported treatments entries that were munged from pump, might be nice to use that
Scott Leibrand
@scottleibrand
Sep 06 2015 23:48
then uploading that as a 16m temp is incorrect: it's actually a 30m temp that hasn't ended yet
@bewest
any record with a type and a date is valid in NS api
but also needs a property with the name of the value of type
and it also needs an iso date string
those are the four rules
Nathan Racklyeft
@loudnate
Sep 06 2015 23:48
It doesn't do that,
Scott Leibrand
@scottleibrand
Sep 06 2015 23:48
oh ok
only for pump supends?
we wouldn't want to upload the artificial resume record
Nathan Racklyeft
@loudnate
Sep 06 2015 23:49
Suspends can be configured to assumed to begin and end at provided dates, but that's optional
Scott Leibrand
@scottleibrand
Sep 06 2015 23:49
but once we have a real resume record we might want to upload that as a temp basal to zero for that timeframe
Nathan Racklyeft
@loudnate
Sep 06 2015 23:50
So it sounds like that's heavily dependent on the use case.
Better to upload raw data to NS... "Suspended at"
Scott Leibrand
@scottleibrand
Sep 06 2015 23:50
so sounds like this is a separate tool from what mm-historytools does
Nathan Racklyeft
@loudnate
Sep 06 2015 23:51
Then your UI can decide what to do with it
Scott Leibrand
@scottleibrand
Sep 06 2015 23:51
@bewest the iso date string nightscout needs has to have a timezone, right?
i.e. the one timezoneless openaps provides from the pump won't work
Nathan Racklyeft
@loudnate
Sep 06 2015 23:52
Not sure I follow your use case, but I would encourage you to use historytools as an example of what issues and edge cases exist in pump history.
The test cases document each one.
But I wouldn't recommend sending data that's munged beyond removing erroneous data (like the carb dupes) because you don't want to limit your options at collection
Re-implementing the munging you need server-side
Scott Leibrand
@scottleibrand
Sep 06 2015 23:54
I think I basically already had that in wip/iob-cob: https://gist.github.com/scottleibrand/b15de1d1e7807023010a#file-iob-cob-diff-L352
Nathan Racklyeft
@loudnate
Sep 06 2015 23:55
NS is in node, I believe? So copy the fixtures/expected data and use that to aid your dev.
Scott Leibrand
@scottleibrand
Sep 06 2015 23:55
for temp basal events only. I didn't handle pump suspend events
Nathan Racklyeft
@loudnate
Sep 06 2015 23:55
The best way to know would be to add test cases :)
Ben West
@bewest
Sep 06 2015 23:56
the iso time string needs to be a valid iso timestring
the mm-latest.py shows how to add the timezone correctly assuming the pi has correct timezone
also allows passing flag to force different timezone
might be nice to have an isorator munging tool
Scott Leibrand
@scottleibrand
Sep 06 2015 23:57
this feels like something I should try to recruit someone else for who's more motivated to "do it right"
I just want it to work
Nathan Racklyeft
@loudnate
Sep 06 2015 23:58
@scottleibrand you'll also need to consider temp basals that cross basal rate boundary lines
Ben West
@bewest
Sep 06 2015 23:58
legacy: http://bl.ocks.org/bewest/c209e405f1e9fd7ecbec requires CR (carb-ratio), carbs, and insulin
but requires munging in order to get those into single record
was thinking about writing a basal schedule calculator/normalizer service somewhere on web