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

Jan 2019
Jan 19 00:19
How stable does 0.7.0 appear to be?
I am concerned by the stability of my current rig. I need to do a pull request on xDripAPS as it just doesn't work properly
and additionally I get a lot of preflight failures, clock mismatching, and additionally fairly consistent problems when I am in certain environments (a client's office i am working in this week is a perfect example, where very consistently the loop fails with warning currenttemp != existing temp error messages
Scott Leibrand
Jan 19 00:32
Oref0 itself is pretty stable. I can’t comment on xdripaps.
Jan 19 00:37
I think an effort needs to be made (probably by myself) to figure out what is causing the issues I am seeing. I just don't know where to begin. Probably at the source code and work from there tbh
i presume there is no way to enable tracing, or extra debug output
Scott Leibrand
Jan 19 02:12
There is actually. But first step is probably to look at all the log files, and the glucose.json and other output files.
Juan Mejías
Jan 19 09:33
Hi all, a few months after I had to give up looping (I had a very old 722 which ended up coming apart), I have a new pump and am looking forward to trying again. I've started setting up the rig, but I seem to be finding some issues. I've first tried re-running the setup script, but after answering all the questions, the loop doesn't get started. Instead, I get this message:
I don't know if it's related, but I also seem to be having radio issues. From time to time I get a message that the system will reset itself due to radio problems, and after a few minutes it shuts down and restart itself
I ran an mmtune and all I got were -99s
Jan 19 12:19
@juanjuanmejias_twitter the message you have a screenshot of can be translated as "I don't have a working network connection"
Juan Mejías
Jan 19 12:37
Yes @viq, thanks! I saw that it was a problem with wpa_supplicant.conf. I fixed that and it connected to wi fi. It worked for a while, but some reason now the wi fi connection is gone again, and it hasn't connected back since then. I don't know why that would happen, the Wi Fi network works fine and as far as I know the signal here is pretty stable (at least my laptop doesn't ever lose connection).
Any ideas what the problem could be?
Jan 19 13:02
Anyone tried using the IOS shortcuts to send treatments to NS? I just prototyped it by using a URL action with the advanced Get Contents of URL action and created a carb announcement script. It works great. Next, I'll integrate it with Siri.
Juan Mejías
Jan 19 16:33
I rebooted and it seems to have fixed the wifi problem for now
Juan Mejías
Jan 19 16:42
Also the radio seems to be working. I hope it all holds!
Scott Leibrand
Jan 19 18:07
@efidoman yes, that is now our main way to enter carbs and temp targets.
John Sjolund
Jan 19 18:32

So I continue to b e stuck in some type of strange Loop.

After ensuring ring everything I can imagine is up to date, on dev branch - I can see that it successfully loops a few times. Then the rig gets stuck in not being able to refresh refresh_pumphistory_and_meal

Continuing oref0-pump-loop at Sat Jan 19 10:24:53 PST 2019
Preflight fail. Retry 1 of preflight
Preflight OK. Profile less than 60m old; Profile valid. Pump history updated through 2019-01-19T09:33:00-08:00 with 3 new records; meal.json refreshed: {"carbs":55,"nsCarbs":55,"bwCarbs":0,"journalCarbs":0,"mealCOB":36,"currentDeviation":1.26,"maxDeviation":6.42,"minDeviation":3.46,"slopeFromMaxDeviation":-1.486,"slopeFromMinDeviation":0,"allDeviations":[1,4,3,6,6],"lastCarbTime":1547917987528,"bwFound":false}
Listening for 1s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:25:26 PST 2019
Checking that pump clock: "2019-01-19T10:25:27-08:00" is within 90s of current time: 2019-01-19T10:25:28-0800
Temp refreshed: monitor/temp_basal.json: {"duration":0,"temp":"absolute","rate":3.25}
Autotune exists! Hoorah! You can use microbolus-related features.
Autosens ratio: 0.72; Adjusting basal from 1 to 0.75; target_bg from 94 to 107; ISF from 44.6 to 62; CR: 5.326
currenttemp: { duration: 0, temp: 'absolute', rate: 3.25 } lastTempAge: 59 m tempModulus: 29 m
SMB enabled for COB of 36
Last carbs 73 minutes ago; remainingCATime: 6 hours; 35% carbs absorbed
Carb Impact: 12.9 mg/dL per 5m; CI Duration: 5.4 hours; remaining CI (~2h peak): 0 mg/dL per 5m
predCIs (mg/dL/5m): 13 13 12 12 12 12 12 11 11 11 11 11 10 10 10 10 10 9 9 9 9 9 8 8 8 8 8 7 7 7 7 7 6 6 6 6 6 5 5 5 5 5 4 4 4 4 4 3
remainingCIs:       0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
UAM Impact: 12.9 mg/dL per 5m; UAM Duration: 0.8 hours
minPredBG: 236 minIOBPredBG: 39 minZTGuardBG: 36 minCOBPredBG: 238 minUAMPredBG: 39 avgPredBG: 236 COB: 36 / 55
BG projected to remain above 5.9 for 240 minutes
naive_eventualBG: -31 bgUndershoot: 104.5 zeroTempDuration: 240 zeroTempEffect: 254 carbsReq: -35
profile.maxSMBBasalMinutes: 30 profile.current_basal: 1.024
naive_eventualBG -31, 60m 0U/h temp needed; last bolus 52.6m ago; maxBolus: 0.5
Checking deliverAt: 2019-01-19T18:25:38.493Z is within 1m of current time: Sat Jan 19 10:25:38 PST 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":205,"tick":"+2","eventualBG":349,"insulinReq":2.08,"reservoir":"121.8\n","deliverAt":"2019-01-19T18:25:38.493Z","sensitivityRatio":0.72,"COB":36,"IOB":3.805,"units":0.5,"rate":0,"duration":60}
"COB: 36, Dev: 4.3, BGI: -0.6, ISF: 3.4, CR: 5.33, Target: 5.9, minPredBG 13.1, minGuardBG 7.8, IOBpredBG 2.2, COBpredBG 19.4, UAMpredBG 2.2; Eventual BG 19.4 >= 5.9,  insulinReq 2.08; maxBolus 0.5; setting 60m low temp of 0U/h. Microbolusing 0.5U. "
COB: [205,207,208,210,211,212,213,214,216,217,219,221,223,225,227,230,232,235,238,242,245,249,252,256,260,264,268,272,276,281,285,289,293,297,302,306,310,314,318,322,326,329,333,336,340,343,346,349]
UAM: [205,206,204,202,198,193,186,178,169,160,150,141,133,125,117,110,103,96,90,84,78,73,68,64,60,56,52,49,45,42,40,39]
IOB: [205,206,206,204,202,199,195,190,184,178,171,163,154,146,138,131,124,117,111,105,100,95,90,85,81,77,73,70,67,64,61,59,56,54,52,50,49,47,46,44,43,42,41,40,40,39]
ZT:  [205,194,183,172,161,151,141,131,122,113,104,96,89
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening for 14s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:30:19 PST 2019
Preflight OK. Profile less than 60m old; Profile valid. Couldn't invoke_pumphistory_etc - continuing
Retry 1 of refresh_pumphistory_and_meal
Listening for 3s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:31:16 PST 2019
Retry 2 of refresh_pumphistory_and_meal
Pump history update failed. Last record 2019-01-19T10:25:42-08:00
Couldn't invoke_pumphistory_etc - continuing
Listening for 14s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:31:47 PST 2019
Retry 3 of refresh_pumphistory_and_meal
Couldn't invoke_pumphistory_etc - continuing
Couldn't refresh_pumphistory_and_meal
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 20 s silence before mmtuning
Listening for 20s: ...No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:32:58 PST 2019
Listening for 20 s silence before mmtuning: Listening for 20s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat Jan 19 10:33:00 PST 2019
Get's stuck here and will not restart successfully
Scott Leibrand
Jan 19 19:13
It’s successfully talking to the loop for short commands, but not able to do the full pumphistory pull. Does mmtune ever report a RSSI?
Martin Haeberli
Jan 19 20:10
rig mmtunes consistently fail - occasional radio errors. rebooted 14 minutes ago. no mmtune attempts even since. trying to figure out why. about to kill oref0 etc then try mmtune by hand. suggestions welcome
oops but maybe service cron stop kills remote access via BT ? or wifi...
basically, as soon as i ‘service cron stop’ the reverse tunnel collapses and the rig seems to die
Martin Haeberli
Jan 19 21:43
debug log:
OREF0_DEBUG=1 oref0-mmtune
mmtune: 2019/01/19 13:36:56 connected to CC111x radio on /dev/spidev5.1
2019/01/19 13:36:56 setting frequency to 916.650
2019/01/19 13:36:58 waking pump
8 minutes later, no further progress. what might be broken?
(edison / explorer rig)
Jan 19 21:45
Hi, I have a problem with mmtune since today, it constantly fails, when I've tried to run it manually, it shows -128 on every frequency. My enire rig is also much hotter than usual. Do you know, what could have happend and how to fix it?
Martin Haeberli
Jan 19 21:45
@lukaszarczynski - I have no suggestions, but am having distantly similar problems ...
Jan 19 21:49
@mhaeberli Have you tried Go-mmtune?
Oh, you're using Edison, I have pi zero with explorer hat
Martin Haeberli
Jan 19 21:53
ok thx; Go-mmtune likely should also work for me because i’m running dev branch which I think uses go versions
Jan 19 22:22
Does anybody know how xDrip's cloud service works?
(i am currently updating xDripAPS to be more bulletproof than it currently is, and also to add in token based authentication support)
Jan 19 22:27
a double check would be good from the commuity
Scott Leibrand
Jan 19 22:32
AFAIK there is no xDrip cloud service. But it looks like you're actually referring to xDrip's Nightscout upload code?
Jan 19 22:46
yeah thats what i meant
Jan 19 22:51

Ok so heres the big issue with xDripAPS. Please can you validate my thinking @scottleibrand :

xDrip+ sends a header on the Nightscout upload call post request with name 'api-secret' as per

The xDripAPS code looks for a header called Secret-Api as per :

That is never going to exist from xDrip's call (perhaps it used to, but its been updated?)

That means, for every user wanting to use this, itll hit a http 500

and bomb out
Scott Leibrand
Jan 19 23:02
I don't see the string Secret-Api anywhere in
Beyond that, I can't really say: I've never used xDrip or xDripAPS myself, and am not familiar with the code. Perhaps someone else who's more familiar could comment, or you might want to try or if no one responds here.
Jan 19 23:12
Sorry @scottleibrand xDripAPS is looking for Secret_Api
which won't ever exist as far as I am aware
Raymond Richmond
Jan 19 23:21
Question about Bluetooth PAN functionality. When I was on the plane today without internet my Edison kept dropping its bt connection constantly. Thought I was having a hardware or IP stack issue but as soon as I landed and got network it stopped. Did I miss something in the offline setup? I'm going to be back country in a couple of months and need thi
This to work.
Jan 19 23:23
@renegadeandy it's API_SECRET (case isn't significant in HTTP headers), not SECRET_API
Jan 19 23:25
that line shows that it's exactly what xdrip sends
Jan 19 23:25
it sends api-secret, note the '-' not '_'
@ecc1 check again....
Jan 19 23:25
I'm sorry, it is API-SECRET (hyphen, not underline)
but it's obviously sending it, and the NS code relies on it
Jan 19 23:26
yes, its sending it
but you are missing my point, xDripAPS is expecting api_secret
which it wont ever receive :/

my current changelog for my pull request to xDripAPS is as follows:

1/Added checking for API_SECRET and won't start unless this, or API_SECRET_xDripAPS environment variable is set
2/Added support for second environment variable API_SECRET_xDripAPS to allow for compatibility to run xDripAPS when OpenAPS users are using token based authentication with their API_SECRET
3/Added error output when api-secret header isn't sent instead of just letting the program return a 500
4/Changed header from Api_Secret to api-secret as xDrip+ doesn't send Api_Secret anymore and therefore this update makes the loop work again when using the latest version of xDrip.

Look ok?