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

20th
Jan 2019
renegadeandy
@renegadeandy
Jan 20 00:04

Just added another feature:

5/Added a persisted log file for xDripAPS. Each log will be 2 megabytes and there is a 2 file rollover scheme to be able to track a sensible amount of historical logs to assist with problem determination.

Eric
@ecc1
Jan 20 00:29
It's probably better to take this to a channel related to xdrip development
Scott Leibrand
@scottleibrand
Jan 20 00:31
Agreed. Also consider using logrotate for log rollover.
renegadeandy
@renegadeandy
Jan 20 01:13
@scottleibrand I have implemented logrotate :) There is no channel for xDripAPS development, and the xDrip channel is perhaps not the home for this. xDripAPS does need a home, but its closer to openaps than xDrip in my opinion, considering it runs entirely on the openaps rig, and was built with no other purpose in mind but for running openAPS in an offline state.
Scott Leibrand
@scottleibrand
Jan 20 01:19
True. Unfortunately it doesn’t have any active developers that I know of, unless someone speaks up here. So if you think you have a fix, feel free to PR it.
renegadeandy
@renegadeandy
Jan 20 01:20

I am going to :)

I don't think the maintainer uses openaps anymore, which is likely why this has happened. What happens in that case? Would we shift to a new repo and move on from there?

I understand there are no active developers, but since this is my first go at helping the openaps community, i like the idea of having a place to document my thoughts, progress, ask for advice etc - which is what you have seen here. If that is ok, I will continue :) More as a way to triple check my thinking and logic and to make sure I integrate neatly into the wider aps project.
Jeremy Cunningham
@jpcunningh
Jan 20 01:29
@renegadeandy, we use xDripAPS with Lookout and Logger without issues... the code we use to sent glucose to xDripAPS in Lookout is:
  const secret = process.env.API_SECRET;

  const optionsX = {
    url: 'http://127.0.0.1:5000/api/v1/entries',
    timeout: 30 * 1000,
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'API-SECRET': secret,
    },
    body: entry,
    json: true,
  };

  /* eslint-disable-next-line no-unused-vars */
  request(optionsX, (err, response, body) => {
    if (err) {
      error('error posting SGV to xDripAPS: ', err);
    } else {
      log(`uploaded SGV to xDripAPS, statusCode = ${response.statusCode}`);
      debug('Entry:\n%O', entry);
    }
  });
I know it works with token secrets. I am not sure I've tested it with just the API-SECRET instead of a token.
Jeremy Cunningham
@jpcunningh
Jan 20 02:06
Looking at the code, I'm not sure how API-SECRET header gets received as Api_Secret, though...
Tim Street
@tim2000s
Jan 20 02:22
@PedanticAvenger - that’s a limitation of the phone Bluetooth stack. Some phones will maintain a tether with no cellular signal while others don’t.
John Sjolund
@sjolundjohn
Jan 20 02:27
@scottleibrand Was the earlier comment to me about the mmtune reporting RSSI?
Eric
@ecc1
Jan 20 02:31
@renegadeandy @jpcunningh I'm pretty sure that the Python code makes headers-with-hyphens available also as headers-with-underscores, for convenience in using them as Python field names. Seems to be done in the Werkzeug library inside Flask. Have you verified that it's in the received HTTP header but not being retrieved by the xdripaps code?
Jeremy Cunningham
@jpcunningh
Jan 20 02:31
Thanks, @ecc1! I was coming to the same conclusion. :smile:
renegadeandy
@renegadeandy
Jan 20 03:03
@jpcunningh are you saying that xDripAPS handles tokens? I am not sure how that can be possible when looking at the code.
@ecc1 ahhh, that makes more sense if the python code automatically makes headers-with-hyphens availble as headers with underscores. Strange though, not sure why thats helpful (but im not a python regular)/
Jeremy Cunningham
@jpcunningh
Jan 20 03:05
@renegadeandy, yes, but rather than passing the token in as a HTTP query string like Nightscout requires, Lookout passes the token to xDripAPS in the header.
renegadeandy
@renegadeandy
Jan 20 03:12
@jpcunningh can you point out where in the xDripAPS code that it handles the token, as opposed to hashed password?
Jeremy Cunningham
@jpcunningh
Jan 20 03:13
It's the location you pointed out above.
It says hashed, but it just matches whatever is sent against the API_SECRET environment variable.
So, if the API_SECRET environment variable is a token, and the header Api_Secret is a token... it works.
Jeremy Cunningham
@jpcunningh
Jan 20 03:20
Can you configure xDrip+ to send the token in the Api_Secret header?
renegadeandy
@renegadeandy
Jan 20 03:22
Not sure....dont think so?
Jeremy Cunningham
@jpcunningh
Jan 20 03:25
do you use xDrip+ to upload to Nightscout and send it to xDripAPS?
renegadeandy
@renegadeandy
Jan 20 03:26
yes
and im pretty certain.....that it doesn't support tokens
there is no place i can see to add a token
Jeremy Cunningham
@jpcunningh
Jan 20 03:27
You may be able to add the token to the URL as a query string.
does the URL you put in xDrip+ contain /api/v1/entries.json or is it just the base URL like http://appname.herokuapp.com?
renegadeandy
@renegadeandy
Jan 20 03:32

I have verified what you said about the hyphens and underscores @ecc1 ty.

@jpcunningh just the base bath

Jeremy Cunningham
@jpcunningh
Jan 20 03:41
I'm digging around some more and found this in the OpenAPS setup info:
definitely doesn't appear to support tokens...
Jeremy Cunningham
@jpcunningh
Jan 20 03:50
Looking at the xDrip+ code, it pulls the API-SECRET out of the user field and puts it in the header instead.
to support tokens, the code needs to determine if the API-SECRET is a token and if it is put it in a query string instead of the header.
Once that's done, xDripAPS needs to be modified to accept the token in as a query string instead of only in the header field.
renegadeandy
@renegadeandy
Jan 20 03:53
yes, but currently xDrip+ doesn't support the query string token correct? I agree with what would need to happen on xDripAPS, but thats not what I am adding :)
If xDrip+ adds support for tokens, ill happily add the code to xDripAPS to support that integration
straykatz
@straykatz
Jan 20 03:54
Autotune question: Why do I get two different recommendations when I run autotune for the same start and stop dates on the same Nightscout account, on the same pump on two different rigs with the same preferences set? I am puzzled about this ... I actually deleted the autotune directories on both rigs and reran it - the results are now closer together but still different. Why is that?
Jeremy Cunningham
@jpcunningh
Jan 20 03:55
I agree, it does not appear that xDrip+ supports tokens.
Dana Lewis
@danamlewis
Jan 20 04:00
@straykatz probably because it still had the propagated profile copied elsewhere and used that for starting tune
straykatz
@straykatz
Jan 20 04:05
Ah. OK. thank you, Dana. they are close enough, soI am not worries about it. I started rerunning them from day 1 because the basal rate suggestions were becoming much lower than when I started - as in, 1/2 and less. I am entering all carbs into NS to the best of my ability, and autotune kept down-regulating my basals until I was had several basal rates around 0.3 IU/hr ... Keeping an eye on this.
straykatz
@straykatz
Jan 20 04:11
The re-run from day 1 of NS data gives now recommendations of around 0.5 IU/hr. I started out with a total daily basal amount of around 18 IU.
renegadeandy
@renegadeandy
Jan 20 04:11
Thanks for confirming @jpcunningh
Would you be interested in helping me test my fork?
Jeremy Cunningham
@jpcunningh
Jan 20 04:12
I can help test xDripAPS, but I unfortunately have to live with an iPhone so I can't help with xDrip+.
Scott Leibrand
@scottleibrand
Jan 20 04:43
@sjolundjohn if I don’t tag or address anyone, I’m either responding to the message immediately preceding mine, or making/asking a general statement/question of everyone.
@straykatz you might need to try the autotune flag to categorize UAM as basal.
straykatz
@straykatz
Jan 20 04:46
@scottleibrand Why, considering I input the carbs?
Scott Leibrand
@scottleibrand
Jan 20 04:47
We saw something similar and changed that on ours. I’ll probably write a conditional that does so automatically if it has two or more carb entries for the day or something like that, so the UAM detection still works for people who don’t announce carbs, but it assumes people who do announce carbs announce them consistently.
If you input carbs, and don’t skip any, then if it detects unannounced BG rises it should attribute those to too-low basals not to missed meal announcements.
straykatz
@straykatz
Jan 20 04:48
OK, thank you.
renegadeandy
@renegadeandy
Jan 20 04:54
@jpcunningh no problem. I won't be updating xDrip+ imminently.
Ill let you know when my new update is reading for testing
Garrett Webb
@garetis
Jan 20 05:01
I'm getting some "no space left on device" in my error messages. Is there an easy way to find out what the bottle neck is or how to clear it out?
Scott Leibrand
@scottleibrand
Jan 20 05:02
There’s a troubleshooting page in the docs for disk full issues.
Garrett Webb
@garetis
Jan 20 05:05
Great, thanks
Garrett Webb
@garetis
Jan 20 05:31
I ran through the disk troubleshooting. I deleted most of the logs but it took it down to 97%. Looks like I have a file 'dev/mmcblk0p10' that is 1.3G? I tried deleting it but it didn't seem to change anything. Does that file mean anything to anyone, and how much disk space should I realistically have to run NCDU?
Garrett Webb
@garetis
Jan 20 05:45
root@garrett2:/# df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root        1.4G  1.3G   66M  95% /
devtmpfs         481M     0  481M   0% /dev
tmpfs            481M     0  481M   0% /dev/shm
tmpfs            481M  6.7M  474M   2% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs            481M     0  481M   0% /sys/fs/cgroup
tmpfs            481M   80K  481M   1% /tmp
/dev/mmcblk0p7    32M  4.8M   28M  16% /boot
/dev/mmcblk0p10  1.3G  888M  403M  69% /home
tmpfs             97M     0   97M   0% /run/user/0
I was able to install NCDU and run that, and used it to knock off an additional 2% with the other logs, but wasn't able to track down that /dev/mmbclk0p10 file. Any thoughts?
jgslade
@jgslade
Jan 20 05:52
/dev/mmbclk0p10 is the partition for the /home folder which is where the regular user files are kept
It looks like there are 3 partitions that aren't tmpfs: /dev/root which is 1.4GB mounted as /, which is where most everything is stored. /dev/mmcblk0p7 mounted as /boot, which is where the boot files are kept, then /dev/mmbclk0p10.
Your /dev/root or / is 95% full, which is why you are getting the out of space errors.
Garrett Webb
@garetis
Jan 20 06:02
Can I delete /dev/mmcblk0p7 safely? If I copied everything onto a larger SD card, would that work, or is that unfeasible and I need to address the specific files?
jgslade
@jgslade
Jan 20 06:06
They aren't files, the are parts of the sdcard set aside for a specific use. The card is broken into 3 pieces. Like you have 3 different drives in the system instead of the one.
Are you using a pi or an edison?
Martin Haeberli
@mhaeberli
Jan 20 06:11
So i tried to test mmtune after ‘service cron stop ; killall -g oref0-pump-loop’ but it complained that the radio was in use. Suggestions?
jgslade
@jgslade
Jan 20 06:16
@garetis run
fdisk -l  /dev/mmcblk0
This might help with locating where the space is being taken up
du -bsh /*
renegadeandy
@renegadeandy
Jan 20 06:28

If anyone would like to help me test my most recent updates to xDripAPS, please can you clone my repo replacing your existing installation: https://github.com/renegadeandy/xDripAPS

Changes are:

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 value for Nightscout, and would like to be able to use the basic environment variable based password for their xDrip+ integration with xDripAPS. If API_SECRET_xDripAPS is defined, we will use that for authentication instead of 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.
5/Added a persisted log file for xDripAPS. Each log will be 2 megabytes and there is a 2 file rollover scheme, meaning at maximum there will be a current working log, and 2 historical log files, to be able to track a sensible amount of historical logs to assist with problem determination. The log is in /var/log/openaps/xDripAPS-{date created}.log
7/Bugfix where we now perform a lowercase comparison meaning that if case between stored API_SECRET variables and value passed into the call are compared, we do it in a case insensitive manner.
6/If you are using the new API_SECRET_xDripAPS environment variable, you will now need to alter your crontab to include the API_SECRET_xDripAPS environment variable. Use crontab -e and add it under your existing API_SECRET entry.

@jpcunningh

Martin Haeberli
@mhaeberli
Jan 20 06:53
Somehow, even though pump comms now works, I’m missing getting the enact on pump settings on some of my spare rigs - I just updated all to the latest dev (copied preferences.json first to backup, then did install, then copied back)
Garrett Webb
@garetis
Jan 20 07:38

@jgslade Thanks. I'm running Edison. The highest ones from the second line were:

788M    /home
704M    /root
355M    /sys
332M    /var
209K    /proc
52M     /lib

There were a couple directories it couldn't access, but I assume that's fine. Even though I cleared up a little space, loop still isn't working. I'll play around a little more tomorrow, see if I can get anywhere and if I have to reflash again, so be it.

renegadeandy
@renegadeandy
Jan 20 08:06
image.png
@garetis odd - my df -h output is very similar yet yours has a higher percentage used....
@garetis but your /root has 500m more than mine
my var has more than yours by 200m etc
:)
tuzoenduro
@tuzoenduro
Jan 20 08:13
hi, finished setting up my rig and it does not upload to NS, the pill is empty and I get the impression that the rig is never able to communicate with NS.. I am testing without the pump plugged into me and I saw that if I bolus the rig recognizes it, but other from that I do not see anything... can someone help?
tuzoenduro
@tuzoenduro
Jan 20 08:22

I get lots of this :Starting oref0-pump-loop at Sat 19 Jan 15:28:06 CET 2019 with 24 second wait_for _silence:
Waiting up to 4 minutes for new BG: First loop: not waiting

Listening for 24s: .No interfering pump comms detected from other rigs (this is a good thing!)
Continuing oref0-pump-loop at Sat 19 Jan 15:28:33 CET 2019
Preflight fail. Retry 1 of preflight
Preflight OK. Old settings: jq: error (at settings/pumpprofile.json.new:1): Cann ot index number with string "current_basal"
Invalid pumpprofile.json.new after refresh
-rw-r--r-- 1 root root 3 Jan 19 15:29 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 "cur rent_basal"
Invalid profile.json.new after refresh
-rw-r--r-- 1 root root 3 Jan 19 15:29 settings/profile.json.new
Profile valid. Pump history updated through 2019-01-19T14:33:32+01:00 with 0 new records; meal.json Could not parse input data: { Error: ENOENT: no such file o r directory, open 'settings/profile.json'

that cycles on and on... could anyone help?
tuzoenduro
@tuzoenduro
Jan 20 08:27
did I bork my setup?
Garrett Webb
@garetis
Jan 20 08:38
@renegadeandy Oh yeah, very peculiar! Thanks for sharing. Maybe smarter people than I would know what it might be. I'm getting some other errors -- some that are usually there (could not parse monitor/carbhistory.json) and others new. I'm not sure if it's because I deleted the logs, so we'll see how it is in the morning.
Jeremy Cunningham
@jpcunningh
Jan 20 13:21
@renegadeandy, how will the log rotation built into your updated xDripAPS interact with the system logrotate?
Jeremy Cunningham
@jpcunningh
Jan 20 13:36
I'm running successfully with Lookout.
jgslade
@jgslade
Jan 20 15:39

@garetis Since /home has it's own partition we don't need to worry about that one. It looks like the majority of the space is being used by the /root folder so run

du -bsh /root/*

so we can see what in the /root folder is taking up so much space.

renegadeandy
@renegadeandy
Jan 20 16:33
@jpcunningh That's fantastic news that my version doesn't regress anything that you had working before
Do you know what the system logrotate is? I am not absolutely sure tbh....
Eric
@ecc1
Jan 20 16:35
@renegadeandy "man logrotate"
renegadeandy
@renegadeandy
Jan 20 16:55
@ecc1 that doesn't tell me where the configuration files used for openaps are held
do you know where they are held?
Eric
@ecc1
Jan 20 17:00
quick grep in the openaps source tree finds oref0/logrotate.openaps, /etc/logrotate.conf, /etc/lograte.d/openaps
renegadeandy
@renegadeandy
Jan 20 17:15
ok....
it seems openaps' logrotate takes care of everything, so my code is surplus to requirements!
It wont do any harm though
I would'nt have thought
renegadeandy
@renegadeandy
Jan 20 17:51

my log sits within /var/log/openaps so therefore will be rotated daily and it would keep up to 30 compressed files according to the openaps logrotate.

I might remove my log rotator in that case to avoid having conflict, @scottleibrand sensible idea?

Dave9111
@Dave9111
Jan 20 18:06
Using Dexcom G5, Openaps with Nightscout master as of Dec 4th, 2018...
When Dexcom goes down for whatever reason, the data becomes old on Nightscout, Openaps keeps looping although it stops doing anything.
No alarms occur - I have Pushover setup.. but I don't see any alarms in Nightscout for old BG data ??? Please tell me I am missing them! :-)
Dave9111
@Dave9111
Jan 20 18:31
Is this the alarm setting ?? ALARM_TIMEAGO_URGENT
renegadeandy
@renegadeandy
Jan 20 18:42
I am getting a series of these errors:
Starting oref0-pump-loop at Sun Jan 20 12:35:02 CST 2019 with 8 second wait_for_silence:
Retrying without waiting for new BG
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. Refreshed pumphistory and meal.json
Checking pump clock: "2019-01-20T12:30:14-06:00" is within 90s of current time: Sun Jan 20 12:37:41 CST 2019
Pump clock is more than 55s off: attempting to reset it
Waiting for ntpd to synchronize... OK!
Setting pump time to Sun Jan 20 12:37:41 CST 2019
IndexError: bytearray index out of range
Error: pump clock refresh error / mismatch
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 Sun Jan 20 12:37:51 CST 2019
which index is causing the problem ?
Id like to help improve the stability of these types of errors
Dave9111
@Dave9111
Jan 20 18:52
Error: pump clock refresh error / mismatch
My interpretation is that "IndexError" occurred and that was a symptom of the pump clock not being refreshed properly... and that appears to be due to a comm issue... at least that is the suggestion.
The "IndexError:" message is probably not needed. If lines like that are going to be logged, it would be nice to have the line number and file name shown where the exception occurred. Otherwise, what is the point of logging an IndexError ??
renegadeandy
@renegadeandy
Jan 20 18:57
@Dave9111 exactly!
renegadeandy
@renegadeandy
Jan 20 19:06
Why is it a common error though
Dave9111
@Dave9111
Jan 20 19:08
My daughter uses Openaps on an Edison rig. If the rig is more than maybe 8 feet from the pump, it can have comm errors. The range is just not great.
Also, I have read that if your pump battery is low (at least Medtronic) it can shutdown RF comms... and I think I have seen that occur before.
renegadeandy
@renegadeandy
Jan 20 19:40
Yeah, but i am never more than 8ft from the pump when this is happening
Garrett Webb
@garetis
Jan 20 20:29

@jgslade Thanks. Here were the standouts from /root/

301M    /root/dead.letter
232M    /root/Lookout
127M    /root/src

I went through Lookout and the standouts there were

116M    /root/Lookout/node_modules/unicode-5.2.0
68M     /root/Lookout/node_modules/phantomjs-prebuilt
7.2M    /root/Lookout/node_modules/chart.js

I was unable to access /root/dead.letter. The errors coming off the loop are now Error: bad basalprofile_data: and meal.json and Could not parse input data: SyntaxError: /root/myopenaps/monitor/glucose.json: Unexpected end of JSON input.

Scott Leibrand
@scottleibrand
Jan 20 22:08
@renegadeandy yeah, no sense duplicating the log rotation.
jgslade
@jgslade
Jan 20 23:25
@garetis is dead.letter a directory or a file? How did you try to access it?
Dead.letter is typically failed email messages and sometimes it is system notices. 300 MB is kinda a lot.
jgslade
@jgslade
Jan 20 23:36
I don't use logger, so don't know if that usage is typical or if there is something you can delete safely