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

13th
Aug 2018
dmdfreak
@dmdfreak
Aug 13 2018 06:45
Just updated an hour ago and now I'm getting this error. Right before the update, everything was fine
This message was deleted
Starting oref0-pump-loop at Mon Aug 13 01:39:02 CDT 2018 with 7 second wait_for_silence:
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 01:39:03 CDT 2018

Preflight fail. Retry 1 of preflight
Preflight fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 01:39:03 CDT 2018

Retry 2 of preflight
Preflight fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 01:39:03 CDT 2018

Retry 3 of preflight
Preflight fail. Couldn't preflight
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 42 s silence before mmtuning
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 01:39:03 CDT 2018

Listening for 42 s silence before mmtuning: Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 01:39:03 CDT 2018

mmtune: Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
No wait required.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Mon Aug 13 01:39:05 CDT 2018
wfeddern
@wfeddern
Aug 13 2018 12:54
My screen went dead yesterday on my pi HAT. Unfortunately I don't have a magic finger like @iValkou so can't get it back. Not seeing any errors on first glance based on the troubleshooting thread above, but will check again later today.
lyntonr
@lyntonr
Aug 13 2018 13:12
just had a bad error using dev branch about 11 commits behind. A pump meal bolus was missed and recorded as a correction meaning I had 10 units IOB not counted, I was able to eat a load of jelly beans in time, but this could be a really serious issue.
"""
Aug 13 20:22:00 openaps pump-loop.log: Preflight OK. Profile less than 60m old; Profile valid. Pump history update failed. Last record 2018-08-13T20:15:47+10:00
Aug 13 20:22:00 openaps pump-loop.log: Couldn't invoke_pumphistory_etc - continuing
Aug 13 20:22:00 openaps pump-loop.log: Retry 1 of refresh_pumphistory_and_meal
Aug 13 20:22:47 openaps pump-loop.log: Pump history updated through 2018-08-13T20:22:11+10:00; meal.json Skipping bolus wizard entry 0 in the pump history with 70 g carbs and no insulin.
Aug 13 20:22:47 openaps pump-loop.log: Timestamp of bolus wizard: 2018-08-13T20:22:11+10:00
"""
that 70g carbs at 8:22 DID have insulin of 10.0 units and is recorded as such on the pump.
Scott Leibrand
@scottleibrand
Aug 13 2018 15:15
How did that cause a problem if it skipped the entry and didn’t record either the carbs or the bolus?
dmdfreak
@dmdfreak
Aug 13 2018 15:34
@scottleibrand any idea what my problem could be from the above putty output?
Scott Leibrand
@scottleibrand
Aug 13 2018 15:45
Nope. What are the LEDs doing?
dmdfreak
@dmdfreak
Aug 13 2018 15:48
if that was for me Im not sure I understand the question. The LEDs are both red but thats how they always are. flicker of green sometimes
I had not done an update in almost 2 months and did it yesterday. Immediately stopped connecting to my pump after that. Im currently in the middle of a hard update now to see if that might have been the problem. I did the quick version yesterday.
dmdfreak
@dmdfreak
Aug 13 2018 16:16
that doesnt appear to have helped
Scott Leibrand
@scottleibrand
Aug 13 2018 16:31
The two LEDs next to the USB ports should not stay illuminated: they should only flash when the cc1110 is being reset before pump comms. If they stay on you need to reflash the cc1110 with ccprog.
The one between the two USB ports is power, and the one in the corner means charging.
dmdfreak
@dmdfreak
Aug 13 2018 16:41
Middle red stays on. Corner is only on during charging
Scott Leibrand
@scottleibrand
Aug 13 2018 16:50
Not relevant. Only the two to the side of the USBs matter.
dmdfreak
@dmdfreak
Aug 13 2018 17:01
Oh ok
dmdfreak
@dmdfreak
Aug 13 2018 17:10
The problem above says it's waiting a number of seconds at different times but in truth it zips right through 3 preflight checks in 2 seconds without stopping
Scott Leibrand
@scottleibrand
Aug 13 2018 17:13
try powering down the rig and reseating the Edison on the EB. if that doesn't fix it, you can export OREF0_DEBUG=1 and then run oref0-pump-loop manually to see what it's doing
dmdfreak
@dmdfreak
Aug 13 2018 17:14
Ok I'll try those. Ty
dmdfreak
@dmdfreak
Aug 13 2018 17:53
I did the export but not sure what to do with or see where to look at it. When I run oref0-pump-loop it says the same thing as it does regularly.
Scott Leibrand
@scottleibrand
Aug 13 2018 17:57
something like cd ~/myopenaps; killall -g oref0-pump-loop; OREF0_DEBUG=1 oref0-pump-loop should do it
dmdfreak
@dmdfreak
Aug 13 2018 18:03
Starting oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018 with 17 second wait_for_silence:
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018

Preflight /usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
/usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
fail. Retry 1 of preflight
Preflight /usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
/usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018

Retry 2 of preflight
Preflight /usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
/usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
fail. Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018

Retry 3 of preflight
Preflight /usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
/usr/local/bin/oref0-pump-loop: line 920: mdt: command not found
fail. Couldn't preflight
oref0-pump-loop failed. pump_loop_completed more than 15m old; waiting for 34 s silence before mmtuning
Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018

Listening for 34 s silence before mmtuning: Listening: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Mon Aug 13 13:01:05 CDT 2018

mmtune: /usr/local/bin/oref0-pump-loop: line 935: Go-mmtune: command not found
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
No wait required.
If pump and rig are close enough, this error usually self-resolves. Stand by for the next loop.
Unsuccessful oref0-pump-loop at Mon Aug 13 13:01:07 CDT 2018
same results
and again, all those waiting 34 seconds and such mean nothing. its blowing right through them without any kind waiting
Scott Leibrand
@scottleibrand
Aug 13 2018 18:10
mdt: command not found is your issue
looks like you might have updated to 0.7.0 without re-running oref0-setup?
dmdfreak
@dmdfreak
Aug 13 2018 18:12
at first I did the quick version last night. when nothing seemed to work I tried the long version but Im not sure it completed correctly. because it still gives the same proplem. Should I try the long version again?
dmdfreak
@dmdfreak
Aug 13 2018 18:18
im doing rerun of oref0 now
dmdfreak
@dmdfreak
Aug 13 2018 18:29
That did it Scott. I tried that earlier but it didnt make it all the way through. I thought it was the same problem causing that. Turns out I should have did it again. Thanks a bunch man!
Scott Leibrand
@scottleibrand
Aug 13 2018 18:33
:+1:
Christian Driver
@DriverNightscout
Aug 13 2018 18:56
Hi all, I'm reading the OpenAPS documentation for offline use, and it talks about using Capture Event. If I understand the documentation correctly, I should go to Utilities and enable Capture Event to show this menu option. I have a WW Medtronic 722 running the 2.41A firmware. I don't see Capture Event under Utilities at all. Is there something I should be doing to enable this?
Dana Lewis
@danamlewis
Aug 13 2018 18:57
see if there's a sub menu it's hiding under. if not, your model may not have it.
Zach Gohr
@zgohr
Aug 13 2018 18:58
@DriverNightscout I have a 722 and can confirm - the feature is not on this model
Christian Driver
@DriverNightscout
Aug 13 2018 19:00
@danamlewis I've had a good look around the sub-menus and I can't find it. @zgohr , thanks for confirming. I'm am preparing for a transatlantic flight, so looks like I'll need to take our chances with the A52_risk_enable setting. What's the recommended course of action if an A52 error occurs?
Dana Lewis
@danamlewis
Aug 13 2018 19:02
you'll have to rewind and reboot the pump, and the pump may double record the bolus (so OpenAPS will see more IOB than actually was delivered), but doesn't always. so key will be to be aware of what was delivered and be able to act accordingly (including switching to manual mode) if it ends up with the double record.
but to avoid an A52, just go slowly through bolus wizard during the flight: if it's just SMB'd, you have 3 minutes before it'll try to SMB again, so it might be worth checking for that or doing an easy bolus to give you time to calculate the rest of your bolus with the bolus wizard.
Christian Driver
@DriverNightscout
Aug 13 2018 19:06
@danamlewis Thanks, I'll keep an eye out. What I did last time was to enter carbs and deliver just a small amount of insulin through the bolus wizard, before following up with an Easy Bolus for the rest, to try and limit the time where Lucy was exposed to the A52 condition risk. Not sure limiting the bolus through the wizard saves anything, but my idea was to get out of the wizard as quickly as possible once carbs were entered.
Scott Leibrand
@scottleibrand
Aug 13 2018 19:07
and before SMBing, the rig will hit ESC four times to try to get you out of the bolus wizard. as long as you're not in the middle of holding down a key to dial up/down the bolus amount, and you let it ESC out, it won't A52
Dana Lewis
@danamlewis
Aug 13 2018 19:07
yup. and you could do the reverse, too - easy bolus a single time, to give you more time to do the full thing through BW, paying attention to make sure you don't get esc'd
Christian Driver
@DriverNightscout
Aug 13 2018 19:11
If I take the precaution doing Easy Bolus and paying close attention to the 4 x ESC, is it recommended to still set the A52_risk_enable variable to True?
Dana Lewis
@danamlewis
Aug 13 2018 19:11
YDMV ;)
but yes, with that behavior it's going to be less likely to A52.
Christian Driver
@DriverNightscout
Aug 13 2018 19:14
I think in this case Your Rig May Vary is more appropriate ;-) Thanks again
Dana Lewis
@danamlewis
Aug 13 2018 19:14
also true ;) :+1:
Scott Leibrand
@scottleibrand
Aug 13 2018 19:28
A52_risk_enable allows the rig to SMB after a bolus wizard entry. It doesn’t change the risk of A52, except by allowing/encouraging you to use the bolus wizard.
Jon Cluck
@cluckj
Aug 13 2018 20:21
clinician page :o
scottleibrand @scottleibrand is never sure what @cluckj means by his emoticons
Jon Cluck
@cluckj
Aug 13 2018 20:24
:laughing:
I'm excited about a clinician page!
Dana Lewis
@danamlewis
Aug 13 2018 20:27
thought you would be :) hold on, about to merge some of Scott's edits in, then will be ready for your input!
okie dokie: openaps/docs#1330
Jon Cluck
@cluckj
Aug 13 2018 20:28
:D
Dana Lewis
@danamlewis
Aug 13 2018 20:30
with the caveat: it's never going to have everything ever clinician ever wants. I tested the general outline of information with some HCPs who were asking for something like this, and it was if you give a mouse a cookie - they wanted all kinds of stuff that's detailed in the rest of the documentation, so I tried to make the emphasis here a high level summary, with pointers to the rest of the docs if they want to go into details. no need to recreate the wheel in detail separately for clinicians when it's the same exact info we use. </soapbox>
Jon Cluck
@cluckj
Aug 13 2018 20:30
hahaha
Scott Leibrand
@scottleibrand
Aug 13 2018 20:34
we could also add a lot more links to the content sections linking to the relevant pages of the main docs. so far we just have the main link to the docs...
Dana Lewis
@danamlewis
Aug 13 2018 20:35
yea, because I was thinking this is going to be what ppl want to print for their docs
and it's in the docs already with the lefthand nav, so if someone ends up viewing it online, they'll see all the left hand nav already
(I put this new page in the Resources section, and added it to the left-hand nav, too, so it'll be listed right under where Resources is now)
whoa, that first sentence is confusing for 'docs' and 'docs'. I meant HCP/clinicians ;) for that first confusing sentence, about printing
Jon Cluck
@cluckj
Aug 13 2018 20:40
docs for docs
Dana Lewis
@danamlewis
Aug 13 2018 20:40
:clap:
cluckj @cluckj whispers rename the branch docs and the page docs.MD
Scott Leibrand
@scottleibrand
Aug 13 2018 20:49
come on: it's gotta be docs.docx
Jon Cluck
@cluckj
Aug 13 2018 20:49
oh dang haha
yessss
Scott Leibrand
@scottleibrand
Aug 13 2018 20:50
lol
Jon Cluck
@cluckj
Aug 13 2018 20:50
"we love our docs"
Dana Lewis
@danamlewis
Aug 13 2018 20:50
......
;p
Dana Lewis
@danamlewis
Aug 13 2018 21:47
neat. finally found a nice tool for creating a summary TOC, helpful for pages like preferences where there's a ton of content. Now, in a drop down, there's clickable list: http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html#
Tom Boudreau
@tomasboudr
Aug 13 2018 21:49
I'm seeing times where the rig stops connecting, and from looking at the log I see it retying preflight over and over, and somewhere in there is a grep mmtune syntax issue as I see the instructions in the console repeatedly. Its resolvable by restarting, but it def gets into a loop of failure and if I'm not paying attention it can go for a a few hours of not looping
anyone else experienced this?
I'm running off a G5 and an explorer board
Dana Lewis
@danamlewis
Aug 13 2018 22:42
@tomasboudr haven't heard any reports of that. is it the exact same error over and over again? or does it vary at all?
kelseyyearick
@kelseyyearick
Aug 13 2018 23:04
Hi all still having network trouble on rasp pi. Home wifi and car hotspot have the same SSID so the rig switched over and pulled the new IP address when I got in the car, but as soon as I got to school with an open network, we stopped looping and never came back when I got home to the original SSID that was working this morning. What should my edit-wifi look like and what settings should I select in pi bakery to get back on?
Scott Leibrand
@scottleibrand
Aug 13 2018 23:04
I would recommend making the home and car networks different SSIDs, since you can't roam between them.
do you have the Pi configured to connect to open wifi networks? lots of people have issues with that, so instead only put in the networks they want it to use
kelseyyearick
@kelseyyearick
Aug 13 2018 23:07
I will do that. My School/work network is an open network, so I purchased an access point to name the network something different and password protect.
Sorry, I configured a network with the SSID known but no password.
SSID: Caliche key_mgmt: NONE
lyntonr
@lyntonr
Aug 13 2018 23:21
@scottleibrand it recorded the 70g carbs as a carb correction with no insulin which then caused very high temp basals for 90 mins until the unrecorded 10.0 units of insulin kicked in but by then an extra unwanted 6 units had been delivered as temp basal.
Scott Leibrand
@scottleibrand
Aug 13 2018 23:30
@lyntonr hmm, ok. that is concerning that the 70g carbs somehow went through but the bolus did not. what version of oref0 are you using?