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

22nd
Jan 2019
Martin Haeberli
@mhaeberli
Jan 22 00:02
@cluckj - do you know what mechanism is used to enable during install ? Just that one-line command at some point?
renegadeandy
@renegadeandy
Jan 22 00:15

There is definitely something environmental with the office. As soon as I left, my rig started operating again perfectly.

My phone, and my rig, are not connected to the office wifi, there is no changes in physical location of my phone / rig / pump, all in the same 'near zone' to me

what on earth could cause that!
some other radio signal maybe?!
Jon Cluck
@cluckj
Jan 22 00:20
@mhaeberli it's probably part of bluez's make install
@renegadeandy I saw earlier it looked like you were using a WW pump? I had some pretty nasty interference and range issues using one in a north american city
renegadeandy
@renegadeandy
Jan 22 00:25
yeah its a WW pump, its a UK pump
and im now in a USA city

so im wondering if the office has something running which is causing bad interference, if this was the case, could we try to 'detect' that level of interfernce and highlight it to the user, instead of just failing?

I would be more than happy to try coding something if somebody could help me understand where and what to add.

i can test running it tomorrow during the day!
Martin Haeberli
@mhaeberli
Jan 22 00:37
@cluckj
systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
   Active: inactive (dead)
     Docs: man:bluetoothd(8)
on ‘broken’ device
even after systemctl enable bluetooth
Martin Haeberli
@mhaeberli
Jan 22 00:43
@cluckj - native, right after boot:
systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
   Active: failed (Result: exit-code) since Mon 2019-01-21 16:40:07 PST; 2min 35s ago
     Docs: man:bluetoothd(8)
  Process: 499 ExecStart=/usr/lib/bluetooth/bluetoothd (code=exited, status=1/FAILURE)
 Main PID: 499 (code=exited, status=1/FAILURE)
   Status: "Starting up"

Jan 21 16:40:07 etghopenaps12 bluetoothd[499]: Bluetooth daemon 5.23
Jan 21 16:40:07 etghopenaps12 bluetoothd[499]: D-Bus setup failed: Name alre...e
Jan 21 16:40:07 etghopenaps12 bluetoothd[499]: Unable to get on D-Bus
Jan 21 16:40:07 etghopenaps12 systemd[1]: bluetooth.service: main process ex...E
Jan 21 16:40:07 etghopenaps12 systemd[1]: Failed to start Bluetooth service.
Jan 21 16:40:07 etghopenaps12 systemd[1]: Unit bluetooth.service entered fai....
Hint: Some lines were ellipsized, use -l to show in full.
Jon Cluck
@cluckj
Jan 22 01:00
journalctl -u bluetooth may tell you more
Martin Haeberli
@mhaeberli
Jan 22 01:00
@cluckj :+1:
renegadeandy
@renegadeandy
Jan 22 01:01

@cluckj thoughts on how I could add an 'interference' test?

Does the edison rig have any controllable LEDs that I can trigger out of interest?

Martin Haeberli
@mhaeberli
Jan 22 01:01
I note that the service it ATTEMPTS to start is /usr/lib/bluetooth/bluetoothd, but /usr/local/bin/bluetoothd --experimental & seems to kind of get the ball rolling the right direction...
Jon Cluck
@cluckj
Jan 22 01:03
@mhaeberli maybe it's running different versions?
@renegadeandy no idea, sorry
Martin Haeberli
@mhaeberli
Jan 22 01:26
for reference, the ‘good’ set is:
d85f3d8681c54c7eb6aa1c14f75c928b  /home/.rootfs/usr/lib/bluetooth/bluetoothd
9a0cd411b6f0bf799a9face29c9f39cb  /home/.rootfs/usr/local/bin/bluetoothd
9a0cd411b6f0bf799a9face29c9f39cb  /home/.rootfs/usr/local/libexec/bluetooth/bluetoothd
9a0cd411b6f0bf799a9face29c9f39cb  /root/src/bluez-5.48/src/bluetoothd
and so is the ‘bad’ set - so it must be some other context
journalctl -u bluetooth
-- Logs begin at Mon 2019-01-21 16:55:20 PST, end at Mon 2019-01-21 17:28:21 PST
Jan 21 16:55:49 etghopenaps12 systemd[1]: Starting Bluetooth service...
Jan 21 16:55:49 etghopenaps12 bluetoothd[492]: Bluetooth daemon 5.23
Jan 21 16:55:49 etghopenaps12 bluetoothd[492]: D-Bus setup failed: Name already 
Jan 21 16:55:50 etghopenaps12 systemd[1]: bluetooth.service: main process exited
Jan 21 16:55:50 etghopenaps12 systemd[1]: Failed to start Bluetooth service.
Jan 21 16:55:50 etghopenaps12 systemd[1]: Unit bluetooth.service entered failed 
lines 1-7/7 (END)
on the broken one; on the good one, pretty much an empty happy log
renegadeandy
@renegadeandy
Jan 22 01:40
Ok! I am switching to the dev branch, wish me luck
Jon Cluck
@cluckj
Jan 22 01:44
good luck; remember to re-run the interactive setup, don't use runagain!
@mhaeberli systemd is trying to start the 5.23 version, and the one you're manually starting is 5.48?
Martin Haeberli
@mhaeberli
Jan 22 01:46
ok - so NEVER use runagain ?
ugh, ok, I’ll try, that might fix it...
@cluckj that sounds right
Jon Cluck
@cluckj
Jan 22 01:47
if you already have a dev install, using runagain is usually okay
Martin Haeberli
@mhaeberli
Jan 22 01:47
yes running dev install in all instances
Jon Cluck
@cluckj
Jan 22 01:50
@mhaeberli what version of bluetooth is systemd starting on one of the good rigs?
renegadeandy
@renegadeandy
Jan 22 01:51
@cluckj i just did git checkout dev, and then git pull, and the git pull just returned 'already up to date', without getting anything from github. Does that mean the initial clone wouldve brought down the latest dev?
Jon Cluck
@cluckj
Jan 22 01:52
yep, that's how git works :)
renegadeandy
@renegadeandy
Jan 22 01:52
yeah, but i checked this out a while back...surprised there havent been more recent git updates
guess it is, what it is!
Jon Cluck
@cluckj
Jan 22 01:53
the last commit was 15 days ago
Martin Haeberli
@mhaeberli
Jan 22 01:53
@cluckj as to which version I’ll have to check anon (soon). but on looking at the run-again, for some reason, I hadn’t enabled BT in it, so that’s a big d’oh! I’ll know soon - I’m running setup again now
Jon Cluck
@cluckj
Jan 22 01:53
@mhaeberli ah that may have messed with the install :)
Ebgineer
@Ebgineer
Jan 22 01:54
@gcarlson did your loop start running eventually? It can take a number of cycles before enough data is available to start controlling.
Martin Haeberli
@mhaeberli
Jan 22 01:56
on another topic, last I tried the autossh instructions with an Edison, they didn’t seem to work. Suggestions welcome
(right now, I’m just using some old cron scripts and a tunnel.sh script per discussions long ago)
renegadeandy
@renegadeandy
Jan 22 01:56
@cluckj what part of this project is your 'home', or area of expertise out of interest. Your knowledge seems broad!
Jon Cluck
@cluckj
Jan 22 01:57
the explorer hat, and general maintenance I guess?
renegadeandy
@renegadeandy
Jan 22 01:58
I see, you commited back to dev, what did you update?
renegadeandy
@renegadeandy
Jan 22 02:05

@cluckj

Would you like to [D]ownload released precompiled Go pump communication library or install an [U]nofficial (possibly untested) version.[D]/U

I presume D?

Jon Cluck
@cluckj
Jan 22 02:05
yep, D
I did some of the initial integration of the new radio stuff and a bunch of HAT stuff
renegadeandy
@renegadeandy
Jan 22 02:06
HAT?
Jon Cluck
@cluckj
Jan 22 02:07
the explorer board for the raspberry pi, with the radio/charger/button/screen on it
renegadeandy
@renegadeandy
Jan 22 02:08
I was asking earlier about making myopenaps folder a git repo
it turns out....it already was!
:/
dev just flagged that
Removing any existing git in /root/myopenaps/.git
Removed any existing git
gcarlson
@gcarlson
Jan 22 02:11
@Ebgineer no I left it running overnight in this state the last two nights, and the output was the same the next morning
Ebgineer
@Ebgineer
Jan 22 02:18
It looks like there might be more to the log output. Can you paste in the text from a whole loop?
renegadeandy
@renegadeandy
Jan 22 02:18
@cluckj the setup has failed
/home/.rootfs/usr/bin/peb-urchin-status -> /home/.rootfs/usr/lib/node_modules/oref0/bin/peb-urchin-status.sh
/home/.rootfs/usr/bin/wifi -> /home/.rootfs/usr/lib/node_modules/oref0/bin/oref0-tail-wifi.sh
+ oref0@0.7.0-dev
updated 1 package in 19.834s
jq: Unknown option --slurpfile
Use jq --help for help with command-line options,
or see the jq documentation at http://stedolan.github.com/jq
module.js:675
    throw err;
    ^

SyntaxError: /root/myopenaps/updated_prefs.json: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Object.Module._extensions..json (module.js:672:27)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/.rootfs/usr/local/lib/node_modules/oref0/bin/oref0-get-profile.js:87:23)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
Could not run oref0-get-profile
Jon Cluck
@cluckj
Jan 22 02:23
you have an older version of jq installed
renegadeandy
@renegadeandy
Jan 22 02:23
why wasnt that updated as part of the npm steps...?
Jon Cluck
@cluckj
Jan 22 02:25
dunno; iirc you can install the new version by doing apt-get -t jessie-backports install jq
renegadeandy
@renegadeandy
Jan 22 02:25
wondering if i should raise an issue
probably should
already in progress :)
renegadeandy
@renegadeandy
Jan 22 02:29
so....
why... when i reran the setup....did it work!
Jon Cluck
@cluckj
Jan 22 02:30
?
renegadeandy
@renegadeandy
Jan 22 02:34
well you said to do the apt-get -t jessie-backports,,, i didn't , i just reran the setup, and somehow it completed
is that pull request completed?
Jon Cluck
@cluckj
Jan 22 02:35
no, it's still a work-in-progress
something else may have updated jq
renegadeandy
@renegadeandy
Jan 22 02:35
hmm, then why did it succeed the second time, how weird
maybe...but thats crazy....why would the order of install have changed between 2 runs for example
something must have happened
odd.
Jon Cluck
@cluckj
Jan 22 02:36
I have no idea :laughing:
renegadeandy
@renegadeandy
Jan 22 02:37
well my friend ...... im looping on dev!
Last carbs 5 minutes ago; remainingCATime: 5 hours; 9% carbs absorbed
Carb Impact: 6.3 mg/dL per 5m; CI Duration: 5 hours; remaining CI (~2h peak): 10.5 mg/dL per 5m
predCIs (mg/dL/5m): 6 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 1 1 1
remainingCIs:       0 1 1 1 2 2 2 3 3 4 4 4 5 5 5 6 6 6 7 7 7 8 8 8 9 9 9 10 10 11 10 10 9 9 9 8 8 8 7 7 7 6 6 6 5 5 5 4
UAM Impact: 6.3 mg/dL per 5m; UAM Duration: 0.6 hours
minPredBG: 39 minIOBPredBG: 39 minZTGuardBG: -254 minCOBPredBG: 39 minUAMPredBG: 39 avgPredBG: 72 COB: 98 / 108
BG projected to remain above 4.8 for 45 minutes
BG projected to remain above 3.5 for 65 minutes
naive_eventualBG: -361 bgUndershoot: 424 zeroTempDuration: 65 zeroTempEffect: 56 carbsReq: 1
2019-01-22T02:36:44.950Z
Checking deliverAt: 2019-01-22T02:36:44.950Z is within 1m of current time: Mon Jan 21 20:36:45 CST 2019
and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":130,"tick":-2,"eventualBG":111,"insulinReq":0,"reservoir":"36\n","deliverAt":"2019-01-22T02:36:44.950Z","sensitivityRatio":1,"COB":98,"IOB":10.609,"duration":120,"rate":0}
"COB: 98, Dev: 2.1, BGI: -0.5, ISF: 2.6, CR: 9, Target: 4.8, minPredBG 2.2, minGuardBG -0.4, IOBpredBG 2.2, COBpredBG 6.2, UAMpredBG 2.2; minGuardBG -0.4<3.5"
COB: [130,128,125,121,116,111,105,98,92,85,78,72,66,59,54,48,44,39,39,39,39,39,39,39,39,39,39,39,39,39,41,45,50,54,58,63,67,71,76,80,84,88,92,96,100,104,108,111]
UAM: [130,127,122,114,104,93,80,65,51,39,39,39,39]
IOB: [130,127,123,117,109,99,89,77,64,50,39,39,39]
ZT:  [130,122,112,101,89,76,62,48,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]
Temp refreshed: monitor/temp_basal.json: {"duration":0,"temp":"absolute","rate":1.15}
enact/smb-enacted.json: "Rate: 0 Duration: 120"
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Temp refreshed: monitor/temp_basal.json: {"duration":120,"temp":"absolute","rate":0}
No bolus needed. Pump profile refreshed; Could not parse temptargets_data.
No temptargets found.
Settings refreshed; grep: enact/bolused.json: No such file or directory
Refreshing pumphistory because: enacted, Settings less than 3 minutes old. Pump history updated through 2019-01-21T20:36:48-06:00 with 2 new records; meal.json refreshed: {"carbs":108,"nsCarbs":108,"bwCarbs":0,"journalCarbs":0,"mealCOB":94,"currentDeviation":6.7,"maxDeviation":8.11,"minDeviation":4.52,"slopeFromMaxDeviation":-0.344,"slopeFromMinDeviation":1.037,"allDeviations":[7,5,5,8,8,7],"lastCarbTime":1548124291000,"bwFound":false}
{"carbs":108,"nsCarbs":108,"bwCarbs":0,"journalCarbs":0,"mealCOB":94,"currentDeviation":6.7,"maxDeviation":8.11,"minDeviation":4.52,"slopeFromMaxDeviation":-0.344,"slopeFromMinDeviation":1.037,"allDeviations":[7,5,5,8,8,7],"lastCarbTime":1548124291000,"bwFound":false}
IOB: 10.53
Completed oref0-pump-loop at Mon Jan 21 20:37:43 CST 2019
Jon Cluck
@cluckj
Jan 22 02:39
great!
renegadeandy
@renegadeandy
Jan 22 02:42
wow, lots and lots of changes. Logging output pattern is different. glad to see all those riley link messages removed, were frustratingly useless
renegadeandy
@renegadeandy
Jan 22 02:52
@cluckj autotune is enabled by default but not smb right?
Jon Cluck
@cluckj
Jan 22 02:54
autotune has a switch in setup, smb you can toggle using preferences.json
renegadeandy
@renegadeandy
Jan 22 02:55
i like that more preferences are in place now , its all in one place which is nice
Jon Cluck
@cluckj
Jan 22 02:55
yep
renegadeandy
@renegadeandy
Jan 22 02:55
i didnt need to merge preferences.json, as it seemed to happen for me
so how can I check if my jq version is what it should be?
and additionally, if i change the curve preference from what it was, to ultra-rapid, do I need to reboot to make that change take effect?
renegadeandy
@renegadeandy
Jan 22 03:01

I see

SMB disabled (no enableSMB preferences active)

in the log, but then i also see:

and that smb-suggested.json is less than 1m old
enact/smb-suggested.json: {"temp":"absolute","bg":157,"tick":"

is it ok that this smb-suggested is written etc, it doesn't mean that its running? Its a bit unnerving to see that

Jon Cluck
@cluckj
Jan 22 03:02
jq --version?
no, the change should take effect without a reboot
renegadeandy
@renegadeandy
Jan 22 03:03
ok i have jq 1.5.1, so appears to be up to date
Jon Cluck
@cluckj
Jan 22 03:03
and everything uses the SMB loop, but it will only deliver an SMB if you have them enabled
renegadeandy
@renegadeandy
Jan 22 03:03
i see cool
and! I see more led blinking on this version
what do they mean?
Jon Cluck
@cluckj
Jan 22 03:04
the loops complete rather fast on the edison in dev
red/green is tx/rx on the radio
renegadeandy
@renegadeandy
Jan 22 03:06
cool :)
do you happen to know where in the code base, those leds are 'blinked'? Id like to play with D1 (I know its a charging led)
Jon Cluck
@cluckj
Jan 22 03:15
you'd probably have to mess with the subg_rfspy firmware to change what the tx/rx LEDs do
renegadeandy
@renegadeandy
Jan 22 03:18
i don't plan on altering the tx/rx leds, (that looks new as of 0.7.0)
but I would like to try to do something wth that charging led
maybe just a status blinky every 20 seconds or something, to show that the last loop was successful, or failed
so at a glance, i can be happy things are good
gcarlson
@gcarlson
Jan 22 03:43
@Ebgineer Here's a full loop output:
Starting oref0-pump-loop at Mon Jan 21 16:51:02 PST 2019 with 17 second wait_for_silence:
Waiting up to 4 minutes for new BG: jq: monitor/glucose.json: No such file or directory
jq: monitor/glucose.json: No such file or directory
ls: cannot access /tmp/pump_loop_completed: No such file or directory
Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Preflight OK. Profile less than 60m old; Profile valid. touch: failed to get attributes of ‘monitor/glucose.json’: No such file or directory
Couldn't touch /tmp/pump_loop_enacted -r monitor/glucose.json
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 40s silence before mmtuning
Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Listening for 40s silence before mmtuning: .No interfering pump comms detected from other rigs (this is a good thing!)
mmtune: "916.660", 5, -86 waiting for 52 second silence before continuing
Radio ok. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Preflight OK. Done waiting for rigs with better signal.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Mon Jan 21 16:54:21 PST 2019
Ebgineer
@Ebgineer
Jan 22 04:38
@gcarlson in this case it looks like the rig is missing the glucose values (jq: monitor/glucose.json: No such file or directory)
so the connection to the cgm data may not be working. how is your rig meant to obtain bg values?
gcarlson
@gcarlson
Jan 22 04:39
I'm using a G6 with xdrip+, reading from NS
Ebgineer
@Ebgineer
Jan 22 04:41
looks ok in NS?
gcarlson
@gcarlson
Jan 22 04:42
I can see my live BGs on the site, yes
Ebgineer
@Ebgineer
Jan 22 04:43
good, and can you see any info in the openaps pill in NS too?
gcarlson
@gcarlson
Jan 22 04:44
no, that shows up as unknown
Ebgineer
@Ebgineer
Jan 22 04:46
I haven't had this exact problem before, but I'd check the rig's wifi connection and also verify the api secret in NS vs. what the rig is using. There are some troubleshooting steps that may apply here https://openaps.readthedocs.io/en/master/docs/Troubleshooting/Rig-NS-communications-troubleshooting.html
gcarlson
@gcarlson
Jan 22 04:48
wifi seems fine (pinging google works with ~30 ms ping)
Ebgineer
@Ebgineer
Jan 22 04:48
cool
gcarlson
@gcarlson
Jan 22 04:50
api key looks fine too
Ebgineer
@Ebgineer
Jan 22 04:52
that troubleshooting guide looks like it was rewritten and probably has some juicy pointers
gcarlson
@gcarlson
Jan 22 04:55
Can I rerun the connection to NS to see a more detailed error?
Martin Haeberli
@mhaeberli
Jan 22 04:56
@gcarlson - I think what you want to do is confirm that your rig can get BG values from Nightscout, and, if not, learn more about why not.
if you can log into the rig, one way to do this is to query Nightscout via curl.
Neal
@tnharvey
Jan 22 04:57
I just got in and had notice from ERD that the 900MHZ Explorer Hat was back in stock, but it says it's out of stock again!? Did it seriously sell out in a few hours?
Martin Haeberli
@mhaeberli
Jan 22 04:57
i’ll try to send you an example
gcarlson
@gcarlson
Jan 22 04:57
cool, thanks. I'm logged in to the rig now
LukoninDanila
@LukoninDanila
Jan 22 05:02
Hello! I want to set up a basal profile. What period you need to watch: for 1 hour or 2 hours before?
Martin Haeberli
@mhaeberli
Jan 22 05:02
@gcarlson - a) try something like: curl -v https://<site>.herokuapp.com/api/v1/experiments/test --header "api-secret: <hash>” see https://github.com/nightscout/cgm-remote-monitor/wiki/API-v1.0.0-beta-Security and http://www.sha1-online.com/ also … for example, if your api-secret is ‘api-secret’ its hash would be ‘1523a9e1ed83a882d980779db02c2b3e8d147686’ This should return {"status":"ok"}
gcarlson
@gcarlson
Jan 22 05:07
I got status : ok yes
  • Connection #0 to host XXX.herokuapp.com left intact
    if that helps
Martin Haeberli
@mhaeberli
Jan 22 05:07
good - so there is a way to get sgv entries
I’m trying to look up my notes so i can send you a sample
gcarlson
@gcarlson
Jan 22 05:08
hang on- when I put my api key into oref0, should that be the hashed version?
Martin Haeberli
@mhaeberli
Jan 22 05:08
yes
gcarlson
@gcarlson
Jan 22 05:08
oh wow
Martin Haeberli
@mhaeberli
Jan 22 05:08
when i tried the unhashed version i did NOT get OK
but it may also depend on nightscout security settings
gcarlson
@gcarlson
Jan 22 05:09
I was passing the unhashed key into oref0
let me try that
Martin Haeberli
@mhaeberli
Jan 22 05:10
my result ends with * Connection #0 to host <site>.herokuapp.com left intact {"status":"ok”}
if you try curl -v https://<site>.herokuapp.com/api/v1/entries.json --header "api-secret: <hash>” you should get some entries in json format, like [{"_id":"5c46a5556aadb2c47c6bccbe","sgv":220,"date":1548133663000,"dateString":"2019-01-22T05:07:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c46a4296aadb2c47c6bc844","sgv":221,"date":1548133363000,"dateString":"2019-01-22T05:02:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c46a2fd6aadb2c47c6bc3a3","sgv":220,"date":1548133062000,"dateString":"2019-01-22T04:57:42.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c46a1d26aadb2c47c6bbe1a","sgv":217,"date":1548132762000,"dateString":"2019-01-22T04:52:42.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c46a0a46aadb2c47c6bb97d","sgv":213,"date":1548132463000,"dateString":"2019-01-22T04:47:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c469f7a6aadb2c47c6bb517","sgv":209,"date":1548132163000,"dateString":"2019-01-22T04:42:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c469e4c6aadb2c47c6bb0bc","sgv":205,"date":1548131863000,"dateString":"2019-01-22T04:37:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c469d206aadb2c47c6babd3","sgv":203,"date":1548131563000,"dateString":"2019-01-22T04:32:43.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c469bf46aadb2c47c6ba759","sgv":195,"date":1548131262000,"dateString":"2019-01-22T04:27:42.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"},{"_id":"5c469ac86aadb2c47c6ba33c","sgv":193,"date":1548130962000,"dateString":"2019-01-22T04:22:42.000Z","trend":4,"direction":"Flat","device":"share2","type":"sgv"}]
gcarlson
@gcarlson
Jan 22 05:12
I'm trying oref0-runagain with the hashed key now. That would be awesome if it worked
Martin Haeberli
@mhaeberli
Jan 22 05:13
I was able to use unhashed key in oref0-setup (recommendation is to use oref0-setup and enter values manually) - it then stores the hashed value ...
for starters, try the above curl on the rig, make sure it gives reasonable results.
if it doesn’t, you will have problems
gcarlson
@gcarlson
Jan 22 05:21
I tried that curl command and got something similar, yes
Martin Haeberli
@mhaeberli
Jan 22 05:30
so then you -should- be (nearly) in good shape… which branch are you running, on what platform? dev on RPi with hat?
gcarlson
@gcarlson
Jan 22 05:32
I'm using edison with explorer, I think dev branch but how do I confirm?
Martin Haeberli
@mhaeberli
Jan 22 05:34

at this point i’d recommend dev. to confirm:

cd ~/src/oref0
git branch -a

(it should show ‘dev’ as highlighted. if it doesn’t, then git checkout dev, npm run global-install, then run oref0-setup again. but important first to: service cron stop; killall -g oref0-pump-loop to avoid trying to run OpenAPS while you’re updating / installing)

gcarlson
@gcarlson
Jan 22 05:39
Ok, branch was master. I'm running setup again now
Dave Cole
@Dave9111
Jan 22 05:44
@tnharvey Send them an email.. they will get back with you and tell you their stock situation.
gcarlson
@gcarlson
Jan 22 05:57
ok, running oref0-setup again, I now got:
module.js:675
    throw err;
    ^

SyntaxError: /root/myopenaps/updated_prefs.json: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at Object.Module._extensions..json (module.js:672:27)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/.rootfs/usr/local/lib/node_modules/oref0/bin/oref0-get-profile.js:87:23)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
Could not run oref0-get-profile
gcarlson
@gcarlson
Jan 22 06:28
Actually, I tried running oref0-runagain even after this step failed, and this time the loop succeeded! Thank you very much for the help. Was the only issue then the version I was running, since that was the only change I made?
Scott Leibrand
@scottleibrand
Jan 22 09:13
@renegadeandy @cluckj the LED blink is actually not tx/rx, it’s “reset”, which the new go code does most every time before doing anything, vs. less often with master.
@LukoninDanila can you be a bit more specific?
tuzoenduro
@tuzoenduro
Jan 22 10:42
hi, I just don't know what is wrong with my rig and any help would be great.. @danamlewis @scottleibrand I'm sorry to pester you for stupid things but this stumps me... I tailed the logs and all I get is continuous loops of this :
Starting oref0-pump-loop at Tue 22 Jan 11:24:15 CET 2019 with 13 second wait_for_silence:
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening for 13s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue 22 Jan 11:24:32 CET 2019
Preflight OK. Old settings: jq: error (at settings/pumpprofile.json.new:1): Cannot index number with string "current_basal"
Invalid pumpprofile.json.new after refresh
-rw-r--r-- 1 root root 3 Jan 22 11:25 settings/pumpprofile.json.new
Could not parse autotune_data
Could not parse temptargets_data.
ERROR: bad basal schedule [ { i: 0, start: '00:00:00', minutes: 0, rate: 0 } ]
max_daily_basal of 0 is not supported
jq: error (at settings/profile.json.new:1): Cannot index number with string "current_basal"
Invalid profile.json.new after refresh
-rw-r--r-- 1 root root 3 Jan 22 11:25 settings/profile.json.new
Profile valid. Pump history updated through 2019-01-22T11:04:43+01:00 with 0 new records; meal.json Could not parse input data:  { Error: ENOENT: no such file or directory, open 'settings/profile.json'
    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/oref0/bin/oref0-meal.js:50:42)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'settings/profile.json' }
{ "carbs": 0, "mealCOB": 0, "reason": "Could not parse input data" }
cat: monitor/meal.json: No such file or directory
Couldn't check_cp_meal - continuing
Retry 1 of refresh_pumphistory_and_meal
Pump history updated through 2019-01-22T11:04:43+01:00 with 0 new records; meal.json Could not parse input data:  { Error: ENOENT: no such file or directory, open 'settings/profile.json'
    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/oref0/bin/oref0-meal.js:50:42)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'settings/profile.json' }
{ "carbs": 0, "mealCOB": 0, "reason": "Could not parse input data" }
cat: monitor/meal.json: No such file or directory
Couldn't check_cp_meal - continuing
Listening for 7s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue 22 Jan 11:28:23 CET 2019
Retry 2 of refresh_pumphistory_and_meal
Pump history updated through 2019-01-22T11:04:43+01:00 with 0 new records; meal.json Could not parse input data:  { Error: ENOENT: no such file or directory, open 'settings/profile.json'
    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/oref0/bin/oref0-meal.js:50:42)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'settings/profile.json' }
{ "carbs": 0, "mealCOB": 0, "reason": "Could not parse input data" }
cat: monitor/meal.json: No such file or director
and the missing tail end of it :
Couldn't check_cp_meal - continuing
Listening for 13s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue 22 Jan 11:29:58 CET 2019
Retry 3 of refresh_pumphistory_and_meal
Pump history updated through 2019-01-22T11:04:43+01:00 with 0 new records; meal.json Could not parse input data:  { Error: ENOENT: no such file or directory, open 'settings/profile.json'
    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Object.<anonymous> (/usr/local/lib/node_modules/oref0/bin/oref0-meal.js:50:42)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:188:16)
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'settings/profile.json' }
{ "carbs": 0, "mealCOB": 0, "reason": "Could not parse input data" }
cat: monitor/meal.json: No such file or directory
Couldn't check_cp_meal - continuing
Couldn't refresh_pumphistory_and_meal
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 38 s silence before mmtuning
Updating HAT Display...
and it goes on and on like that... can you tell me if maybe my rig is borked, my install, my pump? something else? I really don't know what to do... thank you for your help.
tuzoenduro
@tuzoenduro
Jan 22 10:57
for context, I'm using a Pi 0 + explorer HAT, and the explorer hat gets updated (I get a nice screen) but it is empty other than the x & y axis & the hour...
I don't know if I should open an issue in github, if anyone can help me I will continue this...
I switched to dev during the Pi install, and my NS is running on dev as well
thanks
tuzoenduro
@tuzoenduro
Jan 22 11:35
also context, I did flash the sd card with the lite version of raspbian through pibakery, and they I saw issue openaps/oref0#1035 and it looks eerily similar to what I am getting, so I will be installing the stretch raspbian lite version with etcher and see if that makes a difference...
NSewar
@nsewar01
Jan 22 12:06
A hardware question.......I managed to pull the aerial off the explorer block with some force and broke male the connector pin on the board not the female connector on the end of the aeriel wire! Can anyone advise a fix? Conductive glue perhaps? Rig is looping OK when in close proximity to the rig. There is an aerial connector on top of the Edison block.... what does this do?
Kevin Marshall
@ruess
Jan 22 12:40
When setting up their Pi Zero Rig with HAT, has anyone run into issues with NPM?
I keep getting errors such as: npm ERR! Failed at the oref0@0.7.0-dev global-install script.
npm ERR! This is most likely a problem with the oref0 package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! npm install && sudo npm link && sudo npm link oref0 && sudo npm install -g
Ivica Suran
@isuran
Jan 22 13:12
@ruess run npm install from oref0 directory
Kevin Marshall
@ruess
Jan 22 13:20
thanks @isuran - i believe i did so, but will double check next time
tuzoenduro
@tuzoenduro
Jan 22 13:23
@isuran can you tell me how you do that exactly?? I do not know which command to use...
I have had this issue
I just do a cd oref0?
Kevin Marshall
@ruess
Jan 22 13:25
or did you mean to just run: "npm install" instead of or in addition to "npm run global-install" @isuran ?
Ivica Suran
@isuran
Jan 22 13:28
cd ~/src/oref0
then npm run global-install
don't forget git checkout dev
tuzoenduro
@tuzoenduro
Jan 22 13:29
after or before the npm?
ah yes, after, so it switches to the dev version
and before the oref0 setup script
Kevin Marshall
@ruess
Jan 22 13:31
thanks @isuran
tuzoenduro
@tuzoenduro
Jan 22 13:31
I'm flashing my sd card again since I saw on the 1035 issue that the raspbian version could be a source of issues.. as soon as it is done I will check this out
thanks @isuran
tuzoenduro
@tuzoenduro
Jan 22 14:27
I get this while running the setup script
npm ERR! invalid: oref0@0.7.0-dev /usr/local/lib/node_modules/oref0
npm ERR! not ok code 0
@isuran is this ok or something else is off?
tzachi-dar
@tzachi-dar
Jan 22 14:37
@tnharvey I had an order that was standing for about 45 days, now it is finally shipped. They promised to have more early february.
renegadeandy
@renegadeandy
Jan 22 14:51
@scottleibrand ah, so its the start of the next loop?
tuzoenduro
@tuzoenduro
Jan 22 14:54
@isuran hello Ivica, no luck.. I keep getting errors and no successful loops... same thing I posted earlier...
Eric
@ecc1
Jan 22 14:57
PSA: sending cleartext strings to a random site on the web in order to get a SHA1 hash isn't a very secure thing to do -- they may just be collecting passwords. Just do echo "password" | sha1sum on the command line.
Jon Cluck
@cluckj
Jan 22 15:12
@tuzoenduro have you had any successful loops with this pump before?
the main error message you're getting is from the rig having trouble reading the basal profile in your pump:
ERROR: bad basal schedule [ { i: 0, start: '00:00:00', minutes: 0, rate: 0 } ]
tuzoenduro
@tuzoenduro
Jan 22 15:21
@cluckj no, which is why I asked further up if there was a way to test the pump for looping in case there was an issue with it...
it's a 722, on 2.2 firmware
Jon Cluck
@cluckj
Jan 22 15:22
do you have a basal program set up in the pump?
tuzoenduro
@tuzoenduro
Jan 22 15:22
yes.. I input all my basals from my current pump into it
and I can see that it chugs along and is dosing insulin every day...
dosing air for the moment, but it is going at it
Jon Cluck
@cluckj
Jan 22 15:26
double check your basals to make sure that there aren't any 0 units/hour rates in it
(need to go for a couple hours, but I'll be back!)
tuzoenduro
@tuzoenduro
Jan 22 15:27
ok, thanks..
tuzoenduro
@tuzoenduro
Jan 22 15:35
I double checked and the 'Standard' basal rate was at 0, I had input all my values on the Pattern A... So I copied it all onto the 'Standard' and am testing again...
tuzoenduro
@tuzoenduro
Jan 22 15:48
It's ALIIIIIVEEEE!!! thanks a million @cluckj ! I did not know the pump would have a preferred basal rate... now i copied mine over it's picking stuff up, the pill in NS is active and I can smile again :) thanks for your help
Jon Cluck
@cluckj
Jan 22 15:49
:thumbsup:
tuzoenduro
@tuzoenduro
Jan 22 15:49
how can i see on the pump if temp basals are active? I have no experience with a 722, I'm coming from a 640 where things were more visual
Jon Cluck
@cluckj
Jan 22 15:51
hollow circle icon?
tuzoenduro
@tuzoenduro
Jan 22 15:52
that is the indicator?? thing is it was on even before I started setting up the rig
there we go.. the pump was still expecting a sensor, which is why the indicator was on... now it is on because of a temp basal
awesome, simply fantastic.. thanks for the help
renegadeandy
@renegadeandy
Jan 22 16:03

@cluckj at the office today, on dev 0.7.0, same issues:

Starting oref0-pump-loop at Tue Jan 22 09:43:03 CST 2019 with 22 second wait_for_silence:
Waiting up to 4 minutes for new BG: glucose.json newer than pump_loop_completed

Listening for 22s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:43:27 CST 2019
Preflight fail. Retry 1 of preflight
Preflight fail. Listening for 4s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:44:44 CST 2019
Retry 2 of preflight
Preflight fail. Listening for 22s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:45:43 CST 2019
Retry 3 of preflight
Preflight fail. Couldn't preflight
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 34 s silence before mmtuning
Listening for 34s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:46:55 CST 2019
Listening for 34 s silence before mmtuning: Listening for 34s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:47:30 CST 2019
mmtune: "868.350", 3, -69 
waiting for 18 second silence before continuing
Listening for 18s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:48:25 CST 2019
Done waiting for rigs with better signal.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Tue Jan 22 09:48:25 CST 2019

another example

Starting oref0-pump-loop at Tue Jan 22 09:54:03 CST 2019 with 30 second wait_for_silence:
Waiting up to 4 minutes for new BG: ...............glucose.json newer than pump_loop_completed

Listening for 30s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:57:39 CST 2019
Preflight fail. Retry 1 of preflight
Preflight fail. Listening for 5s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:59:16 CST 2019
Retry 2 of preflight
Preflight OK. Profile less than 60m old; Profile valid. Pump history update failed. Last record 2019-01-22T09:50:27-06:00
Couldn't invoke_pumphistory_etc - continuing
Retry 1 of refresh_pumphistory_and_meal
Pump history update failed. Last record 2019-01-22T09:50:27-06:00
Couldn't invoke_pumphistory_etc - continuing
Listening for 5s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 09:59:47 CST 2019
Retry 2 of refresh_pumphistory_and_meal
Listening for 30s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Tue Jan 22 10:01:40 CST 2019
Retry 3 of refresh_pumphistory_and_meal
Pump history update failed. Last record 2019-01-22T09:50:27-06:00
Couldn't invoke_pumphistory_etc - continuing
Couldn't refresh_pumphistory_and_meal
oref0-pump-loop failed. If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Tue Jan 22 10:01:48 CST 2019
@ecc1 suggests finding the stderr for the pump loop radio calls, to see if there is output in there. @scottleibrand any idea where that gets routed to?
Eric
@ecc1
Jan 22 17:09
@renegadeandy I also suggested that you read the code. Plenty of lines in bin/oref0-pump-loop.sh like the following:
  mdt reservoir 2>&3 | tee monitor/reservoir.json && nonl < monitor/reservoir.json \
  mdt model 2>&3 | tee settings/model.json
    mdt status 2>&3 | tee monitor/status.json 2>&3 >&4 && cat monitor/status.json | colorize_json .status
  mdt clock 2>&3 | tee monitor/clock-zoned.json >&4 && grep -q T monitor/clock-zoned.json
  mdt battery 2>&3 | tee monitor/battery.json && cat monitor/battery.json | jq .voltage
  mdt tempbasal 2>&3 | tee monitor/temp_basal.json >&4 && cat monitor/temp_basal.json | jq
Usage of fds 3 and 4 is described in the comments at the top of that file
renegadeandy
@renegadeandy
Jan 22 17:43
@ecc1 I find that a steep jump in terms of understanding. I don't even know what mdt is.......but hey, i guess its study it and see (really wanted a foot up, i don't have much time to mess with stuff)
renegadeandy
@renegadeandy
Jan 22 17:48

for example, trying to figure it out on my own, i go to here : https://openaps.readthedocs.io/en/latest/search.html?q=mdt&check_keywords=yes&area=default -- which has no reference to mdt

I type mdt on the rig:

 mdt
usage: mdt [options] command [ arg ... ]
   or: mdt [options] command [ args.json ]
  -f format
        print result in specified format (default "openaps")
output formats: json openaps internal
commands: basal battery bolus button carbratios carbunits clock execute firmware glucoseunits model pumpid reservoir resume rssi sensitivities setclock setmaxbasal setmaxbolus settempbasal settings status suspend targets tempbasal wakeup

so I try
mdt battery 2>&3 | tee monitor/battery.json && cat monitor/battery.json | jq .voltage

But get

root@andyaps:~/myopenaps# mdt battery 2>&3 | tee monitor/battery.json && cat monitor/battery.json | jq .voltage
-bash: 3: Bad file descriptor
root@andyaps:~/myopenaps#

Mdt has no man, has no --help so where next?

so its probably all really simple, but its not standalone, its not self sufficient or easy to pick this stuff apart
there should be an onboarding doc
Eric
@ecc1
Jan 22 17:52
that output from mdt with no arguments is the "--help" output. just try "mdt battery" to see the output, for example. I'm sure the project will welcome any onboarding document you write ...
renegadeandy
@renegadeandy
Jan 22 17:56
I actually tried that too
and got this:
2019/01/22 11:56:35 cannot connect to CC111x radio on /dev/spidev5.1
2019/01/22 11:56:35 /dev/spidev5.1: device is in use
which makes sense, as presumably the loop is using it
it would be better if mdt just said at the top "This program communicates with the pump over radio to retrieve or issue various commands
because, how else am i to know, what the program is actually for
Scott Leibrand
@scottleibrand
Jan 22 18:00
@renegadeandy not necessarily. the LEDs blink in a regular pattern every 10s or so during wait_for_silence, and then blink again before each pump comms command, so they blink pretty actively when it's doing lots of little commands, but won't necessarily blink at all when the rig is pulling pumphistory (which is the most tx/rx intensive command)
djnoor
@djnoor
Jan 22 19:45
Are there any 522/722 pumps that are not loopable because of firmware upgrades?
In the docs, it says that if you send pumps in to Medtronic for repairs, the firmware can get upgraded. So does that mean that a 722 might not be loopable if this happened and it had newer firmware?
Scott Leibrand
@scottleibrand
Jan 22 19:52
as I understand it, if MDT "upgrades" your pump, it will be refurbished and given a new model number
AFAIK only 523/723 (and possibly their equivalents in other countries) have both loopable and non-loopable firmware available
Martin Haeberli
@mhaeberli
Jan 22 19:53
generally, my understanding (without citable evidence) is that any loop able pumps sent to medtronic for refurbishment will be upgraded to non-loopable
Scott Leibrand
@scottleibrand
Jan 22 19:55
right, but the question is: do they distribute said pumps as non-loopable 522/722's? AFAIK they do not
Eric
@ecc1
Jan 22 20:11
yeah, that would be some kind of anti-unicorn
Jon Cluck
@cluckj
Jan 22 20:15
a horse?
Scott Leibrand
@scottleibrand
Jan 22 20:26
lol
djnoor
@djnoor
Jan 22 21:17
Ok, thanks. Looking at a 722 online. Just wasn't sure if I could end up with a non-loopable version. Sounds like it's a low risk.
Scott Leibrand
@scottleibrand
Jan 22 21:56
yeah, pretty low risk. if you don't trust the seller much you can get them to send you a photo or video of the utilities, connect devices screen (I think it is: check the docs) so you can check for PC Connect. if that's absent, you're good.
renegadeandy
@renegadeandy
Jan 22 22:02
who wrote mdt?
Scott Leibrand
@scottleibrand
Jan 22 22:03
@ecc1
renegadeandy
@renegadeandy
Jan 22 22:06
lol, so when you say if "MDT" upgrades your pump, you are not talking about @ecc1 's mdt ;)
I got rather confused there
Scott Leibrand
@scottleibrand
Jan 22 23:15
Heh, no. mdt controls MDT pumps.
renegadeandy
@renegadeandy
Jan 22 23:40
MDT == medtronic?
Jon Cluck
@cluckj
Jan 22 23:45
mdt = medtronic, do (a) temp-basal