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

25th
Mar 2019
Riko L
@Ricco555
Mar 25 00:51

hmm weird behavior stopped. Now it's back to normal. ISF is now reported as

Autosens ratio: 1.07; Basal unchanged: 0.3; ISF from 375.6 to 351; CR: 30.041

and all looks good. Will monitor if this comes up again.

viq
@viq
Mar 25 11:35
:D
Parameter      | Pump        | Autotune    | Days Missing
---------------------------------------------------------
ISF [mg/dL/U]  | 56.000      | 2611.852    |
Carb Ratio[g/U]| 14.000      | 14.000      |
Stargazer32584
@Stargazer32584
Mar 25 14:08
Just a short question. Is it possible to use the
RPi0 with Explorer HAT with the accu in the HAT and a 5V battery in the Pi ? Background: if i sit on the computer, i could use his 5V to power the system. And if i go away, i plug the 5V power off and use the battery on the HAT.
Scott Leibrand
@scottleibrand
Mar 25 15:33
@viq any idea how it got to that?
viq
@viq
Mar 25 15:34
A walk on Saturday. Insterestingly, autotuneweb for same period wants to change from 56 to 54
Scott Leibrand
@scottleibrand
Mar 25 15:35
ah, I see the conversation in https://gitter.im/openaps/autotune, so I'm assuming that's specific to a non-standard implementation of autotune on docker or something?
viq
@viq
Mar 25 15:37

I'm getting

Parameter      | Pump        | Autotune    | Days Missing
---------------------------------------------------------
ISF [mg/dL/U]  | 56.000      | 723.849     |
Carb Ratio[g/U]| 14.000      | 14.000      |

on latest dev oref0 running on debian 9 in LXC, so while some of it may be due to some quirks of that docker setup, it seems that quite "vanilla" oref0 has the same issue

Scott Leibrand
@scottleibrand
Mar 25 15:41
that shouldn't be possible for ISF to diverge more than a factor of autosens_min from the pump ISF. can you help figure out why?
and we can move that conversation back to https://gitter.im/openaps/autotune
Andrew Baugh
@baughaw
Mar 25 17:21
@scottleibrand Do you think it would make sense for a temp basal to be cancelled if no new sensor data was received for x amount of time? I had a bad sensor the other day and was telling me I was low but really wasnt. So my rig set an hour and a half zero temp. I then proceeded to insert a new sensor and the 2 hour warmup. I know I should have cancelled the temp basal.... but I forgot. An hour later I am sky high. Thoughts?
Scott Leibrand
@scottleibrand
Mar 25 17:33
the 90 minute zero temp was based on how much IOB needed to be neutralized to avoid going low if your meal carbs didn't materialize. there are certain situations under which we'll shorten a long zero temp to 30m, but we really want to avoid causing hypos, even if it means you have to take manual action to dose for any carbs that you know for sure are actually getting absorbed
it shouldn't be possible to go "sky high" from the zero-temping alone: that only happens when you have COB and the rig stops being able to safely dose for it due to lack of CGM data (and you don't do so manually)
Abigail Cember
@acember
Mar 25 19:35
I don't know about you guys but I can easily go "sky high" from not having any basal for an hour and a half...
So back to my time issue, what do I do about constantly getting an "ntpd failed to synchronize error" when I need the rig to be getting the time from my pump?
Scott Leibrand
@scottleibrand
Mar 25 19:43
perhaps we need to define "sky high" - you shouldn't rise more than 1.5 (h) basal (U/hr) ISF (mg/dL/U or mmol/L/U) from 90m of missed basal, and the rise should only occur over DIA hours.
ntpd failed to synchronize should precede (and trigger) the attempt to get time from the pump
Abigail Cember
@acember
Mar 25 20:01
I would disagree that it's a linear function, but this can be discussed later...
What seems to happen is that my rig just attempts this over and over over, without ever succeeding. How would I go about troubleshooting or debugging this?
viq
@viq
Mar 25 20:07
I can probably give some advice regarding the ntpd part, not the pump part
I guess:
1) is your rig able to reach the internet?
2) journalctl -u ntpd
3) what's in /etc/ntpd.conf?
Abigail Cember
@acember
Mar 25 20:09
As for 1) no, the whole point is that I'm trying to loop offline
Let me look at that other stuff
viq
@viq
Mar 25 20:09
Ah, then the rest is not relevant
Since ntpd is a daemon to synchronise time with servers online
And adding a GPS receiver to your rig to have an offline time source sounds like a bit of an overkill ;)
you should be able to run oref0-set-system-clock manually for testing
Abigail Cember
@acember
Mar 25 20:42
In other words, this is the function that should run automatically and set the clock from the pump if there's no internet?
Oh, sorry, I missed that first link with the function in context.
Scott Leibrand
@scottleibrand
Mar 25 20:55
yes
Abigail Cember
@acember
Mar 25 20:58
What do these "2>&3 >&4" indicate? Do I need them as input args?
hmm
monitor/clock-zoned.json doesn't exist
Is that the source of my problem?
Scott Leibrand
@scottleibrand
Mar 25 21:20
those 2>&3 >&4 redirects point the output somewhere else. you don't need to include those for a manual run, as long as you don't mind seeing everything
are you looking in ~/myopenaps/ ?
does your pump-loop.log have a Checking that pump clock: foo is within 90s of current time: bar ? that reads from monitor/clock-zoned.json
Abigail Cember
@acember
Mar 25 21:31
As for the monitor/clock-zoned.json, I reported that it doesn't exist based on the error thrown by oref0-set-syste-clock, not by looking for it myself. Let me check if it's there.
*system
It actually is there...
Abigail Cember
@acember
Mar 25 21:43
yeah, that's not the problem - -I had just run the 'set-clock' command from the wrong directory. Still working on it...
Abigail Cember
@acember
Mar 25 22:12
Ok, so I think I figured out the problem, and it seems really simple -- but because I don't know diddly squat on linux I have no idea how to fix it. When my rig does the set-system-clock "by itself", it always fails, because it's not looking in the myopenaps directory. When I run it manually, I have to cd to myopenaps first, and then everything is fine. Whatever this line (21 in oref0-set-system-clock)
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
is supposed to mean, I think it isn't working :/
viq
@viq
Mar 25 22:14
@acember that's just telling it where to look for executables, so this is not the culprit directly
Abigail Cember
@acember
Mar 25 22:15
@viq Oh. Then clearly I don't even know what PATH means. How does it know where to look for the things defined in lines 23-26?
viq
@viq
Mar 25 22:15
Sorry, lines of what?
Scott Leibrand
@scottleibrand
Mar 25 22:15
it depends where oref0-pump-loop (which calls oref0-set-system-clock) is running
Scott Leibrand
@scottleibrand
Mar 25 22:15
which should be ~/myopenaps/
Abigail Cember
@acember
Mar 25 22:16
Hm...so I could I have messed it up so that oref0-pump-loop is running in home (which I guess it is)?
Scott Leibrand
@scottleibrand
Mar 25 22:16
nothing would work if you did that
Abigail Cember
@acember
Mar 25 22:17
Oh boy. Well, maybe I came up with a wrong hypothesis? Why would I have to do a cd to myopenaps in order for oref0-set-system-clock to work?
Scott Leibrand
@scottleibrand
Mar 25 22:17
because that's what the scripts do
Abigail Cember
@acember
Mar 25 22:17
Oh, OK -- so it's not a problem that if I wanted to run it manually, I had to do that (?)
Scott Leibrand
@scottleibrand
Mar 25 22:17
correct, that's normal
so it successfully sets rig time from pump time when run manually?
Abigail Cember
@acember
Mar 25 22:19
In that case I'm kind of back to square one: my clock will only get set when I run that function manually, and not when it's ostensibly being called from smb_verify_suggested.
Yeah, it works when I run it manually.
Scott Leibrand
@scottleibrand
Mar 25 22:19
we may need to run oref0-pump-loop in debug mode then
like @cluckj has someone doing in https://gitter.im/openaps/oref0
"you'll want to systemctl stop cron and wait a few minutes first, so that you can use the radio
then cd ~/myopenaps/ && OREF0_DEBUG=1 oref0-pump-loop"
Abigail Cember
@acember
Mar 25 22:21
Ok, here goes...are there just more write statements?
Scott Leibrand
@scottleibrand
Mar 25 22:21
all the output normally hidden by 2>&3 >&4 gets printed, ya
you only care about the part where it tries to reset the clock
Abigail Cember
@acember
Mar 25 22:21
I like output :)
Abigail Cember
@acember
Mar 25 22:37
Except in this case there is no extra output :(
I've tried a couple of times, and i only get the "ntpd did not synchronize" message
It almost seems as if this if statement:

if ! checkNTP; then

set system time to pump time if pump time is newer than the system time (by printing out the current epoch, and the epoch generated from the $CLOCK file, and using the most recent)

echo Setting system time to later of `date` or `cat $CLOCK`:
echo "(epochtime_now; to_epochtime $(cat $CLOCK; echo)) | sort -g | tail -1 | while read line; do sudo date -s @\$line; done;"
(epochtime_now; to_epochtime "$(cat $CLOCK; echo)") | sort -g | tail -1 | while read line; do sudo date -s @$line; done;

fi

whoa sorry about that formatting
Abigail Cember
@acember
Mar 25 22:42
I meant to say that this if statement doesn't get entered unless I'm running the function manually
image.png
Ok, that's better. So yeah, this only happens if I have manually run oref0-set-system-clock, and never seems to happen from within oref0-pump-loop