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

24th
Oct 2017
spaldings
@spaldings
Oct 24 2017 00:00

Now I am stumped. oref0-setup has failed twice with same message:

File "/usr/local/lib/python2.7/dist-packages/openaps/cli/init.py", line 78, in git_repo
self.repo = getattr(self, 'repo', Repo(os.getcwd( ), odbt=GitCmdObjectDB))
File "/usr/local/lib/python2.7/dist-packages/git/repo/base.py", line 167, in init
raise InvalidGitRepositoryError(epath)
git.exc.InvalidGitRepositoryError: /root/myopenaps
process://ns/nightscout/ns https://ellasaps.herokuapp.com 206a43073d2c3a49c85423e472f22b554cbc4e01
Traceback (most recent call last):
File "/usr/local/bin/openaps-import", line 89, in <module>
app( )
File "/usr/local/lib/python2.7/dist-packages/openaps/cli/init.py", line 52, in call
self.epilog( )
File "/usr/local/bin/openaps-import", line 50, in epilog
super(ImportToolApp, self).epilog( )
File "/usr/local/lib/python2.7/dist-packages/openaps/cli/init.py", line 75, in epilog
self.create_git_commit( )
File "/usr/local/lib/python2.7/dist-packages/openaps/cli/init.py", line 82, in create_git_commit
self.git_repo( )
File "/usr/local/lib/python2.7/dist-packages/openaps/cli/init.py", line 78, in git_repo
self.repo = getattr(self, 'repo', Repo(os.getcwd( ), odbt=GitCmdObjectDB))
File "/usr/local/lib/python2.7/dist-packages/git/repo/base.py", line 167, in init
raise InvalidGitRepositoryError(epath)
git.exc.InvalidGitRepositoryError: /root/myopenaps
Could not run nightscout autoconfigure-device-crud

Any thoughts?

spaldings
@spaldings
Oct 24 2017 00:28
Decided to reflash the rig and went to download Jubilinux from link in OpenAPS Docs. Getting 403 Forbidden error and cannot download from Debian site directly. Had someone else check and same error. Getting a copy of Jubilinux from a friend but wanted others to be aware.
nicked22
@nicked22
Oct 24 2017 00:40
In nightscout, what is carbs activity/ absorption rate [g/hour]?
Scott Leibrand
@scottleibrand
Oct 24 2017 00:47
that's only used for populating the COB pill if your OpenAPS rig is not uploading COB.
LilDucky
@LilDucky
Oct 24 2017 01:05
basic tuning question - pump supports ISF and CR profiles across the day. Am I correct to assume that oref0/1 will use these? and is there any way toy autotune these?
Travis Cannell
@diabeticpilot
Oct 24 2017 01:28
I'm poking around on my rig with the latest dev release. I use Xdrip+ and I see that in my myopenaps/xdrip folder glucose.json and last-glucose.json are both current. In NS the OpenAPS pill is correct and it is looping with current data. However my myopenaps/cgm/ns-glucose.json stopped updating after I switched over to Dev. How is that updated? I think that could be why my NS has no BG data
Dave Acklam
@dcacklam
Oct 24 2017 02:09
@spaldings The working link for jubilinux is http://www.jubilinux.org/dist/jubilinux-v0.2.0.zip
spaldings
@spaldings
Oct 24 2017 02:12
thanks @dcacklam - did you get that from the docs link?
Scott Leibrand
@scottleibrand
Oct 24 2017 02:29
@LilDucky multiple CR or ISF schedules are not supported, and should not be used with autotune
until we add multiple CR support, you should set a single average CR in your pump and have autotune adjust that
@dcacklam @spaldings do the docs link to http://www.jubilinux.org/dist/ ? If so, that's what the download link on the main http://www.jubilinux.org/ links to as well, so most likely @esialb needs to fix the problem there and allow directory listings of http://www.jubilinux.org/dist/
Scott Leibrand
@scottleibrand
Oct 24 2017 02:35
@diabeticpilot most likely someone needs to update oref0-setup to do whatever special thing xDripAPS requires there, or add a special case making the xdrip config use the old openaps ns-loop like we did for MDT CGM
LilDucky
@LilDucky
Oct 24 2017 02:38
@scottleibrand thanks. was not 100% sure if that was the case. Are there any plans / ideas how to support it?
spaldings
@spaldings
Oct 24 2017 03:04
@scottleibrand yes docs link to http://www.jubilinux.org/dist/ . @dcacklam link worked to access file and download.
Travis Cannell
@diabeticpilot
Oct 24 2017 03:05
hmm @scottleibrand is there somewhere I could add that documentation as an issue with dev for xDripAPS users? Also I'll try having XDrip+ just upload directly to NS and then see if the rig can pull in BG values from NS to use. I have all the BG data going via LAN or PAN (with BT) from XDrip+ to the rig but it doesn't have to work that way
Scott Leibrand
@scottleibrand
Oct 24 2017 03:32
@diabeticpilot yes, please open an issue, unless you want to try your hand at actually fixing it and submitting a PR. I'm happy to help if it's not perfect the first time. Easiest place to start is probably the oref0-setup section that adds the (oref0-)pump-loop line to crontab, and copy what's done there for MDT.
@LilDucky I think CR autotuning will be pretty straightforward once we get the bandwidth to sit down and do it. we just need to read the CR schedule and have autotune apply CR adjustments for each meal (stacked series of carbs) to the schedule covering the first carb entry of the meal.
ISF schedules would be a lot harder, given the amount of data we have to work with, and a lot less necessary, given that ISF is only used for determining how aggressive corrections should be, and given that most people's BG doesn't get all that high once they're looping.
@spaldings thanks. I suspect @esialb will have it fixed before long, but if he doesn't see this conversation (maybe by tomorrow), you or @dcacklam could do a PR to the docs to temporarily change the link until he does.
LilDucky
@LilDucky
Oct 24 2017 03:38
@scottleibrand thanks. Interested in your thoughts of ISF vs BG skewing. I seem to be observing a drop in sensitivity with higher BGs. Have you seen this? A couple of people I have spoken to have suspected that this phenomenon exists. could be quite simple to implement.
nicked22
@nicked22
Oct 24 2017 03:49
Is there someone that could help me with the setup for autotune? I'm in the terminal right now trying to code in the insulin sensitivities and carb ratios, but I'm not sure how to put multiple ones in for different times.
LilDucky
@LilDucky
Oct 24 2017 04:00
@scottleibrand is this also related to issue 708?
Scott Leibrand
@scottleibrand
Oct 24 2017 05:29
@LilDucky is what related to openaps/oref0#708 ?
many PWDs have noticed that higher BGs correlate to lower sensitivity, and often attribute the causation to the BGs -> sensitivity direction. However, all the HCPs we've discussed this with think the causation actually runs in the other direction, ie. the lower sensitivity is what causes the higher BGs. in fact, all else being equal, insulin is actually more effective at higher glucose concentrations. so given all that, I prefer to focus on detecting sensitivity changes as directly as possible (with autosens) and adjusting oref0's actions accordingly. for high BGs, rather than assume a lower sensitivity in order to be more aggressive, we now use the ZTpredBGs to determine how aggressive to be, based on how much runway we have to prevent a low BG by zero-temping.
Scott Leibrand
@scottleibrand
Oct 24 2017 05:35
that way, if BG is high, and we can tell from the ZTpredBGs that even if deviations ceased we'd be able to flatten out at 150, then we know it's safe to give more insulin now via SMB with the expectation of being able to let the corresponding zero temp run if BGs actually start to drop as expected.
LilDucky
@LilDucky
Oct 24 2017 06:08
@scottleibrand sorry for not being clear - I am referring to the multiple ISF and CF entries in the pump, which issue 708 appears to reference in some json files.
@scottleibrand thanks for the explanation. It was just an idea that seemed to explain the prolonged highs that we are experiencing. Do you think that clearing out the multiple ISF and CR entries, then making sure that the files referred to in 708 are correct is a worthwhile process?
Scott Leibrand
@scottleibrand
Oct 24 2017 06:15
yes, I would recommend switching over to a single ISF and CR and clearing out the autotune pumpprofile etc. and making sure it's properly tuning and using the single values
LilDucky
@LilDucky
Oct 24 2017 06:18
Is it sensible to include the removal of these profiles in the prerequisites for looping to prevent future issues?
Scott Leibrand
@scottleibrand
Oct 24 2017 06:22
I think we can come up with a more automatic way to do that
also, no need to apologize for having ideas. I'm more than happy to keep sharing what I think about things with every new person who comes up with the same idea, as long as it means you'll keep thinking up new ones. :)
LilDucky
@LilDucky
Oct 24 2017 06:54
No problems Scott.
Marco
@CaptainBalou
Oct 24 2017 07:47
grafik.png
Strange behaviour since 2h. NightScout tells me there is a problem with OpenAPS
But I am looping and I see the rig is giving me SMB as expected. Also the CGM values and meals I enter in the pump are shown in NS. So ns-loop seems to work.
I have no chance to look into my rig at this point of time so just the question to you all: has someone an idea in which part the problem could rely on?
Diadon81
@Diadon81
Oct 24 2017 07:54
@CaptainBalou maybe you reach database limit. You should compact database.
Marco
@CaptainBalou
Oct 24 2017 07:55
Hello @Diadon81 . You mean mlab or OpenAPS rig? If one of both were full I wouldn't have anything working anymore, isn't it?
Diadon81
@Diadon81
Oct 24 2017 07:56
Mlab
Marco
@CaptainBalou
Oct 24 2017 07:57
But I see all new CGM values and new datasets I enter in the pump. Would you see a possibility I could push this into the mlab database without having space left? But nevertheless I will look into it! Thanks for the hint.
There is detailed explanation for your problem.
Marco
@CaptainBalou
Oct 24 2017 08:03
I will look into it now. The meeting I am in is boring anyway. ;-)
You are so right...you are so...right.
Marco
@CaptainBalou
Oct 24 2017 08:14
I have this:
grafik.png
But compacting doesn't change anything. While executing it returns "timeout" of the command but mentioned that it runs in background and I should not care.
But nothing changed here withing the last 5 minutes. I would assume compacting is something which should be done within 5 minutes even on shared systems, isn't it?
Diadon81
@Diadon81
Oct 24 2017 08:22
Write email to the support, last time, when I tried to compact my DB, I had same problem, only when I wrote a letter to the support team, they did it manually
Marco
@CaptainBalou
Oct 24 2017 08:24
Oh ok. Perfect. @Diadon81 is my hero of the day. I would never thought about searching in mLab troubleshooting sections for this. Thanks!
Diadon81
@Diadon81
Oct 24 2017 08:25
You are welcome my friend, we are in one boat)))
Paul Dickens
@thebookins
Oct 24 2017 09:04
I'm finding some inconsistency in how COB is calculated. In the logs below from a meal, mealCOB is incorrectly reported as 0 on three occasions, leading the predictions to jump around wildly.
Oct 24 00:30:10 shihab pump-loop.log: {"carbs":60,"mealCOB":60,"currentDeviation":-3.38,"maxDeviation":0.89,"minDeviation":-5.19,"slopeFromMaxDeviation":-0.5,"slopeFromMinDeviation":0.712,"allDeviations":[-3,-5,-5,-5,-4,-3,-1,1,1],"lastCarbTime":1508829510000}
Oct 24 00:35:25 shihab pump-loop.log: {"carbs":60,"mealCOB":59,"currentDeviation":-0.8,"maxDeviation":0.79,"minDeviation":-5.19,"slopeFromMaxDeviation":-0.185,"slopeFromMinDeviation":1.222,"allDeviations":[-1,-3,-5,-5,-5,-4,-3,-1,1],"lastCarbTime":1508829510000}
Oct 24 00:42:52 shihab pump-loop.log:  {"carbs":82,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviation":-5.19,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":null,"allDeviations":[-1,-3,-5,-5,-5,-4,-3],"lastCarbTime":1508829510000}
Oct 24 00:46:22 shihab pump-loop.log: {"carbs":90,"mealCOB":86,"currentDeviation":9.92,"maxDeviation":0,"minDeviation":-5.19,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":2.614,"allDeviations":[10,-1,-3,-5,-5,-5,-4,-3],"lastCarbTime":1508830865000}
Oct 24 00:51:32 shihab pump-loop.log: {"carbs":90,"mealCOB":85,"currentDeviation":11.43,"maxDeviation":9.92,"minDeviation":-5.19,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":2.439,"allDeviations":[11,10,-1,-3,-5,-5,-5,-4],"lastCarbTime":1508830865000}
Oct 24 00:58:16 shihab pump-loop.log: {"carbs":112,"mealCOB":0,"currentDeviation":null,"maxDeviation":11.43,"minDeviation":-5.19,"slopeFromMaxDeviation":null,"slopeFromMinDeviation":null,"allDeviations":[11,10,-1,-3,-5,-5],"lastCarbTime":1508830865000}
Oct 24 01:05:12 shihab pump-loop.log: {"carbs":140,"mealCOB":119,"currentDeviation":36.84,"maxDeviation":29.01,"minDeviation":-4.89,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":4.885,"allDeviations":[37,29,11,10,-1,-3,-5],"lastCarbTime":1508831690000}
Oct 24 01:14:54 shihab pump-loop.log: {"carbs":140,"mealCOB":119,"currentDeviation":36.84,"maxDeviation":29.01,"minDeviation":-3.38,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":4.576,"allDeviations":[37,29,11,10,-1,-3],"lastCarbTime":1508831690000}
Oct 24 01:17:26 shihab pump-loop.log: {"carbs":140,"mealCOB":119,"currentDeviation":36.84,"maxDeviation":29.01,"minDeviation":-0.8,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":4.192,"allDeviations":[37,29,11,10,-1],"lastCarbTime":1508831690000}
Oct 24 01:21:09 shihab pump-loop.log: {"carbs":140,"mealCOB":111,"currentDeviation":29.19,"maxDeviation":38.68,"minDeviation":9.92,"slopeFromMaxDeviation":-3.476,"slopeFromMinDeviation":2.493,"allDeviations":[29,39,37,29,11,10],"lastCarbTime":1508831690000}
Oct 24 01:25:22 shihab pump-loop.log: {"carbs":140,"mealCOB":105,"currentDeviation":23.79,"maxDeviation":38.68,"minDeviation":9.92,"slopeFromMaxDeviation":-4.179,"slopeFromMinDeviation":1.62,"allDeviations":[24,28,29,39,37,29,11,10],"lastCarbTime":1508831690000}
Oct 24 01:32:21 shihab pump-loop.log: {"carbs":140,"mealCOB":105,"currentDeviation":23.79,"maxDeviation":38.68,"minDeviation":11.43,"slopeFromMaxDeviation":-2.992,"slopeFromMinDeviation":1.376,"allDeviations":[24,28,29,39,37,29,11],"lastCarbTime":1508831690000}
Oct 24 01:36:08 shihab pump-loop.log: {"carbs":0,"mealCOB":0,"currentDeviation":15.47,"maxDeviation":38.68,"minDeviation":20.27,"slopeFromMaxDeviation":-4.051,"slopeFromMinDeviation":0,"allDeviations":[15,20,24,28,29,39,37,29],"lastCarbTime":0}
Oct 24 01:41:31 shihab pump-loop.log: {"carbs":140,"mealCOB":101,"currentDeviation":9.52,"maxDeviation":38.68,"minDeviation":15.47,"slopeFromMaxDeviation":-4.28,"slopeFromMinDeviation":0,"allDeviations":[10,15,20,24,28,29,39,37,29],"lastCarbTime":1508831690000}
Oct 24 01:49:15 shihab pump-loop.log: {"carbs":140,"mealCOB":100,"currentDeviation":6.01,"maxDeviation":38.68,"minDeviation":9.52,"slopeFromMaxDeviation":-3.913,"slopeFromMinDeviation":0,"allDeviations":[6,10,15,20,24,28,29,39],"lastCarbTime":1508831690000}
One of those occasions is associated with the error Warning: setting mealCOB to 0 because currentDeviation is null/undefined, but the other two don't seem to be caused by this. Has anyone seen this before? Should I raise an issue?
BTW, running dev, updated a few days ago.
cameronrenwick
@cameronrenwick
Oct 24 2017 11:10
@CaptainBalou I'll bet it's a a disk full situation as well. The docs provide instructions for how to push your data to open humans and then delete data. I've just done this a while back myself. I'd suggest once you've donated, and assuming your endo doesn't need your data/you don't have to show it, delete up to your most recent month. That'll free up a lot of space and you should have all NS pills showing properly
Marco
@CaptainBalou
Oct 24 2017 11:33
@cameronrenwick I will do so. Would be good to have a maintenance tool of OpenAPS to maintain that without the need to know what influences what. But let's dream on... :-)
cameronrenwick
@cameronrenwick
Oct 24 2017 11:38
@CaptainBalou I have decided that every other month I'm going to donate my oldest 2 months of data to open humans and then delete that from my database collection. In this way I've got space and the most current data is available.
Marco
@CaptainBalou
Oct 24 2017 12:10
@cameronrenwick Yes this is a good way. But you have to manually do that by loggin in and doing some "erase older than" magic. A maintenance tool would be easier for some with less knowledge here. But sure, someone with knowledge has to write it...I know. :-/
Glenn Primack
@primags
Oct 24 2017 12:16
@PieterGit Just saw your note about the BT and WIFI being built in on the Edison board. I wasn't aware of that, but it makes sense now why my rig could talk wifi and BT, but couldn't talk to the pump if I damaged the explorer board.
@PieterGit Also, I tried cutting the antenna to get better range, which could've also caused issues communicating with pump,but turned out that my pump battery was just getting low but it wasn't displaying it on the pump itself...I setup an alarm for pump voltage now...
Glenn Primack
@primags
Oct 24 2017 14:15
What has everyone done about their Endocrinologist and OpenAPS? Do you tell them so you can get supplies covered? I'm going for my appt. soon and want to know how others have handled it. I would suspect it would make some uneasy, though mine has Type 1 so may be OK.
ejoe132
@ejoe132
Oct 24 2017 14:17
@primags Mine loved it, everytime I go in,(also meet with an educator every 2 months) they bring more of their doctors or nurses in to see it and look at my nightscout, as soon as she say the improvement in my a1c she is in love with me on openaps
kallnap
@kallnap
Oct 24 2017 14:21
@primags the supplies are not so much different from sensor supported therapy and pump perscription, therefore, I do not see issues there. For Endos I would like to quote Dana YE(ndo)MV. Some that are supportive and even using this themselves and there seem to be others. On the other hand what can he do? Worst case is you go to a more open minded doctor .
Dana Lewis
@danamlewis
Oct 24 2017 14:24
:smile:
cameronrenwick
@cameronrenwick
Oct 24 2017 14:32
@primags my endo was all good with looping and openaps but his question was "oh, but what happens if this gizmo stops working??" with a smile on my face I said, well, if my rig stops working I'm back to exactly what you've prescribed... the pump. Framing it in this manner really hit home (for him and others) that what we're doing with openaps and our rigs is only bettering what we've all been prescribed. It's hard for a Dr or anyone for that matter to argue you shouldn't use openaps when you see A1C's steadily going down to non-T1D numbers. (This of course assumes you're doing all the openaps things safely etc etc)
Dana Lewis
@danamlewis
Oct 24 2017 14:33
+1 many people have brought the reference design in with them, or a short form of that, explaining the safety design, and that helps a lot. Also showing you know what you're doing and why.
^based on other people's experiences
cameronrenwick
@cameronrenwick
Oct 24 2017 14:39
biggest compliment I got at my last endo DNE visit was when the new RN asked the dietitian "how do we advise Cameron on his T1D?". The dietitian said "we don't advise him honestly, he's advising us".... ('nuff said!)
Dana Lewis
@danamlewis
Oct 24 2017 14:43
:smile:
Velibor Maric
@vebaba
Oct 24 2017 14:48
I'm wondering: How often you can/are allowed to see your endo? And how often you have to see your endo to keep benefits (pump, stripes etc.)?
Jacob H
@jdhigh
Oct 24 2017 14:50
@vebaba For most people, it depends on their insurance coverage. If you can afford to have more frequent visits, then it would depend on your perceived need. For prescription benefits, some people get 1 month supply coverage, others get as much as 3 month. (I used to get 3 month, now I get 2.) I typically get 3 refills before the Endo has to write a new Px.
Dana Lewis
@danamlewis
Oct 24 2017 14:53
Depends on a lot things. sometimes insurance when being colossal idiots require "fresh" chart notes from an in person visit <6 months ago to evaluate coverage for a CGM. Depends on which insurance, depends on devices and scripts, depends on if they're being silly, etc.
Velibor Maric
@vebaba
Oct 24 2017 14:55
But every T1D can have pump?
Jacob H
@jdhigh
Oct 24 2017 14:56
Not always. Sometimes there's a "medically necessary" evaluation.
I've known of T1Ds who were recently diagnosed and they couldn't get a pump because "insert reason something something too recently diagnosed."
Velibor Maric
@vebaba
Oct 24 2017 14:57
@jdhigh Oh, that's bad. But, basically if you pay more for insurance, you'll get covered... How much is that, if that's not too personal question...
cameronrenwick
@cameronrenwick
Oct 24 2017 14:58
come to Ontario Canada, you can get a pump provided by our provincial healthcare plan every 5 years, plus $600 every 3 months for supplies... (ok, I'll get off my socialist healthcare soapbox...)
Jacob H
@jdhigh
Oct 24 2017 14:58
Well, it depends on where you live and what insurance is available for you.
Dana Lewis
@danamlewis
Oct 24 2017 14:59
Insurance does not guarantee coverage for anything (pump or CGM). Increases the likelihood of it costing less than out of pocket, is all.
Jacob H
@jdhigh
Oct 24 2017 14:59
^
Dana Lewis
@danamlewis
Oct 24 2017 15:00
Someone (<---) is feeling a smidge cynical today.
cameronrenwick
@cameronrenwick
Oct 24 2017 15:03
I honestly feel that way with Ins co's EVERY day.... (but I'm kinda like that....)
Dana Lewis
@danamlewis
Oct 24 2017 15:03
Some of my latest cynicsm is fueled by this experience from last year, in case anyone outside of the US wants more insight into just how silly it can be sometimes: https://diyps.org/2016/07/07/let-me-count-the-ways-that-the-healthcare-system-is-broken/
Not always, but sometimes.
Velibor Maric
@vebaba
Oct 24 2017 15:07
Oh, well... I have to pay for everything but insulin. Northern Europe is best for medical coverage and ease of use
Jacob H
@jdhigh
Oct 24 2017 15:08
As a healthcare fraud lawyer, I can tell you that there is one thing that gets healthcare providers/insurance companies motivated more than no other: regulatory pressure. A call to your congressman or a letter to regulatory agencies can work wonders.
Velibor Maric
@vebaba
Oct 24 2017 15:08
The only way for to get pump and supplies is if my kidneys become to deteriorate.
James
@in-10-city
Oct 24 2017 15:10
note to self, don't change jobs working at a hospital that is state funded does have it's small perks
Scott Leibrand
@scottleibrand
Oct 24 2017 15:12
@thebookins the Warning one is expected behavior. I'd need to see the full pump-loop.log for the others.
Velibor Maric
@vebaba
Oct 24 2017 15:14
Thanks all for sharing info. Nowhere is excellent but there are different shades of good and bad ;)
Dana Lewis
@danamlewis
Oct 24 2017 15:15
:+1:
Diadon81
@Diadon81
Oct 24 2017 17:47
That maybe strange for everyone, but in Russia the pump, insulin and test strips are covered by social insurance (which you get by default as a tax payer) for children under 18 y.o. all pump supplies (instead of CGM) also for free. But anyway the price for pump supplies, sensors, insulin is much more cheaper (at least 10 times) than in USA
Dave Acklam
@dcacklam
Oct 24 2017 18:00
@Diadon81
Without side-tracking into US politics (eg, I will leave my personal opinion on the subject out of my post).... The breadth & cost of social insurance is one of the biggest issues in our federal elections, ever since the Democrats used their 2008 gains in Congress to expand it substantially (leading to a backlash & the 2010 reversal of those gains)...
On the previously-discussed subject of getting my 712 pump working, I've managed to do it (abeit in a slightly unsafe way)
The error is an array-out-of-bounds in decocare's commands.py
I put that in a try-except & had the 'except' block return 'normal', 'false', 'false'.
And now the 'old_main()' loop function works.
Dave Acklam
@dcacklam
Oct 24 2017 18:05
The 'unsafe' part, is that no matter what the pump is set to, monitor/status.json will always return normal/false/false. Which I am OK with for now since I'm the one wearing said pump...
Marco
@CaptainBalou
Oct 24 2017 18:06
@primags My doctor was interested a lot. Because I have no compatible pump myself he lent me one and said "you damn nerd 😜 Take the pump as long as you need it and tell me EVERYTHING after looping a while! 😊"
Dave Acklam
@dcacklam
Oct 24 2017 18:07
Obviously the desired-endstate would be to figure out what is wrong with the array & make it actually do it's job as-much-as-it-can...
@CaptainBalou
You are lucky on that one. My endo doesn't believe APS is workable, even in terms of the 670G - says 'they have been trying for years, and it's never worked'. Needless to say, I'm taking that with a grain of salt...

/root/src/decocare/decocare/commands.py
Original dev-branch code:
status = { 'status': normal.get(data[0], 'error'),
'bolusing': data[1] == 1,
'suspended': data[2] == 1
}

What I did:
try:
status = { 'status': normal.get(data[0], 'error'),
'bolusing': data[1] == 1,
'suspended': data[2] == 1
}
except:

  #hack to BS status, when the above returns byteindex out of range (712 pump)
  status = { 'status': 'normal',
             'bolusing': 'false',
             'suspended': 'false'
           }
Scott Leibrand
@scottleibrand
Oct 24 2017 18:12
what happens if you just do status = { 'status': 'unknown' } or something like that?
Dave Acklam
@dcacklam
Oct 24 2017 18:12
in the except:?
Scott Leibrand
@scottleibrand
Oct 24 2017 18:12
ya
Dave Acklam
@dcacklam
Oct 24 2017 18:13
It would write 'unknown' to the json file & the oref0-pump-loop would process that
Scott Leibrand
@scottleibrand
Oct 24 2017 18:13
yeah, just wondering what oref0-pump-loop would do with that. we might need to special-case something
might also be worth checking which of data[0] data[1] and data[2] are and aren't populated
Dave Acklam
@dcacklam
Oct 24 2017 18:14
Since this is an array-out-of-bounds, my thought would be that the non-hacky way to do it would be to put code that reads the array properly for the 712 in the except:
Scott Leibrand
@scottleibrand
Oct 24 2017 18:14
I seem to recall the 512 doesn't support either the bolusing and/or the suspended check
so would be better to just have those ones say unknown if they're not supported
Dave Acklam
@dcacklam
Oct 24 2017 18:15
That would make sense: If data[] is 0, 1, or 2 params instead of 3... index OOB
And yes, if we are talking changes to the code in the branch... unknown is better.
I only did this to make mine work
Scott Leibrand
@scottleibrand
Oct 24 2017 18:16
anyway, sounds like you're well qualified to try things and figure out what works best, which hopefully we can get committed to the repo to benefit everyone
Dave Acklam
@dcacklam
Oct 24 2017 18:16
I'll definately post back what I find.
Scott Leibrand
@scottleibrand
Oct 24 2017 18:16
sounds like you're pretty close to turning your hack into a more general solution for all 512s that's backwards compatible with other pumps
Dave Acklam
@dcacklam
Oct 24 2017 18:17
Another one:
The 'dev' oref0-pump-loop chokes on the 512 unless I use the 'old_main()' function
Scott Leibrand
@scottleibrand
Oct 24 2017 18:17
yeah, that doesn't surprise me. I wasn't thinking about 512 support when I switched that over
Dave Acklam
@dcacklam
Oct 24 2017 18:17
New main's enforcement of the 'No-SMB on 512/712' produces a hard-fail rather than a fallback-to-basal-only
Scott Leibrand
@scottleibrand
Oct 24 2017 18:18
what I'd like to do is use the new main() but just add appropriate error checking to let it continue/fallback after unsupported commands
ah, yeah, that needs fixed
feel free to take a crack at that, or open an issue for one of us to do it
Dave Acklam
@dcacklam
Oct 24 2017 18:18
Will do...
Now I have to get back to working on the stuff that pays the bills (I'm a sysadmin for one of the smaller tech firms in Seattle)...
Scott Leibrand
@scottleibrand
Oct 24 2017 18:19
thx for the help. great to have someone working on the 512 who's actually willing to help make things better for everyone. :)
you planning to come to the Seattle meetup in a couple weeks?
Dave Acklam
@dcacklam
Oct 24 2017 18:20
My coding skills beyond bash are... limited (I had to google try:/except: & how to format code blocks in python)... But I'll give back what I can...
scottleibrand @scottleibrand is just waiting for a big data processing job to finish @ work ;-)
Scott Leibrand
@scottleibrand
Oct 24 2017 18:20
@dcacklam that's exactly where I started: my pre-DIYPS scripting skills were just bash and perl. :)
Dave Acklam
@dcacklam
Oct 24 2017 18:22
Regrettably, I'm also preparing to leave the region for 5mo this June (my 'weekend employer' is sending me to Oklahoma for some training) & have to leave my wife/1yo son behind... So I can't really break away from the massive list of 'before I leave you guys' chores that have to get done...

On other notes, my edison board's wifi seems to be melting down (either that or it doesn't like my office)... And BT tether direct to the phone blocks xdrip from talking to my G5 (left my SmartWatch3 at home today)...

Fortunately, the typical setup I run (watch as collector) will solve that (because X won't be collecting via the phone, & BT tether doesn't mess with the connection between the watch and phone the way it does with the G5 sensor)

Paul Dickens
@thebookins
Oct 24 2017 20:47
@scottleibrand re mealCOB being reported as zero, here's pump-loop.log for one of those occasions, with the previous and subsequent cycles included. As you can see mealCOB goes from 105 to 0 to 101. Any ideas? Let me know if you need more context.
Martin Haeberli
@mhaeberli
Oct 24 2017 20:47
btw, current master is 0.5.5, I think? when is 0.6.0 expected ?
Paul Dickens
@thebookins
Oct 24 2017 20:49
Oct 24 01:32:21 shihab pump-loop.log:  Autotune exists! Hoorah! You can use microbolus-related features.
Oct 24 01:32:21 shihab pump-loop.log: {"carbs":140,"mealCOB":105,"currentDeviation":23.79,"maxDeviation":38.68,"minDeviation":11.43,"slopeFromMaxDeviation":-2.992,"slopeFromMinDeviation":1.376,"allDeviations":[24,28,29,39,37,29,11],"lastCarbTime":1508831690000}
Oct 24 01:32:21 shihab pump-loop.log:  BG data is too old (it's probably this), or clock set incorrectly.  The last BG data was read at Tue Oct 24 2017 19:21:55 GMT+1100 (AEDT) but your system time currently is Tue Oct 24 2017 19:32:21 GMT+1100 (AEDT)
Oct 24 01:32:21 shihab pump-loop.log:    "reason": "BG data is too old (it's probably this), or clock set incorrectly.  The last BG data was read at Tue Oct 24 2017 19:21:55 GMT+1100 (AEDT) but your system time currently is Tue Oct 24 2017 19:32:21 GMT+1100 (AEDT)"
Oct 24 01:32:21 shihab pump-loop.log:  Checking system clock against pump clock:
Oct 24 01:32:21 shihab pump-loop.log:  Checking deliverAt: null is within 1m of current time: Tue Oct 24 19:32:21 AEDT 2017
Oct 24 01:32:22 shihab pump-loop.log:  date: invalid date ‘null’
Oct 24 01:33:05 shihab pump-loop.log:  supermicrobolus pump-loop failed. Listening for 40s silence before mmtuning: .No interfering pump comms detected from other rigs (this is a good thing!)
Oct 24 01:33:27 shihab pump-loop.log:  mmtune: "916.660", 5, -84 waiting for 48 second silence before continuing
Oct 24 01:34:18 shihab pump-loop.log:  Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Oct 24 01:34:18 shihab pump-loop.log:  Done waiting for rigs with better signal.
Oct 24 01:34:18 shihab pump-loop.log:  Unsuccessful supermicrobolus pump-loop at Tue Oct 24 19:34:18 AEDT 2017
Oct 24 01:35:03 shihab pump-loop.log:  Starting supermicrobolus pump-loop at Tue Oct 24 19:35:02 AEDT 2017 with 6 second wait_for_silence:
Oct 24 01:35:03 shihab pump-loop.log:  Waiting up to 4 minutes for new BG: glucose.json newer than pump_loop_completed
Oct 24 01:35:13 shihab pump-loop.log:  Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Oct 24 01:35:50 shihab pump-loop.log:  Preflight OK. Profile less than 60m old. Refreshed pumphistory! and meal.json
Oct 24 01:35:54 shihab pump-loop.log:  Checking pump clock: "2017-10-24T19:35:52+11:00" is within 1m of current time: Tue Oct 24 19:35:53 AEDT 2017
Oct 24 01:36:04 shihab pump-loop.log:  and that pumphistory is less than 1m old.  Temp refreshed
Oct 24 01:36:08 shihab pump-loop.log:  Autotune exists! Hoorah! You can use microbolus-related features.
Oct 24 01:36:08 shihab pump-loop.log: {"carbs":0,"mealCOB":0,"currentDeviation":15.47,"maxDeviation":38.68,"minDeviation":20.27,"slopeFromMaxDeviation":-4.051,"slopeFromMinDeviation":0,"allDeviations":[15,20,24,28,29,39,37,29],"lastCarbTime":0}
Oct 24 01:36:08 shihab pump-loop.log:  {"iob":5.636,"activity":0.0416,"basaliob":-0.817,"bolusiob":6.453,"netbasalinsulin":-1.55,"bolusinsulin":10.8,"time":"2017-10-24T08:35:57.000Z","iobWithZeroTemp":{"iob":5.636,"activity":0.0416,"basaliob":-0.817,"bolusiob":6.453,"netbasalinsulin":-1.55,"bolusinsulin":10.8,"time":"2017-10-24T08:35:57.000Z"},"lastBolusTime":1508831690000,"lastTemp":{"rate":0,"timestamp":"2017-10-24T19:25:26+11:00","started_at":"2017-10-24T08:25:26.000Z","date":1508833526000,"duration":11.58}}
Oct 24 01:36:08 shihab pump-loop.log:  {"delta":-12,"glucose":113,"short_avgdelta":-8.67,"long_avgdelta":1.12}
Oct 24 01:36:08 shihab pump-loop.log:  Autosens ratio: 1; Basal unchanged: 1.1; ISF unchanged: 108
Oct 24 01:36:08 shihab pump-loop.log:  currenttemp: { duration: 21, rate: 0, temp: 'absolute' } lastTempAge: 11 m tempModulus: 2 m
Oct 24 01:36:08 shihab pump-loop.log:  Carb Impact: 10.5 mg/dL per 5m; CI Duration: NaN hours; remaining CI (~2h peak): NaN mg/dL per 5m
Oct 24 01:36:08 shihab pump-loop.log:  UAM Impact: 10.5 mg/dL per 5m; UAM Duration: 0.3 hours
Oct 24 01:36:08 shihab pump-loop.log:  minPredBG: -324 minIOBPredBG: 39 minZTGuardBG: -324 avgPredBG: -324 COB: 0 / 0
Oct 24 01:36:08 shihab pump-loop.log:  BG projected to remain above 117 for 0 minutes
Oct 24 01:36:08 shihab pump-loop.log:  BG projected to remain above 78.5 for 15 minutes
Oct 24 01:36:08 shihab pump-loop.log:  naive_eventualBG: -496 bgUndershoot: 574.5 zeroTempDuration: 15 zeroTempEffect: 30 carbsReq: 86
Oct 24 01:36:08 shihab pump-loop.log:  Checking deliverAt: 2017-10-24T08:36:08.491Z is within 1m of current time: Tue Oct 24 19:36:08 AEDT 2017
Oct 24 01:36:09 shihab pump-loop.log:  and that smb-suggested.json is less than 1m old
Oct 24 01:36:09 shihab pump-loop.log:  enact/smb-suggested.json: {"insulinReq":0,"bg":113,"reservoir":"155.3","temp":"absolute","carbsReq":86,"predBGs":{"ZT":[113,91,68,45,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39,39],"IOB":[113,100,86,71,56,39,39,39,39,39,39,39,39]},"IOB":5.636,"reason":"COB: 0, Dev: 63, BGI: -22.46, ISF: 6.0, Target: 6.5, minPredBG -18.0, minGuardBG -24.3, IOBpredBG 2.2; 86 add'l carbs req w/in 15m; minGuardBG -24.3<4.4 21m left and 0 ~ req 0U/hr: no temp required","COB":0,"eventualBG":-433,"tick":-12,"deliverAt":"2017-10-24T08:36:08.491Z"}
Oct 24 01:36:11 shihab pump-loop.log:  No smb_enact needed. Temp refreshed: monitor/temp_basal.json: {"duration":20,"rate":0,"temp":"absolute"}
Oct 24 01:36:26 shihab pump-loop.log:  No bolus needed (yet). Settings less than 15 minutes old. Edison on battery: 39%. pumphistory-24h refreshed
Oct 24 01:36:27 shihab pump-loop.log:  Completed supermicrobolus pump-loop at Tue Oct 24 19:36:26 AEDT 2017
Oct 24 01:37:03 shihab pump-loop.log:  Starting supermicrobolus pump-loop at Tue Oct 24 19:37:03 AEDT 2017 with 13 second wait_for_silence:
Oct 24 01:40:16 shihab pump-loop.log:  Waiting up to 4 minutes for new BG: ...................glucose.json newer than pump_loop_completed
Oct 24 01:40:34 shihab pump-loop.log:  Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Oct 24 01:41:19 shihab pump-loop.log:  Preflight OK. Profile less than 60m old. Refreshed pumphistory!!!!! and meal.json
Oct 24 01:41:21 shihab pump-loop.log:  Checking pump clock: "2017-10-24T19:41:20+11:00" is within 1m of current time: Tue Oct 24 19:41:21 AEDT 2017
Oct 24 01:41:28 shihab pump-loop.log:  and that pumphistory is less than 1m old.  Temp refreshed
Oct 24 01:41:31 shihab pump-loop.log:  Autotune exists! Hoorah! You can use microbolus-related features.
Oct 24 01:41:31 shihab pump-loop.log: {"carbs":140,"mealCOB":101,"currentDeviation":9.52,"maxDeviation":38.68,"minDeviation":15.47,"slopeFromMaxDeviation":-4.28,"slopeFromMinDeviation":0,"allDeviations":[10,15,20,24,28,29,39,37,29],"lastCarbTime":1508831690000}
nicked22
@nicked22
Oct 24 2017 21:27
How do I add multiple insulin sensitivity factors when I set up autotune?
Scott Leibrand
@scottleibrand
Oct 24 2017 21:28
You don't. You switch to using a single one and tuning that.
Dana Lewis
@danamlewis
Oct 24 2017 21:30
@mhaeberli no timeline
Scott Leibrand
@scottleibrand
Oct 24 2017 21:31
If you have solid physiologically plausible evidence that your ISF actually experiences real diurnal variation, I'd love to have a look, but so far everyone we've seen using multiple ISFs is compensating for something else, and it ends up working better to fix the other settings and stick with a single ISF (which can then be adjusted as needed by autosens and autotune).
We'll probably add CR schedule support to autotune at some point, but there usually isn't enough data to support tuning ISF differently for different times of day.
Martin Haeberli
@mhaeberli
Oct 24 2017 21:32
@danamlewis no worries … thx
Scott Leibrand
@scottleibrand
Oct 24 2017 21:33
And with a closed loop, ISF is really just an aggressiveness setting, so isn't all that important to tune precisely.
Scott Leibrand
@scottleibrand
Oct 24 2017 21:41
@thebookins where do your carbs come from? NS or pump? looks like your rig may have had connectivity issues and couldn't get BG. if carbs came from NS, that would also affect carb_history downloads.
Jacob H
@jdhigh
Oct 24 2017 22:17
I read the suggestion in the docs for "What do you do with the loop when you shower" (cancel basal, set temp basal 0, then suspend) to help oref1 more accurately calculate netIOB. QUESTION: Does the software know when your reservoir is empty, and begin calculating net IOB accordingly?
Dana Lewis
@danamlewis
Oct 24 2017 22:18
No
Because you can go past empty
Keeps going til you're truly empty aka no delivery alarms go off
Jacob H
@jdhigh
Oct 24 2017 22:19
Hmm... has there been a calculation of how much is delivered past 0.0? (Or an average over a large sample)?
(Depending on pump model, etc.)
Dana Lewis
@danamlewis
Oct 24 2017 22:20
Depends on if you 100% filled it and if there are any air bubbles at the bottom
But for me, ~8-10u is what I expect past 0. Keeping track of it is hard though because no record of exactly when you hit 0 if you're not paying attention to it
Jacob H
@jdhigh
Oct 24 2017 22:21
I suppose air bubbles would be hard to isolate as a variable here.
Dana Lewis
@danamlewis
Oct 24 2017 22:21
That's both based on scott pushing insulin out of 0 reservoirs and anecdotal experience. After 3-5u I expect a no delivery or assume the remainder have some air bubbles
Jacob H
@jdhigh
Oct 24 2017 22:22
Yeah. I like to get the last bit out of my reservoir, and unfortunately I forgot for about .5 hour today. Not a big deal, but I figured my BG would rise a little as a result. It did.
But when I replaced the reservoir, I then began to wonder if the software would compensate for the lost time. (And it didn't, hence my question.)
Scott Leibrand
@scottleibrand
Oct 24 2017 22:23
as you approach the end of the 10U buffer, you hit the angled end of the reservoir, and the pump starts giving less and less insulin relative to what it thinks it gave
there were about 2U "missing" by the time we hit a no delivery when we were testing, and that was without taking into account any air bubbles
now that said, OpenAPS doesn't use the reservoir readings to calculate IOB: it uses the temp basals and bolus records in the pumphistory. so up until about 5-8U past empty, IOB should be pretty accurate
Jacob H
@jdhigh
Oct 24 2017 22:25
Well, if there's always "about 2 units" missing, and the sample size is large enough, that could come into the software in the event of a prolonged period of 0.0 reservoir?
Scott Leibrand
@scottleibrand
Oct 24 2017 22:26
we're not going to compensate for people going 10U past an empty reservoir
Jacob H
@jdhigh
Oct 24 2017 22:26
Makes sense. I guess I'm just worrying a lot about a little.
Scott Leibrand
@scottleibrand
Oct 24 2017 22:26
just know if you actually hit a no delivery, you need to do something to compensate: set a low temp target, do a small bolus on the new reservoir, or whatever
Jacob H
@jdhigh
Oct 24 2017 22:29
Taking this a bit further then... Does OpenAPS have any way of picking up a no delivery warning coming from the pump?
Scott Leibrand
@scottleibrand
Oct 24 2017 22:53
I'm sure it shows up in NS
but I would focus on alarming on the empty reservoir instead of the no delivery
if you really want to save the last bit of insulin, you can refill a reservoir multiple times or transfer the last bit to the new one
Paul Dickens
@thebookins
Oct 24 2017 23:04
@scottleibrand the carbs are coming from the pump. There's a patchy internet connection, but should this affect carbs read from the pump?
Scott Leibrand
@scottleibrand
Oct 24 2017 23:47
theoretically it should not
although it's possible that an error downloading carbhistory from NS would cause it to ignore pump carbs until the next refresh, when it properly downloads the empty NS carbhistory (or the full copy of everything the rig has uploaded from the pump)