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

28th
Mar 2019
Jon Cluck
@cluckj
Mar 28 00:03 UTC
new pumps don't have any pump history in them, set a temp basal or something
Katja Jacob
@straykatz
Mar 28 00:03 UTC
ok
done
Oh, yea. That did it.
OMG I HAVE A BACKUP SETUP RUNNING!!!
thank you kindly, Sir!
Jon Cluck
@cluckj
Mar 28 00:08 UTC
:confetti_ball: :clap: :tada:
thanks for testing this out today!
Katja Jacob
@straykatz
Mar 28 00:09 UTC
Yes. Most welcome :)
Phhh. Unfortunately none of the other chips wanted to go through bootstrap ....
Jon Cluck
@cluckj
Mar 28 00:09 UTC
did any without the chip antenna work?
Katja Jacob
@straykatz
Mar 28 00:10 UTC
no, I did not end up setting one up
Jon Cluck
@cluckj
Mar 28 00:15 UTC
@thanksegon did yours end up starting to loop?
Katja Jacob
@straykatz
Mar 28 00:27 UTC
OK, running autotune, and then I'll try to set up Lookout on the new chip. I feel slightly masochistic, but hey, eyes on the prize, huh <3
node is >8 now, right? 9 or something?
Jon Cluck
@cluckj
Mar 28 00:32 UTC
should be v8.something now
Katja Jacob
@straykatz
Mar 28 00:34 UTC
cool
Katja Jacob
@straykatz
Mar 28 02:35 UTC
hmm ... why do I get this: Could not parse autotune_data
When I get a result on cat-autotune, since I ran autotune manually
tynbendad
@tynbendad
Mar 28 03:10 UTC
has anyone tried autotune_isf_adjustmentFraction on 0.6.2 master? it doesn't seem to do anything for me (tried values of 0.5, 1.0, 0.0)... the description in docs says "keeps autotune ISF closer to pump ISF via a weighted average of fullNewISF and pumpISF. 1.0" but that isn't happening. pump isf is 19, autotune isf was around 12 for all tested values of autotune_isf_adjustmentFraction.
Martin Haeberli
@mhaeberli
Mar 28 03:25 UTC
on an Edison rig -
...
Hit http://http.debian.net jessie/non-free Translation-en                                                                       
Ign http://http.debian.net jessie-updates/contrib Translation-en_IE                                                             
Ign http://http.debian.net jessie-updates/contrib Translation-en                                                                
Ign http://http.debian.net jessie-updates/main Translation-en_IE                                                                
Ign http://http.debian.net jessie-updates/main Translation-en                                                                   
Ign http://http.debian.net jessie-updates/non-free Translation-en_IE                                                            
Ign http://http.debian.net jessie-updates/non-free Translation-en                                                               
Err http://http.debian.net jessie-backports/main i386 Packages                                                                  

Ign http://http.debian.net jessie-backports/main Translation-en_IE                                                              
Ign http://http.debian.net jessie-backports/main Translation-en                                                                 
Err http://http.debian.net jessie-updates/main i386 Packages                                                                    
  404  Not Found
Err http://http.debian.net jessie-updates/contrib i386 Packages                                                                 
  404  Not Found
Err http://http.debian.net jessie-updates/non-free i386 Packages                                                                
  404  Not Found
Err http://http.debian.net jessie-backports/main i386 Packages                                                                  
  404  Not Found
Fetched 1,771 B in 32s (53 B/s)                                                                                                 
W: Failed to fetch http://http.debian.net/debian/dists/jessie-updates/main/binary-i386/Packages  404  Not Found

W: Failed to fetch http://http.debian.net/debian/dists/jessie-updates/contrib/binary-i386/Packages  404  Not Found

W: Failed to fetch http://http.debian.net/debian/dists/jessie-updates/non-free/binary-i386/Packages  404  Not Found

W: Failed to fetch http://http.debian.net/debian/dists/jessie-backports/main/binary-i386/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
why the errors?
Jon Cluck
@cluckj
Mar 28 03:44 UTC
@mhaeberli jessie went LTS, you should reflash with jubilinux 0.3.0 and bootstrap/install dev: openaps/docs#1448
@straykatz it may not have regenerated your profile with autotune?
Katja Jacob
@straykatz
Mar 28 03:46 UTC
how can I find out?
another thing, right now the new rig is not reading COB from Nightscout.
But I got Lookout to work, and it's looping. No SMBs right now, but I also had to update the settings substantially to turn them on. Had not done that for a while :)
Jon Cluck
@cluckj
Mar 28 03:47 UTC
or something went wrong with the manual autotune run :\
Katja Jacob
@straykatz
Mar 28 03:48 UTC
yea
the rig has a nice list to show when I "cat-autotune"
Continuing oref0-pump-loop at Wed Mar 27 20:48:38 PDT 2019
Checking reservoir: reservoir level before: 142.7, suggested: 142.7 and after: 142.7
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":false,"suspended":false}
Sending ESC ESC, ESC ESC ESC ESC to exit any open menus before SMBing and bolusing 0.3 units
Checking pump status (suspended/bolusing): {"status":"normal","bolusing":true,"suspended":false}
Settings less than 30 minutes old. Refreshing pumphistory because: bolused, Pump profile refreshed; Could not parse autotune_data
Settings refreshed; Pump history updated through 2019-03-27T20:48:18-07:00 with 1 new records; meal.json Not enough glucose data to calculate carb absorption; found: 15
refreshed: {"carbs":100,"nsCarbs":100,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":2.15,"maxDeviation":0.55,"minDeviation":-0.82,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":1.163,"allDeviations":[2,-1,-1,0,1],"lastCarbTime":1553743195512,"bwFound":false,"reason":"not enough glucose data to calculate carb absorption"}
{"carbs":100,"nsCarbs":100,"bwCarbs":0,"journalCarbs":0,"mealCOB":0,"currentDeviation":2.15,"maxDeviation":0.55,"minDeviation":-0.82,"slopeFromMaxDeviation":0,"slopeFromMinDeviation":1.163,"allDeviations":[2,-1,-1,0,1],"lastCarbTime":1553743195512,"bwFound":false,"reason":"not enough glucose data to calculate carb absorption"}
IOB: 0.288
Completed oref0-pump-loop at Wed Mar 27 20:49:46 PDT 2019
it did SMB with the updated preference settings!
I also restarted it (the "press the button" way)
Jon Cluck
@cluckj
Mar 28 03:52 UTC
looks like it did: Checking pump status (suspended/bolusing): {"status":"normal","bolusing":true,"suspended":false}
Katja Jacob
@straykatz
Mar 28 03:52 UTC
Perhaps it's waiting on the COB to get CarbAbsorption with more glucose data
not sure why it's not using NS data
yes, I did SMB 0.3 :)
Jon Cluck
@cluckj
Mar 28 03:53 UTC
it says you have 100g of COB from NS
"carbs":100,"nsCarbs":100,"bwCarbs":0
Katja Jacob
@straykatz
Mar 28 03:54 UTC
yea, maybe all day ...
Martin Haeberli
@mhaeberli
Mar 28 03:54 UTC
@cluckj
Jon Cluck
@cluckj
Mar 28 03:54 UTC
hah, okay
Martin Haeberli
@mhaeberli
Mar 28 03:54 UTC
@cluckj :+1:
Jon Cluck
@cluckj
Mar 28 03:55 UTC
I don't remember how many readings it needs to do absorption, maybe 20?
Katja Jacob
@straykatz
Mar 28 03:58 UTC
hmm. ontinuing oref0-pump-loop at Wed Mar 27 20:57:20 PDT 2019
Preflight OK. Profile less than 60m old; Invalid settings.json
Profile invalid: -rw-r--r-- 1 root root 4477 Mar 27 20:55 settings/profile.json
Pump profile refreshed; Could not parse autotune_data
is this pref?
Jon Cluck
@cluckj
Mar 28 04:00 UTC
no, looks like a bad autotune run
Katja Jacob
@straykatz
Mar 28 05:10 UTC
well, this is running. BT tether is working + it is jumping back onto my WIFI (which is better than my other rig :)). Thank you, @cluckj for this very long day of helping me.
Stephan
@MosiGitHub
Mar 28 08:10 UTC
hey guys, anybody (especially from Germany) interested in some rigs based on Intel Edison and the ERF chip or the TI stick. Worked nicely together with Medtronic pumps and Medtronic CGM. so, if interested just contact me via PN ;-)
Jan Schenk
@jansche
Mar 28 23:02 UTC

Anybody knows why "Listening" currently takes like - forever?

Listening for 46s: .....................................................................................................................................................................

That was more like 5-8 minutes not 46 seconds...

Scott Leibrand
@scottleibrand
Mar 28 23:02 UTC
Each time a . is printed, the 46 seconds starts over
because it detected another rig communicating with the pump
a rig waiting for > 30s should only stop waiting once the other rig(s) finish their loops and go into "waiting for next BG" mode, or if they all fail their loops and mmtune into a > 30s wait as well
Jan Schenk
@jansche
Mar 28 23:04 UTC
Err, for that pump, there should only be one rig talking. What about neighbor frequencies?
And thanks for the knowledge, @scottleibrand . Didn't know that.
Scott Leibrand
@scottleibrand
Mar 28 23:04 UTC
I'd run oref0-pump-loop in debug mode to see what it's detecting
Jan Schenk
@jansche
Mar 28 23:04 UTC
have that command handy?
Scott Leibrand
@scottleibrand
Mar 28 23:05 UTC
OREF0_DEBUG=1 oref0-pump-loop
but first you have to kill off the existing loop
and generally best to stop cron so it doesn't start another one
Jan Schenk
@jansche
Mar 28 23:15 UTC
ok, running it the 7th time was successful. Before it said it couldn't connect to RFM69HCW on spidev0.1. Maybe an old process still running.
Jan Schenk
@jansche
Mar 28 23:22 UTC
Could it be my other rig (on a different frequency 848.500, my frequency vs. my daughter's 848.350) disturbing RF? should I just schedule diffenrently in cron? like 2 minutes before or after the other one?
Scott Leibrand
@scottleibrand
Mar 28 23:22 UTC
those frequencies are effectively the same
Jan Schenk
@jansche
Mar 28 23:23 UTC
ok, well, then. Would modifying times in crontab help?
ooops, radio errors reboot.
Scott Leibrand
@scottleibrand
Mar 28 23:23 UTC
so yes, they will interfere with each other, and each rig will need to wait until the other is done to proceed. are they not finishing up with enough time before the next BG to allow the other one to proceed?
Jan Schenk
@jansche
Mar 28 23:25 UTC
obviously not. haven't checked, but it's all Pi0s, they are slower than the Edisons. Way slower. So...
Will unplug the other rig though. it's just a backup.
Thanks for your help, as usual, @scottleibrand! I appreciate!
Scott Leibrand
@scottleibrand
Mar 28 23:28 UTC
:+1:
if you want to keep a backup rig running but not often, you can do something like echo 60 > /tmp/wait_for_silence to tell it to wait longer
that will last until the next reboot
Jan Schenk
@jansche
Mar 28 23:32 UTC
cool. Will note that in my docs. =)