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

5th
Sep 2018
John Sjolund
@sjolundjohn
Sep 05 2018 04:08
@benfiscal you are right that the hardware you have will not support Loop/OpenAPS or AndroidAPS unfortunately. Perhaps you can ask your clinic if they have any old demo pumps?
Giuseppe
@giupo
Sep 05 2018 08:55

I have my data squished in NS, I knew what to do: but when I opened my NS admin page I found out that the data blamed to be in the future wasn't really, and deleting it didn't fix the issue.

I checked my heroku app date, and it turns out to be correct

$ heroku run -a #### date
Running date on####... up, run.3469 (Free)
Wed Sep  5 10:45:05 CEST 2018

Which is correct; No matter how I hardly try, the NS site still present itself as having future data. Has anyoune run over my same problem? I have papertrail activated on the NS site, and the logs show a timestamp in the past (or different timezone?)

imagelogs

sorry, wrong markdown, here's . the NS logs: note the timestamp:
Sep 05 01:56:00 ##### app/web.1: tick 2018-09-05T08:56:00.098Z 
Sep 05 01:56:01 ##### app/web.1: searching treatments q { find: { created_at: { '$gte': '2018-08-28T08:56:01.101Z' } }, 
Sep 05 01:56:01 ##### app/web.1:   sort: { created_at: 1 } } 
Sep 05 01:56:02 ##### app/web.1: Load Complete: 
Sep 05 01:56:02 ##### app/web.1:      treatments:207, profiles:1, devicestatus:1030, tempbasalTreatments:152, tempTargetTreatments:1 
Sep 05 01:56:02 ##### app/web.1: all buckets are empty
Sacha M
@coolestkidsever
Sep 05 2018 10:41
@ecc1, @juehv - unsure why - but it seems pumps not communicating for the last 4 hours (all looks ok) - cgmhistory shows below (4 hours ago)

2018/09/05 22:39:50 retrieving CGM history since 2018-09-05 16:39:50
2018/09/05 22:39:51 connected to CC111x radio on /dev/spidev0.0
2018/09/05 22:39:51 MEDTRONIC_PUMP_ID environment variable is not set
Giuseppe
@giupo
Sep 05 2018 11:05

AFAIK MEDTRONIC_PUMP_ID is set in oref0-pump-loop.sh via

export MEDTRONIC_PUMP_ID=`grep serial pump.ini | tr -cd 0-9`

make sure you have that line in oref0-pump-loop.sh, make sure you have the serial in the myopenaps/pump.ini.

if you miss the export MEDTRONIC_PUMP_ID in oref0-pump-loop.sh but you are quite sure you are on the dev branch, I would re-run the oref0-setup
@coolestkidsever the code that warns you about the MEDTRONIC_PUMP_ID is here : https://github.com/ecc1/medtronic/blob/master/pump.go#L25 so I guess even an empy string (being set, although) raises that "not set" warning).
Sacha M
@coolestkidsever
Sep 05 2018 11:27
Weirdly it has “worked” (somewhat haltingly) since setup, even though it returns this error, it just takes 20-30mins to loop and therefore throws stale data alarms..
Sacha M
@coolestkidsever
Sep 05 2018 11:40
@juehv - i think you hit the nail on the head.. your comment about underclocking the battery .. I “un” underclocked the battery and the loop only took 7 minutes, not 20!!thanks, getting closer to getting this working..:)
Jens Heuschkel
@juehv
Sep 05 2018 12:32
@coolestkidsever I'm working on this issue ... try to find out why it takes so long on the mdt path ... I figured one problem already: when the pump is receiving a cgm value it is already between 0 and 3 minutes old. But for my taste, it takes too long until the values are used. My display usually shows between 7 an 12 minutes as cgm age.
Bob Duerr
@Duer0049
Sep 05 2018 13:53
Good Morning Everyone, My wife just switched over to the Dexcom G6 and we updated everything accordingly, but I cannot get the BG reading into Xdrip. We are connected via bluetooth, all the setting look correct, we clicked the box stating that we are on a G6. Anyone else have any success on a G6?
Zach Gohr
@zgohr
Sep 05 2018 13:55
@Duer0049 Yeah successfully on day 14 of G6 right now. But I don’t have much advice - we just clicked the checkbox, entered the transmitter and sensor id’s and things just picked up without doing anything else
Eric
@ecc1
Sep 05 2018 14:10
@coolestkidsever you need to set the pump id in the environment of the shell in which you're running cgmhistory:
$ export MEDTRONIC_PUMP_ID=nnnnnn # replace this with the numeric part of the pump serial number
$ cgmhistory
ideeagit
@ideeagit
Sep 05 2018 14:25
@danamlewis, hmmm i checked autotune now and saw that
it just takes the wrong ISF (100, i have 64 in my pump) and a wrong carb ratio (25, i have 10-16 g in my pump). 100 and 25 seem like default values maybe?
But even when i switched off autotune it took the ISF value of 100 in the Pump-Loop log.
Dana Lewis
@danamlewis
Sep 05 2018 14:33

@ideeagit must be multiple values in your pump, then. Autotune uses the one at midnight-ish to tune from. I would quadruple check your bolus wizard isf settings for all hours; sounds like there is a value in there (100) that you don't want to be using. That is worth deleting or editing so it doesn't confuse you.

In addition to disabling Autotune you'd also need to delete the Autotune log files before it would switch to using pump only isf for that time

ideeagit
@ideeagit
Sep 05 2018 16:04
@danamlewis, there was unfortunately really no value of 100 in the bolus wizard of my pump, but i made now multiple values with my desired value at midnight. Can i run autotune manually or should i just wait till 4 am when it runs automatically?
Scott Leibrand
@scottleibrand
Sep 05 2018 16:18
you can run it manually. I would first rm ~/myopenaps/autotune/*.json and rm ~/myopenaps/settings/autotune.json
Travis Cannell
@diabeticpilot
Sep 05 2018 20:37
Hey - On a fresh install of dev I'm having this error on an Edison, anyone seen this? Looks like the radio is failing
Starting oref0-pump-loop at Wed Sep  5 13:27:04 PDT 2018 with 1 second wait_for_silence:
Waiting up to 4 minutes for new BG: ls: cannot access /tmp/pump_loop_completed: No such file or directory
mmeowlink.exceptions.CommsException: Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?

Radio check failed. mmeowlink.exceptions.CommsException: Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?
Listening for 40s silence before mmtuning: ..............................................................................................................................................................................................................................................
Adi Barilan
@Adidushi
Sep 05 2018 20:45

I've been having this problem for a while on a pi zero w/ hat, dev branch:
it seems openaps is running from root instead of /root/myopenaps as shown by:
oref0-mmtune: This script should be run from the myopenaps directory, but was run from /root which does not contain openaps.ini.

I reflashed my pi, it worked for a bit then it went back to this.
Any ideas?

I've been getting that error along with missing file errors in my log file for every file
alimhassam
@alimhassam
Sep 05 2018 20:50
@diabeticpilot it doesn't look like you fully installed the dev branch
Travis Cannell
@diabeticpilot
Sep 05 2018 20:50
hmmm ok i'll try re-running setup
Don't forget the npm command
@Adidushi also make sure you follow all instructions on above page to install dev branch
alimhassam
@alimhassam
Sep 05 2018 21:02
@Adidushi also check if you have the $HOME environment variable correctly set
Adi Barilan
@Adidushi
Sep 05 2018 21:02
How do i check that?
and how do i set it
alimhassam
@alimhassam
Sep 05 2018 21:03
echo $HOME
Adi Barilan
@Adidushi
Sep 05 2018 21:05
What should it be?
alimhassam
@alimhassam
Sep 05 2018 21:07
Sorry I was just trying to think of reasons why your directory might be set incorrectly
Adi Barilan
@Adidushi
Sep 05 2018 21:10
No worries
alimhassam
@alimhassam
Sep 05 2018 21:11
If home is set to root directory should be good. I would try to follow instructions to install dev on page I linked above step by step precisely
Don't pass a dir parameter to oref0 setup
Let it figure it out on its own
Adi Barilan
@Adidushi
Sep 05 2018 21:32
Same errors
alimhassam
@alimhassam
Sep 05 2018 21:35
Did you reinstall crontab?
Adi Barilan
@Adidushi
Sep 05 2018 21:36
Yup
alimhassam
@alimhassam
Sep 05 2018 21:36
Can you save all your output somewhere so I can see? Hide sensitive info
Travis Cannell
@diabeticpilot
Sep 05 2018 22:10
so I re-ran setup and am still getting this error on dev. it worked for 2-3 loops and then went back to this message. Any ideas? Could the x-drip js fakemeter code be doing something to the radio? I don't see how it could work for a few loops them stop
Starting oref0-pump-loop at Wed Sep  5 15:02:03 PDT 2018 with 29 second wait_for_silence:
Waiting up to 4 minutes for new BG: .glucose.json newer than pump_loop_completed
mmeowlink.exceptions.CommsException: Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?

Radio check failed. mmeowlink.exceptions.CommsException: Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?
Listening for 40s silence before mmtuning: ....................................................................................................................................................................
Travis Cannell
@diabeticpilot
Sep 05 2018 22:20
another thing is that I ran the master branch with a manual install of Logger... and then when I installed dev, I picked xdrip-js as the bg source so not sure if that stepped on the other installation or something strange happened
alimhassam
@alimhassam
Sep 05 2018 22:29
@diabeticpilot did you run the npm run global-install step after checking out the dev branch?
Travis Cannell
@diabeticpilot
Sep 05 2018 22:30
yes
alimhassam
@alimhassam
Sep 05 2018 22:30
seem like it's still trying to use the old communications libraries
type cd ~/src/oref0 && git status
Travis Cannell
@diabeticpilot
Sep 05 2018 22:33
i switched back to Master to fix this...
root@bearpanks:~# cd ~/src/oref0 && git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
alimhassam
@alimhassam
Sep 05 2018 22:34
ok, does it fix it?
that mmeolink exception comes from the master branch, as the dev branch has different types of errors.
Travis Cannell
@diabeticpilot
Sep 05 2018 22:39
hmmmm no, it keeps tripping on the radio
I've got to run but perhaps tonight I'll try a re-flash and fresh install again and then go right to branch and run the xdrip-js setup from there.
alimhassam
@alimhassam
Sep 05 2018 22:41
ok, probably a small step was forgotten
if your master branch is working, then you might not need a full reflash
Travis Cannell
@diabeticpilot
Sep 05 2018 22:41
strange... it ran fine all last night on Master + Logger
alimhassam
@alimhassam
Sep 05 2018 22:41
just the update steps.
Travis Cannell
@diabeticpilot
Sep 05 2018 22:41
this only started when I changed to Dev branch to get the fakemeter stuff
alimhassam
@alimhassam
Sep 05 2018 22:41
the old radio code, and the radio code on the dev branch are not compatible.
(at least on the edison, not sure about the pi)
so you need to have everything on the new radio code, or nothing at all.
if you start using fakemeter, but are still running oref0-pump-loop on the master branch, you'll get these issues.
Travis Cannell
@diabeticpilot
Sep 05 2018 22:43
ahhh
so I should do a re-flash and then NOT install the master branch. Switch to dev, then install there
alimhassam
@alimhassam
Sep 05 2018 22:50
yep