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

30th
Sep 2017
Dana Lewis
@danamlewis
Sep 30 2017 00:01
the other issue yesterday was hotspot seemingly killed g5 ability. but not being a g5 user, don't feel like I can drill down on whether that's just related to known g5/bluetooth stinkiness or anything reproducible
live4sw
@live4sw
Sep 30 2017 00:10
Wow, approvals are fast and furious lately, Fiasp was just approved!
Dana Lewis
@danamlewis
Sep 30 2017 00:10
@live4sw yup! exciting, even if it's not available in US until late dec/early q1, there are other places to acquire it from ;) for those interested
live4sw
@live4sw
Sep 30 2017 00:11
I was extremely excited about it but have cooled a lot on it after reading about the random resistance issues and need to change sites every 2 days...but still...seems like it could be huge.
Dana Lewis
@danamlewis
Sep 30 2017 00:12
@live4sw not sure site changes @ 2 days is universal. I haven't experienced that. but yea - important to have reasonable expectations. won't work perfect for everyone.
jaylagorio
@jaylagorio
Sep 30 2017 00:18
@scottleibrand I can't use the app because they don't make a compatible version for my phone
And I use the receiver because I can't have my phone or rig with me during the work day, so having the receiver by itself or hooked up to the rig simplified continuity
@danamlewis Yeah, that was someone with an iPhone having issues - I'm not having any issues related to the Dexcom stuff or the phone and I know the data's getting to the rig
@scottleibrand If I used the g4-local-only option would the rig shuttle data to Nightscout by itself?
Scott Leibrand
@scottleibrand
Sep 30 2017 00:23
@jaylagorio no, that's g4-upload (and only if you have a G4 receiver)
sounds like you want to build a g5-upload option
should be doable, you're just the first person with a use case that requires it
jaylagorio
@jaylagorio
Sep 30 2017 00:24
That does sound like what would work for me
OK, I'll keep that in mind going forward
Scott Leibrand
@scottleibrand
Sep 30 2017 00:24
happy to help you put it all together and work it into oref0-setup if you like
jaylagorio
@jaylagorio
Sep 30 2017 00:24
I think that's the correct solution as opposed to my cron job ns-upload
Yeah, I think that would be good, I just need to get the time together. As much as I wish it was it probably won't be this weekend.
Dana Lewis
@danamlewis
Sep 30 2017 00:41
@jaylagorio ah, thanks for clarifying phone usage
gregorschlump
@gregorschlump
Sep 30 2017 00:43
So am I right? The DANA Diabecare R is usable with OpenAPS?!
Dana Lewis
@danamlewis
Sep 30 2017 00:43
with AndroidAPS (so the OpenAPS algorithm on Android phones), yes :)
gregorschlump
@gregorschlump
Sep 30 2017 00:44
@danamlewis Thanks a lot for the second time, Dana ;)
Dana Lewis
@danamlewis
Sep 30 2017 00:45
:+1: thanks in return for properly capitalizing the pump name :D
gregorschlump
@gregorschlump
Sep 30 2017 00:50
I'm going crazy with all this synonyms and abbreviations... better to point out exactly what I try to say/ask ;)
Dana Lewis
@danamlewis
Sep 30 2017 00:56
:+1:
Scott Leibrand
@scottleibrand
Sep 30 2017 02:55

@/all Have something we'd like more input and particularly testing on from folks running dev: openaps/oref0#685

It's a fairly major change, so before we merge it to dev we'd like to get testing from some folks who are still manually bolusing for meals to see if the rest of the new code in dev makes it possible to remove bolus snooze, or if there are still any corner cases we need to deal with.

br
@brmccollum
Sep 30 2017 05:02
Wanted to update you guys on the two 712's radio issue. I received a 715 yesterday and was able to switch over to it within 15 minutes. Been looping on oref0 for the past 30 hours. Thanks again for your help. @scottleibrand @danamlewis and others.
Paul Dickens
@thebookins
Sep 30 2017 05:02
Screen Shot 2017-09-30 at 14.58.13.png
I wonder if someone could help me understand some algorithm behaviour. We're seeing a lot of zero temping with oref1 and subsequent microbolusing that doesn't necessarily replace what was removed with the zero temp. The pic above shows a sustained rise and IMO it would have worked better without the zero temp. Is the algo not seeing the effect of the declared carbs? Any tips on how to tweak the behaviour?
Scott Leibrand
@scottleibrand
Sep 30 2017 05:04
@thebookins are you using the dev branch? have you been running autotune since we updated it to do CR autotuning?
Paul Dickens
@thebookins
Sep 30 2017 05:06
@scottleibrand we are using dev roughly equal to 0.5.3. haven't had much success with autotune, despite much trying, due to fast-changing needs and a carb ratio that varies through the day.
Looking for some understanding at the moment.
In these circumstances, is it right to expect the microboluses to equal or exceed what was removed with the zero temp?
Too simplistic?
Paul Dickens
@thebookins
Sep 30 2017 05:14
In the middle of that zero temp section, the pill says something like insulin req 0.3, setting zero temp, microbolusing 0.1. That would seem to me to suggest that we are setting zero temp for safely, but we will deliver that amount (i.e. the current basal rate for 30 mins) plus the 0.3 needed as microboluses. Make sense?
Scott Leibrand
@scottleibrand
Sep 30 2017 05:27
0.5.3 autotune had a bias toward too-high ISF and CR. that caused it to think your BG would end up lower than target, reducing the size of SMBs and extending zero temps. 0.6.0 dev autotune calculates CR directly, and fixes those biases, so it usually ends up predicting the eventual effects of carb absorption much more accurately. 0.6.0 also has a bunch of improvements around predicting the timing of carb absorption, which also help a lot with that.
if you're unhappy with the SMB outcomes in 0.5.3, I would suggest you try 0.6.0 dev on one of your rigs, with autotune enabled to run nightly: you should see quite a few differences.
Paul Dickens
@thebookins
Sep 30 2017 05:30
OK thanks @scottleibrand, we will dive into 0.6.0.
What would you suggest re autotune and different CRs through the day? We have tried having one CR and adjusted basal to compensate, but it seems we genuinely need a lower carb ratio for breakfast.
I know there's an issue for different CRs with autotune, but it's not clear to me how you might optimise for basal that varies through the day, as well as CR and potentially ISF that vary through the day too.
Scott Leibrand
@scottleibrand
Sep 30 2017 05:53
whenever we've dug into things with someone who needs a way lower CR for breakfast, we've found that they're mostly compensating for insulin vs. fast-breakfast-carb timing: it's not that they need more insulin to prevent BG from ending up high 4h later, but rather they don't want BG to end up so high 1-2h after breakfast. sometimes they even end up having to do a snack to prevent a low >2h after breakfast. If that matches your pattern, I'd recommend trying an eating soon mode and/or prebolus for breakfast to try to get the breakfast insulin started earlier, so you can do slightly less total breakfast insulin (a higher CR) and better match its activity to the carb absorption. if that doesn't work, you can just manually dose according to your lower breakfast CR, and then let autotune turn that into a super bolus by zero-temping based on the higher autotuned CR.
Paul Dickens
@thebookins
Sep 30 2017 06:10
Definitely part of the issue is not wanting the spike in the hour/ two hours after breakfast. At school the next eating time is about 3 hours later, so we don't have long to wait to return to target. Currently we set a target of 4.4 beginning about 1 hour before eating or else give a prebolus around 20 mins before eating. The superbolus idea may be a good solution, though I am concerned about the safety if the rig looses contact with the pump.
Scott Leibrand
@scottleibrand
Sep 30 2017 06:16
if you over-bolus for breakfast and the rig sets a long zero temp that you expect to run to completion, that doesn't seem like a safety issue: worst case BG will just be a little higher leading into the next meal/snack bolus.
I wouldn't give any extra insulin at breakfast because you expect the rig to zero temp for it, just be ok with it attempting to counteract the extra you already give due to the lower CR.
Paul Dickens
@thebookins
Sep 30 2017 06:23
Thanks scott, appreciate your help.
PieterGit
@PieterGit
Sep 30 2017 07:37
@danamlewis nice blogentry https://diyps.org/2017/09/29/not-bolusing-for-meals-fiasp-0-6-0-algorithm-in-oref0-dev-branch-and-more/
I also started looking at the variability reporting that @sulkaharo implemented in Nightscout (see nightscout/cgm-remote-monitor#2736 and http://www.healthline.com/diabetesmine/a-new-view-of-glycemic-variability-how-long-is-your-line#2 ) as an indicator of how well a rig is performing.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 10:32

Struggling with bluetooth. Everything is fine until Edison is rebooted. It's as if none of settings stick and I have to redo all of the bits about killall, pairing, etc.

When I check the settings post reboot, everything is fine. For some reason I can't fathom the rig will not initiate a tether to the phone. The BTAutoTether app doesn't help in this case; I'm at a loss.

Any volunteers to sit down with us and methodically analyze the problem step by step?

As long as Edison remains powered on after doing all the bluetooth steps, we're fine. Any power loss and I have to redo it all.
Jacob H
@jdhigh
Sep 30 2017 14:30
Is there an easy way to port the autotune recommendations log into NS's profile? (Rather than manually)
daveklingler
@daveklingler
Sep 30 2017 15:12
@YYCMichael I had the same problem. My BT worked for one full day (yay!) after running runagain, but then my rig crashed and it hasn't worked since then. I'm running runagain again as we type.
Tim Street
@tim2000s
Sep 30 2017 15:16
@YYCMichael I saw similar issues with a fresh install of Jubilinux 0.2.0 and 0.6.0 Dev branch. I ran through the various bits of oref0-online and oref0-bluetoothup and it seems to be that the sudo killall bluetoothd process isn't running correctly so the restart of the bluetoothd doesn't work properly. I haven't investigated further than that though.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 16:08
@tim2000s : for the killall, are you referring to the command manually entered during the initial setup? Does this command get re-issued at startup?
Tim Street
@tim2000s
Sep 30 2017 16:09
YOu need to work through the oref0-online and oref0-bluetoothup scripts to see how it works. When you are connecting to bluetooth, these do the same thing that you do when you initially set up the system
Deweyoxberg
@Deweyoxberg
Sep 30 2017 16:13
Hrm, is it possible the scripts are not providing enough time between the various commands and bluetooth does not start cleanly?
i know when we do it manually, we have to wait a good 15-20 seconds between steps or the process fails and I have to start over.
Dana Lewis
@danamlewis
Sep 30 2017 16:52
@PieterGit thx!
@jdhigh I don't believe anyone's done that. (Is it possible? Dunno. Worth a try, but haven't seen anyone work on figuring it out)
Dana Lewis
@danamlewis
Sep 30 2017 19:01
@brmccollum bummer about the 12s but glad you're up and looping now!
Deweyoxberg
@Deweyoxberg
Sep 30 2017 19:33
@tim2000s : I think you're on to something
Sep 30 12:33:02 localhost bluetoothd: Bluetooth daemon 5.44
Sep 30 12:33:02 localhost bluetoothd: Starting SDP server
Sep 30 12:33:02 localhost bluetoothd: Bluetooth management interface 1.3 initialized
Sep 30 12:33:02 localhost bluetoothd: Failed to read advertising features: Unknown Command (0x01)
Sep 30 12:33:02 localhost bluetoothd: hci0 Load Connection Parameters failed: Unknown Command (0x01)
That's the log result from just a sudo killall and leaving it alone for a few seconds
Katie Aldridge
@kcrcgm
Sep 30 2017 19:40
Hello all! I want to automate autotune to run nightly, to help with me switching from Fiasp back to Humalog. I'm on the dev branch. Do I edit my runagain file and then install 0.6.0 again? Where and what do I add? Here's what mine says now, after the api secret... --tty=/dev/spidev5.1 --max_iob=4 --enable=' autosens meal microbolus ' --radio_locale='US' TIA!
Deweyoxberg
@Deweyoxberg
Sep 30 2017 19:45
found this as well in the bluetooth saga: Sep 30 12:44:27 localhost dbus: [system] Failed to activate service 'org.freedesktop.hostname1': timed out
sdneufer
@sdneufer
Sep 30 2017 19:52
@kcrcgm If you just want to run autotune nightly why not just add it into your crontab if its not already there?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 19:57
@tim2000s : curiously I'm on jubi 0.1.1 ; was flashed before v2 was available. Might have to start there then and see what happens.
Katie Aldridge
@kcrcgm
Sep 30 2017 19:57
@sdneufer Didn't know I could do that. ;) I'll check it to see if it's there.
sdneufer
@sdneufer
Sep 30 2017 19:58
@kcrcgm crontab -l | grep autotune
Katie Aldridge
@kcrcgm
Sep 30 2017 19:58
@sdneufer I did try just editing my runagain file and pulling the dev branch again, and it seems to be working. I think Scott updated some autotune things recently so probably good for me to pull again anyway
sdneufer
@sdneufer
Sep 30 2017 19:58
look for
5 0 * ( oref0-autotune -d=/root/myopenaps -n=https://YOURSITE.herokuapp.com && cat /root/myopenaps/autotune/profile.json | json | grep -q start && cp /root/myopenaps/autotune/profile.json /root/myopenaps/settings/autotune.json) 2>&1 | tee -a /var/log/openaps/autotune.log
Katie Aldridge
@kcrcgm
Sep 30 2017 19:59
@sdneufer But if that didn't automate autotune, I'll do it the way you suggested. Thank you!
sdneufer
@sdneufer
Sep 30 2017 19:59
never seems to hurt to update
Deweyoxberg
@Deweyoxberg
Sep 30 2017 20:28
Would a flash to newer jubilinux version wipe the edison to scratch?
I'm wondering if I may find better results with bluetooth starting from zero
Anytime bluetooth service launches from the system it fails on the namespace; not familiar with writing a script to kill it on reboot and start how I want it to
Deweyoxberg
@Deweyoxberg
Sep 30 2017 20:37
Narrowed it down to the bluetooth service not starting correctly on reboot.
That hci0 step is failing
Deweyoxberg
@Deweyoxberg
Sep 30 2017 21:56
Ok, figured out a temporary workaround. made a script to kill bluetooth, restart it and redo the hci0 step
But getting it to run after Edison has been rebooted is a mystery
Tried adding it to the crontab with everything else, no dice; yep, it's executable.
Works to solve the problem for now, just need it running on reboot.
sdneufer
@sdneufer
Sep 30 2017 22:34
@YYCMichael Did you try putting it in /etc/rc.local that should be run on reboot
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:36
@sdneufer : that was the other idea, but the concern I have there is if it runs before the regular bluetooth initialization then I just re-create the problem
Tim Street
@tim2000s
Sep 30 2017 22:39
@YYCMichael I wonder if the simplest solution is to add a couple of waits in to oref0-Bluetoothup?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:40
That was the long term idea. I didn't want to mess with the oref=stuff at the moment
Altough... if I broke something in there, restarting the oref setup would wipe out any oopses yes?
which is a whole other set of questions... where is oref0-Bluetoothup :P
sdneufer
@sdneufer
Sep 30 2017 22:41
@YYCMichael rc.local should be the very last thing that is run on reboot. If you run a bluetooth script you would not wipe out oref0.
@YYCMichael /root/src/oref0/bin/oref0-bluetoothsetup.sh
@YYCMichael umm... oref0-bluetoothup.sh is there also
on the edison
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:44
hoha!
Glenn Primack
@primags
Sep 30 2017 22:44
I am on my first week of OpenAPS so still working on understanding all the moving pieces. I don't use the bolus wizard to calculate my carbs ((it never worked well for me), I always just do a manual bolus based on what I'm eating and how I know the food generally affects my blood sugar; I was wondering if there is any component of the OpenAPS system where not giving the pump carb info to calculate bolus amounts will bite me.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:46
@tim2000s I think you're on to something here, check the commands in bluetoothup
if ! ( hciconfig -a | grep -q "PSCAN" ) ; then
sudo killall bluetoothd
sudo /usr/local/bin/bluetoothd --experimental &
There's no wait or error check
sometimes when I do killall I have to repeat the command once more after a few seconds to ensure it's really down
sdneufer
@sdneufer
Sep 30 2017 22:47
@YYCMichael @tim2000s add a sleep 5 in there?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:51
added a couple both after the killall and after the --experimental (sleep 15 there)
rebooting now
let's see what happens :)
nope
Sep 30 15:53:02 localhost bluetoothd: Bluetooth daemon 5.44
Sep 30 15:53:03 localhost bluetoothd: Starting SDP server
Sep 30 15:53:03 localhost bluetoothd: Bluetooth management interface 1.3 initialized
Sep 30 15:53:03 localhost bluetoothd: Failed to read advertising features: Unknown Command (0x01)
Sep 30 15:53:03 localhost bluetoothd: hci0 Load Connection Parameters failed: Unknown Command (0x01)
growly...
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:57
I can't be the only person to be running into this problem if it's truly broken in bluetoothup
sdneufer
@sdneufer
Sep 30 2017 22:58
where do you see those messages?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 22:59
it's in my papertrail log
if I manually kill bluetooth, restart it, do the hci step by hand, then it's fine
sdneufer
@sdneufer
Sep 30 2017 23:00
where is the papertrail log getting it the error from? my log files do not have an error.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:00
good question
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:07
@sdneufer what was your command for looking at the logs?
was going to type it in but it's gone now
sdneufer
@sdneufer
Sep 30 2017 23:10
There are many openaps logs for pumps etc... I start with tail -50 /var/log/syslog and see that it reported
Sep 30 19:09:02 localhost CRON[12962]: (root) CMD (ps aux | grep -v grep | grep -q "oref0-bluetoothup" || oref0-bluetoothup >> /var/log/openaps/network.log)
so I looked at /var/log/openaps/network.log however it has nothing around 19:09 from oref0-bluetoothup
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:14
nothing in there about bluetooth at all
think it's more coming from the system level
sdneufer
@sdneufer
Sep 30 2017 23:17
you could look through /var/log files or /var/log/openaps files however syslog is where I expected to find system level stuff. My experience is older though so they may have some stuff moved around.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:20
yep syslog is where it's coming from
is this a typo?
Oct 1 08:20:03 localhost systemd[11935]: Failed at step NAMESPACE spawning /lib/systemd/systemd-hostnamed: No such file or directory
systemd-hostnamed
nevermind on typo :P
tynbendad
@tynbendad
Sep 30 2017 23:25
fyi (i know how to free space), one of my rigs just ran out of space :)
/usr/local/bin/oref0-pump-loop: line 338: echo: write error: No space left on device
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:28
Looks like @iainct had the same issue back on April 7th
sdneufer
@sdneufer
Sep 30 2017 23:31
Hmm... I looked online for the message "hci0 Load Connection Parameters" and found a reference that said it can show up "... This error is caused when there is another process already using that port. Another option would be to change the Port or to reinitialize the Bluetooth service."
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:31
Which explains why restarting bluetooth works for me
When I dig more and do systemctl status systemd-hostnamed.service, I find that process failed to load correctly
(that whole namespace problem)
looking at the rest of gitter, looks like quite a few people running into that
Ah, well... according to @Kdisimone , hostname isn't a thing because it's not used... so that's one error down :P
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:37
fine then, back to getting the restart script working
sdneufer
@sdneufer
Sep 30 2017 23:39
ok. crontab shows that if oref0-bluetoothup is not being run it runs it... every minute
on boot in rc.local /usr/local/sbin/bluetooth_patchram.sh
is run
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:42
but it's busted... so... running a busted bluetooth every minute = busted
sdneufer
@sdneufer
Sep 30 2017 23:47
Are you only getting the error on reboot?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:47
Well the bottom line is bluetooth doesn't connect if wifi islost.
I can manually make it work with the whole killall etc commands
But if the rig reboots, I have to redo the fix manually
From my perspective, whatever happens at boot concerning starting up bluetooth is broken
I could be wrong :P
sdneufer
@sdneufer
Sep 30 2017 23:48
if the rig reboots and it fails I would look in the /usr/local/sbin/bluetooth_patchram.sh script. Perhaps the sleep 5 there should be sleep 15 ?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:49

killall -9 bluetoothd

mkdir /mnt/mmcblk0p5
mount /dev/mmcblk0p5 /mnt/mmcblk0p5

BD_ADDR=$(echo $(cat /mnt/mmcblk0p5/bluetooth_address))

umount /mnt/mmcblk0p5
rmdir /mnt/mmcblk0p5

rfkill unblock bluetooth

nohup brcm_patchram_plus \
  --bd_addr $BD_ADDR \
  --use_baudrate_for_download \
  --no2bytes \
  --enable_lpm \
  --enable_hci \
  --baudrate 3000000 \
  --patchram /etc/firmware/bcm43341.hcd \
  /dev/ttyMFD0 > /var/log/brcm_patchram_plus.log 2>&1 &

/usr/local/libexec/bluetooth/bluetoothd &

sleep 5

hciconfig hci0 up
hciconfig hci0 noscan
I'm wondering about the libexec bit myself
everything else where bluetooth is started uses --experimental
can try sleep15
might just not be enough time
sdneufer
@sdneufer
Sep 30 2017 23:50
what does /var/log/brcm_patchram_plus.log have in it?
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:51
heh just rebooted with sleep 20, will let you know shortly
sdneufer
@sdneufer
Sep 30 2017 23:51
ok. that log file on mine says "Done setting line discipline"
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:52
same
and the sleep didn't help
sdneufer
@sdneufer
Sep 30 2017 23:55
so that is where the bluetoothd errors are likely coming from. my suggestion at this point would be to cp the /usr/local/sbin/bluetooth_patchram.sh
file to create a backup and then comment out the bluetoothd and add in the commands you run manually.
Deweyoxberg
@Deweyoxberg
Sep 30 2017 23:59
copied, commented, edited, rebooted, waiting
fingers crossed