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

2nd
Nov 2018
Steve Lund
@902Lund
Nov 02 2018 00:22
Hi All. I'm having a problem accessing NS. Everything has been fine all day...now that I'm home all my devices are asking for my API secret. It keeps telling me that it's wrong when I enter it. I'm definitely entering it correctly...copy/paste from Heroku. I tried to search Gitter for other instances of this issue and have tried a couple of the suggested fixes such as checking mongoDB size, updating credit card info for Heroku. Does anyone have any suggestions/insight about this issue? I'm kind of stuck now...
Steve Lund
@902Lund
Nov 02 2018 00:31
Please disregard the above. It seems to be working again. All of a sudden NS is accepting my API secret...maybe 1 of the above fixes worked but, it took a few minutes to take effect.
tzachi-dar
@tzachi-dar
Nov 02 2018 00:36
Hi,
On the file settings/profile.json I see basal values that I did not put.
They are in the resolution of per 30 minutes and also have fractions.
Who puts them there? Is it autotune?
Thanks
Tzachi
Scott Leibrand
@scottleibrand
Nov 02 2018 01:49
No, autotune only operates on hourly boundaries. Those should come from the pump.
Raymond Richmond
@PedanticAvenger
Nov 02 2018 02:44
Attempting to get pushover setup I think I whacked something else. How do I confirm most likely source of error with the following?
Nov 01 20:42:02 bit pump-loop.log: Starting oref0-pump-loop at Thu Nov  1 20:42:02 MDT 2018 with 26 second wait_for_silence:
Nov 01 20:42:03 bit pump-loop.log: Waiting up to 4 minutes for new BG: ls: cannot access /tmp/pump_loop_completed: No such file or directory
Nov 01 20:42:03 bit pump-loop.log: using carelink; not waiting for silence
Nov 01 20:42:23 bit pump-loop.log: Preflight OK. Profile less than 60m old; Profile valid. Refreshed pumphistory and meal.json
Nov 01 20:42:25 bit pump-loop.log: Checking pump clock: "2018-11-01T20:16:43-06:00" is within 90s of current time: Thu Nov  1 20:42:25 MDT 2018
Nov 01 20:42:25 bit pump-loop.log: Pump clock is more than 55s off: attempting to reset it
Nov 01 20:42:25 bit pump-loop.log: Waiting for ntpd to synchronize...  OK!
Nov 01 20:42:40 bit pump-loop.log: Setting pump time to Thu Nov 1 20:42:40 MDT 2018
Nov 01 20:42:43 bit pump-loop.log: serial.serialutil.SerialException: Attempting to use a port that is not open
Nov 01 20:42:43 bit pump-loop.log: Error: pump clock refresh error / mismatch
Nov 01 20:42:43 bit pump-loop.log: oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 40s silence before mmtuning
Nov 01 20:42:43 bit pump-loop.log: using carelink; not waiting for silence
Nov 01 20:42:43 bit pump-loop.log: using carelink; skipping mmtune
Nov 01 20:42:43 bit pump-loop.log: If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Nov 01 20:42:43 bit pump-loop.log: Unsuccessful oref0-pump-loop at Thu Nov 1 20:42:43 MDT 2018
My gut says all the "carelink" is wrong, but as I was foolish enough to not backup that folder before I went mucking about.....
Raymond Richmond
@PedanticAvenger
Nov 02 2018 03:27
Yeah, my runagain was all messed up and I had to go back to my last known good config for that. All good now, proper comms should be restored and rebooting now.
djnoor
@djnoor
Nov 02 2018 03:50
I needed to setup autotune to use data from XdripAPS. So I reflashed Yocto, then reflashed Jubilinux 3.10.98, then installed Oref0 0.7.0 dev. Everything went well until the Edison rig tried to loop. It's been well over an hour and it keeps failing at preflight and mmtune. The rig is connected to the internet via Bluetooth tethering to my phone. The rig is getting data but it's not looping.
I've confirmed that the pump's serial number is correct.
Here's the error messages I'm getting
Starting oref0-pump-loop at Thu Nov  1 22:43:30 CDT 2018 with 22 second wait_for_silence:
grep: enact/smb-suggested.json: No such file or directory
grep: enact/smb-suggested.json: No such file or directory
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening for 22s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Nov  1 22:43:54 CDT 2018
Preflight 2018/11/01 22:43:55 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:43:55 setting frequency to 916.550
2018/11/01 22:43:56 waking pump
2018/11/01 22:44:11 no response to wakeup
2018/11/01 22:44:12 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:44:12 setting frequency to 916.550
2018/11/01 22:44:14 waking pump
2018/11/01 22:44:29 no response to wakeup
fail. Retry 1 of preflight
Preflight 2018/11/01 22:44:30 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:44:30 setting frequency to 916.550
2018/11/01 22:44:32 waking pump
2018/11/01 22:44:46 no response to wakeup
2018/11/01 22:44:47 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:44:47 setting frequency to 916.550
2018/11/01 22:44:49 waking pump
2018/11/01 22:45:04 no response to wakeup
fail. Listening for 10s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Nov  1 22:45:15 CDT 2018
Retry 2 of preflight
Preflight 2018/11/01 22:45:16 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:45:16 setting frequency to 916.550
2018/11/01 22:45:18 waking pump
2018/11/01 22:45:33 no response to wakeup
2018/11/01 22:45:34 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:45:34 setting frequency to 916.550
2018/11/01 22:45:35 waking pump
2018/11/01 22:45:50 no response to wakeup
fail. Listening for 22s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Nov  1 22:46:13 CDT 2018
Retry 3 of preflight
Preflight 2018/11/01 22:46:14 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:46:14 setting frequency to 916.550
2018/11/01 22:46:16 waking pump
2018/11/01 22:46:31 no response to wakeup
2018/11/01 22:46:32 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:46:32 setting frequency to 916.550
2018/11/01 22:46:34 waking pump
2018/11/01 22:46:48 no response to wakeup
fail. Couldn't preflight
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 16 s silence before mmtuning
Listening for 16s: .^C.No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Nov  1 22:47:21 CDT 2018
Listening for 16 s silence before mmtuning: Listening for 16s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Thu Nov  1 22:47:38 CDT 2018
mmtune: 2018/11/01 22:47:39 connected to CC111x radio on /dev/spidev5.1
2018/11/01 22:47:39 setting frequency to 916.550
2018/11/01 22:47:40 waking pump
2018/11/01 22:47:55 no response to wakeup
2018/11/01 22:47:55 frequency set to 916.300
2018/11/01 22:47:56 frequency set to 916.350
2018/11/01 22:47:58 frequency set to 916.400
2018/11/01 22:47:59 frequency set to 916.450
2018/11/01 22:48:01 frequency set to 916.500
2018/11/01 22:48:03 frequency set to 916.550
2018/11/01 22:48:04 frequency set to 916.600
2018/11/01 22:48:06 frequency set to 916.650
2018/11/01 22:48:08 frequency set to 916.700
2018/11/01 22:48:09 frequency set to 916.750
2018/11/01 22:48:11 frequency set to 916.800
2018/11/01 22:48:12 frequency set to 916.850
2018/11/01 22:48:14 frequency set to 916.900
{
  "scanDetails": [
    [
      "916.300",
      0,
      -128
    ],
    [
      "916.350",
      0,
      -128
    ],
    [
      "916.400",
      0,
      -128
    ],
    [
      "916.450",
      0,
      -128
    ],
    [
      "916.500",
      0,
      -128
    ],
    [
      "916.550",
      0,
      -128
    ],
    [
      "916.600",
      0,
      -128
    ],
    [
      "916.650",
      0,
      -128
    ],
    [
      "916.700",
      0,
      -128
    ],
    [
      "91
The key seems to be that the rig tries "waking pump" but there is "no response to wakeup"
The pump has a full battery and is sitting right next to the rig
It worked fine when I set it up a few days ago with the same pump, same rig, and oref0 0.6.2 instead of 0.7.0
djnoor
@djnoor
Nov 02 2018 03:58
I've tried rebooting the rig several times
djnoor
@djnoor
Nov 02 2018 04:05
Just noticed this:
npm list -g oref0
/home/.rootfs/usr/lib
└─┬ oref0@0.7.0-dev  -> /root/src/oref0
  └─┬ oref0@0.7.0-dev
    └── oref0@0.7.0-dev  deduped
Does this mean I am running three instances of oref0, and if so, could that be causing problems with radio interference?
Martin Haeberli
@mhaeberli
Nov 02 2018 04:47
what happens if you follow the troubleshooting steps for mmtune ?
Running "grep mmtune /var/log/openaps/pump-loop.log"
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
mmtune:
Manually preforming an mmtune and show the selected frequency of the entire scan
cd ~/myopenaps && sudo service cron stop && killall -g openaps ; killall -g oref0-pump-loop; oref0-mmtune && sudo service cron start
openaps: no process found
mmtune:
djnoor
@djnoor
Nov 02 2018 14:36
Manually performing an mmtune with the full frequency scan displayed in oref0 :
cd ~/myopenaps && sudo service cron stop && killall -g openaps ; killall -g oref0-pump-loop; OREF0_DEBUG=1 oref0-mmtune && sudo service cron start
openaps: no process found
mmtune: 2018/11/02 09:36:12 connected to CC111x radio on /dev/spidev5.1
2018/11/02 09:36:12 setting frequency to 916.550
2018/11/02 09:36:14 waking pump
2018/11/02 09:36:28 no response to wakeup
2018/11/02 09:36:28 frequency set to 916.300
2018/11/02 09:36:30 frequency set to 916.350
2018/11/02 09:36:31 frequency set to 916.400
2018/11/02 09:36:33 frequency set to 916.450
2018/11/02 09:36:34 frequency set to 916.500
2018/11/02 09:36:36 frequency set to 916.550
2018/11/02 09:36:38 frequency set to 916.600
2018/11/02 09:36:39 frequency set to 916.650
2018/11/02 09:36:41 frequency set to 916.700
2018/11/02 09:36:43 frequency set to 916.750
2018/11/02 09:36:44 frequency set to 916.800
2018/11/02 09:36:46 frequency set to 916.850
2018/11/02 09:36:48 frequency set to 916.900
{
  "scanDetails": [
    [
      "916.300",
      0,
      -128
    ],
    [
      "916.350",
      0,
      -128
    ],
    [
      "916.400",
      0,
      -128
    ],
    [
      "916.450",
      0,
      -128
    ],
    [
      "916.500",
      0,
      -128
    ],
    [
      "916.550",
      0,
      -128
    ],
    [
      "916.600",
      0,
      -128
    ],
    [
      "916.650",
      0,
      -128
    ],
    [
      "916.700",
      0,
      -128
    ],
    [
      "916.750",
      0,
      -128
    ],
    [
      "916.800",
      0,
      -128
    ],
    [
      "916.850",
      0,
      -128
    ],
    [
      "916.900",
      0,
      -128
    ]
  ],
  "setFreq": 916.6,
  "usedDefault": true
}
2018/11/02 09:36:49 disconnecting CC111x radio on /dev/spidev5.1
"Results of 0, -128 indicate NO pump communications in oref0 0.7.0 or later"
So apparently the rig is failing to communicate with the pump.
Raymond Richmond
@PedanticAvenger
Nov 02 2018 15:26
@djnoor Do you have a carelink stick you could use to verify the pump side of comms capability?
Just try a sync with the medtronic software/site?
djnoor
@djnoor
Nov 02 2018 15:28
I do. Will try that.
djnoor
@djnoor
Nov 02 2018 15:44
I used the carelink stick to upload data from the pump to Medtronic's site. Everything worked fine. So that doesn't seem to be the issue.
Scott Leibrand
@scottleibrand
Nov 02 2018 16:37
Try reseating your EB/EH on the edison/Pi?
Or try another one if you have one.
And triple check serial.
Eric
@ecc1
Nov 02 2018 16:40
Didn't @djnoor say it worked OK with master, just not dev? That's a little worrisome
Scott Leibrand
@scottleibrand
Nov 02 2018 16:59
That points to a misconfiguration/typo most likely.
djnoor
@djnoor
Nov 02 2018 17:13
Reseated EB on Edison. I don't have more than one. Triple checked serial no and other settings. Still not working. Showing same errors. Yes, these errors have occurred on the dev branch but not on master.
Scott Leibrand
@scottleibrand
Nov 02 2018 17:16
And if you go back to master does it work again?
djnoor
@djnoor
Nov 02 2018 17:18
I'll try. What is the recommended way to do that?
And what is the recommended way to install dev from scratch (a fresh flash of the edison). Could upgrading the existing files without reflashing be causing problems?
Do I run
cd ~/src/oref0 && git checkout master && git pull
npm run global-install
Scott Leibrand
@scottleibrand
Nov 02 2018 17:28
I’m not sure whether or not you can cleanly downgrade without a reflash.
djnoor
@djnoor
Nov 02 2018 17:47
@scottleibrand I'll try it and reflash if it doesn't work
djnoor
@djnoor
Nov 02 2018 18:04
Not working. I'll reflash
djnoor
@djnoor
Nov 02 2018 21:25
Reflashed master and it's working.
However, I'm going to try to reflash dev again.
djnoor
@djnoor
Nov 02 2018 23:39
Reflashed dev and I have the exact same problem with mmtune failing
So I guess I'm going to have to go back to master for now. Too bad about the master oref0 version with Autotune not parsing AndroidAPS entries correctly. I'll just have to live with that for now I guess.
djnoor
@djnoor
Nov 02 2018 23:45
I just realized that AndroidAPS is irrelevant to me since I'm not using it. I was mixing up AndroidAPS with XdripAPS. So there's no downside to downgrading to master.
Thanks for all your help guys!
Jon Cluck
@cluckj
Nov 02 2018 23:45
Which model pump are you using? And which region?
djnoor
@djnoor
Nov 02 2018 23:48
Paradigm 522, North America