@MilosKozak the meal-assist branch is what we're using in production.
@TC2013 I opened nightscout/cgm-remote-monitor#1545 that I hope will fix the NS OpenAPS alarms you're getting. Also gets rid of the really noisy units warnings.
when NS starts you should see something like
OpenAPS Prefs: { warn: 30, urgent: 60, enableAlerts: true } in the logs with the settings it sees
I am having trouble pulling the latest treatment from NS. at some point overnight my loop stopped working. NS was also not working to even pull BGs from share. I rebooted Heroku and it started pulling BGs again.
when i run
openaps use latest-treatments shell it craps out with no JSON object. not sure where that is supposed to come from
@jmatheson that PR above should help with your papertrail issues too
the latest-treatments.json runs but comes back with nothing. some sort of issue talking to NS but not sure the deal
what do you get for
openaps latest-ns-treatment-time
this is what my report looks like
[report "monitor/latest-treatments.json"]
device = latest-treatments
use = shell
reporter = textand then my device is
[device "latest-treatments"]
vendor = openaps.vendors.process
extra = ini/latest-treatments.iniand then my ini is
[device "latest-treatments"]
fields =
cmd = nightscout
args = latest-openaps-treatment $NIGHTSCOUT_HOSTand then in my env $NIGHTSCOUT_HOST is set properly
mine might be a little different, my alias is
format-latest-nightscout-treatments = ! bash -c "nightscout cull-latest-openaps-treatments monitor/pump-history-zoned.json monitor/model.json $(openaps latest-ns-treatment-time) > monitor/upload-treatments.json"
that report returns nothing because it is grepping for a time in a blank file
it just says no valid json
oh, since there are no treatments to pull down
time/timezone on the edison are right?
yes
but me NS site crashed overnight and/or it might have some bogus data.
well the site was up, but it was not working for BG or loop. and then i rebooted it.
check the admin page in NS and see if there are any future treatment, but it doesn't sound like it
nothing in the future on admin
i think it has something to do with my secret key. going to dig in on this.
do you need api secret to pull down? I guess not
no, read is open
only to PUT/POST/DELETE
ok
not clue why it can’t pull latest treatment. is there a place i can look in my heroku db to see if there is something there valid to pull?
i guess nothing in NS reports is showing anything
I think you just don't have any recent openaps treatments
it should be able to get past that
it expects JSON as opposed to a blank file.
it’s supposed to get past that?
my format-latest-nightscout-treatments is the same as yours
Evening - another quick question on calculations when running low.
I just saw this:
reason":"BG 66<100, avg delta 3.67>0; no high-temp to cancel"
And what I would expect should happen is that I get a 0 rate for 30 minutes, since I am below my threshold. But instead, I have no temp rate set (low or high) and am on normal basal rate.
This is a bit counter-intuitive to me...what's the history/experience guiding that setting?
I just saw this:
reason":"BG 66<100, avg delta 3.67>0; no high-temp to cancel"
And what I would expect should happen is that I get a 0 rate for 30 minutes, since I am below my threshold. But instead, I have no temp rate set (low or high) and am on normal basal rate.
This is a bit counter-intuitive to me...what's the history/experience guiding that setting?
You're rising quite quickly: almost 4 mg/dL every 5 minutes. If you had a low-temp already running, it'd let it run. But it won't set a new one unless the rise slows.
By the time any low temp would take effect, you'll have rebounded already if you keep rising like that.
But I am below a threshold - isn't that the point? To rise, regardless of rate?
I see a bunch of logic around " if below threshold" which doesn't quite make sense. I put a defensive threshold of 100 to protect from lows. But that doesn't seem to be working - and it seems to be the logic turning basals back on before I have any sufficient climb out of the hole...
With the current logic, I am ping-ponging between by "Below 55" and "Below 70" warnings
did you set it to 100-100?
or is it set to a range?
I hard coded my threshold to 100, my min_bg = max_bg = 120
The hardcoded threshold = 100 was a ham fisted attempt to protect from lows, when the previous value of 80(?) just kept slamming me low.
someone else will need to answer.. I haven't heard of anyone hardcoding it, the docs I read suggested starting high like 120-160 and seeing where it went from there and slowly lowering the limits
hmm, it sounds like something else may be wrong then. is there any chance your basals are too high right now?
what you should be seeing is any time you are flat or falling slightly, it will zero-temp, and when you start to rise sufficiently, it will let that run for 30m and then expire, without setting a new one
if those zero-temps are insufficient to keep you above 70, then something else is not right
do you have a NS site you could PM me to take a look at in more detail to see what all is going on?
nope - haven't set up NS.
I would make that a priority
are you looping, or manually enacting things?
one thing you might notice if you're not looping during the initial drop is that it doesn't get enough negative IOB going, so it has to work a lot harder to bring you up
do you have a logfile you could share that I could go through with you?
For tonight, my priority is sleep. Have been looping. Have negative IOB ~-0.8 last I looked.
are you running sensitive, maybe from exercise or something?
This weekend has been out of the ordinary - travel, lots of unusual things. But I would expect even then, for the loop to protect my low. Period.
I need to figure out if the zero-temps are running to completion, or getting canceled...
and how long it's running normal basal before setting another low-temp
what branch are you running?
master (package), dev, or meal-assist?
I think it ran to completion, then when it was time to reset, the rise was large enough and I went back to no temp basal. which is currently a bad choice (too sensitive)
Running dev
one thing that might be helpful in situations like this is to set up automatic sensitivity detection (using the meal-assist branch)
but for tonight: do you have patterns set up on your pump?
No
we usually set up a pattern that runs at 80% of normal basal
and switch to that when running sensitive
for tonight, I gutted the code around line 172 and if below threshold, then I set a 0 rate for 30 minutes
ok, that will also work
again -pretty ham fisted, but serviceable
:+1:
:+1:
you'll probably see worse rebounds with that, but you probably don't care for tonight
so when you have time, I would: set up Pattern A to be lower basals for when you're running sensitive; set up nightscout to be able to see more clearly everything that's going on; and set up meal-assist with automatic sensitivity detection (which basically does an automatic version of the pattern A thing)
with my threshold at 100, I would agree. But with it set at a normal 80, I think it would work as I expect - maybe a high temping as I crest 80, but with generally higher sensitivity below 100, I don't think I would see much over shoot - but time would tell
See, I think the loop should handle cases when I am sensitive. It does when I am insensitive.
And does it well - even though I have expressed skepticism at times (which you always handle gracefully)
the other thing we see a lot of is that when BG gets that low, people tend to want to do carb corrections, so you'll see a big rebound from those.
but I think that's a function of how it handles lows - at least for some people (well, at least 1 - and that's not a statistic - that's an anectdote)
if you want, you could also open an issue describing the situation and your suggested fix, so we can start a wider discussion
you'd have a better sense if it's a wider issue - or if I am a "unique flower"
we've had a number of people say they don't want zero-temps to run for too long (multiple hours) due to risk of occlusions and ketones
so I'm genuinely not sure what the right thing to do is for really persistent lows
and that's genuinely okay - it may have to be user selectable - and see what happens picking one method vs. another
yeah. in any event, there are definitely some features in the newer branches that will help, so you should try those too.
meal assist is on my radar - but that seems like it's in flux/heavy development - so I 've been holding off, maybe it's time to take the leap. Any other features you would suggest?
meal assist itself is being replaced with advanced-meal-assist, so if you don't want to actually set up the meal assist reports you could defer that part
but you definitely want to set up the autosens reports using the meal-assist branch
will do - just verified that the loop is working with my changes
"reason":"BG 61<100","duration":30,"rate":0
time for sleep - thanks for your help
have a good night
sorry for the frustration: hopefully we can leverage it into some algorithm improvements
actually, it's less frustrating knowing I can form a hypothesis and point to code, rather than just wondering "WTF?"
:-)
(incidentally, one of the features that goes with meal-assist is called wtf-assist, which high-temps when you're rising for no apparent reason). I was gonna call it something more boring, but @jasoncalabrese and @amazaheri called it that and it stuck. :)
And over the last 2 weeks, even with stress at work that made the loop raise my insulin from 35 to 50 units/day, my BG is an average of 140. So it works, and I am loving it. I just seem to find some edge cases in the code...
around here it's called my "bubble" - and we are working on expanding the bubble and its benefits
:+1:
Just did this to prevent any issues tonight from DST time mismatch: openaps/oref0@89b609c
feel free to pull the latest meal-assist if you want to do the same, or cherry-pick that commit if you’re on another branch.
feel free to pull the latest meal-assist if you want to do the same, or cherry-pick that commit if you’re on another branch.
LMK if anyone wants me to push that to dev as well.
also opened openaps/oref0#83 to track fixing it right. not sure the best approach though.
some systems have a DST flag, wonder if tracking that flag at this time of year and in the fall would be beneficial?
I'm keeping an eye on mine since i'm curious what will happen soon
yeah, we should be able to do something smart with DST
but I'm hoping for a more general solution that deals well with timezone changes too
true
maybe allow for up to 3 hours offset if the time otherwise matches within 5m
and just throw a warning about fixing rig timezone
wouldn't we have to deal with people that fly internationally too?
generally though your body clock can only adjust 1 hour per day
so changing more than 3 hours without changing the Pi seems out of scope to me
I'm planning on fixing things as they break tonight, but planning to move the dumb device to the new time when the phones switch, and the probably need to clean up mongo some
yeah, then there's NS
our NS upload isn't working right now due to Share BLE issues, so I won't care about that this time
And xdrip and some other unexpected thing
Almost unpredictable
everyone please note in openaps/oref0#83 any oref0-related issues you see other than the obvious one I already called out.
and open issues in the appropriate places for any other things you see
Like that 2016 rollover bug, didn't enforce that
*expect
wow that changed over pretty smoothly
impressed
you haven't hit the threshold yet
?
I'd give it at least 10m after the DST change before saying it's working
if there is BG data coming through saying it is 3am, then wouldn't the threshold be OK?
fair enough
did you change the CGM and pump? or are they still on EST?
I have a G5 so the iphone did it automatically
the pump I did manually
I'm going to go change the receiver now tho ha
k. I would expect it to be smooth if you change all three at the same time
it's when you actually want to sleep through the DST change that you have trouble . :)
I see your point, not everybody would stay up until 2am
yeah I'm getting your point now the more I think about it
worse, when @danamlewis' body is on CST and her pump is on PST. :-(
hence my workaround, so she can sleep tonight.
CST/PST plus a DST change, ouch!
she's been at SXSW for awhile, but we never change the pump and CGM times due to bad experiences in the past
I do the same thing, I leave the pump alone. I'm new to the CGM tho
would be nice to fix openaps/oref0#83 so we can stop worrying about that
agreed
@tazitoo I have altered the algorithm as well and hard coded it that if below threshold to set a temp basal of 0 for 30 min no matter what. This seems to work better for us. We may rebound a bit higher than others but otherwise we find that the algorithm will push my son back down below threshold too often
I would be fine with merging a PR to do that, if that's the general consensus.
Not sure that works for everyone but definitely better for us.
maybe if combined with some max time to temp to 0
might need 2 thresholds, below ~55 no max time to temp to 0 below ~70 there would be some limit
or simply below ~55 extend to zero regardless, below ~70 do the current thing
I'd probably say ~60 and ~80 actually
I think that would work for me
And thanks for reporting this. This is the kind of thing we really want to get fixed ASAP to be as safe as possible when it matters most.
Similar was discussed before
Was that me? I don't remember what it was (or whether it was fixed).
Yes back on Nov 24 2015 - very similar discussion.
Not sure how to link to that discussion here. Thought quoting would work
I remember discussing, but don't remember what if anything was changed after
alt click on the time
:point_up: November 24, 2015 7:26 AM
ah, the 39+0 thing. we did fix that, but not by adding the 55-60 threshold
it was more of a >= thing
but sounds like we may want the other solution as well
so we need a way to get the ~60 threshold, feel like I've seen that before too
if someone opens an issue I'll be happy to do it, probably tomorrow
I need a new way to setup a NS dev environment, I used to do mongo dump/restore on crons to update a test db, but data is too big for that
thx @eyim
Done
In particular, where it affects us is if it has low temped him for a while maybe 2 hours and has significant negative iob then it will try to give him extra insulin to counteract that when in reality it doesn't need to. I had hoped the auto sensitivity stuff would help but I didn't find that
No problem
good to know
I think sometimes the -IOB is really countering pooled insulin
Hello I am dex wixel Paradigm veo User (xdrip+).currently Setting up nightscout.Sticked at making Azure Web Page.my Goal is making asap an aps-Solution. I have two pumps to try Version 2.8 B and Version 3.2 (Which seem to have less Options older SW.) I heard a rumour about Companies in india/china/Israel making an easy to remote access pump (Paradigm Clone).I have Not found the company so far. Max anyone help. PS I wie a Bayer Contour Next. Max I remote Control via Bayer?
FYI - I simply didn't loop last night, adjusted pump & CGM clocks before going to sleep, and started up again this morning and everything seems to be working fine.
Unrelated question - should we periodically
sudo easy_install -ZU openaps to update it?
@jasoncalabrese :+1:
@TC2013 I opened nightscout/cgm-remote-monitor#1545 that I hope will fix the NS OpenAPS alarms you're getting. Also gets rid of the really noisy units warnings.
Sorry my questions seem Not to be answered,are they inappropriate or Simply at the wrong Place asked pls advise...
@TC2013 did that work?
@eyim @scottleibrand, we like that extra (low) threshold idea too.
@benhamou I don't really understand the question, if you don't have a PC Connect screen on your pump it should work, do you have a carelink stick to test it with?
@benhamou also, I have not seen any discussions about Paradigm clones, but that sounds like an interesting possibility.
@jasoncalabrese I just have the Bayer Contour Next. So I Need the carelink Stick to test?
wow. did my 2 hour dexcom reset (did not change sensors or transmitter). Said i was 107 at last reading. now 305. prebolused 5 units for a crissaunt and coffee. WTF!
no idea what is going on...
Maybe the strips/meter?
possible, but i always use the same strips and meter. tested twice, two different fingers.
@tghoward I have Not found a Clone (Paradigm remake) in the Internet Made by chinese/indian/israeli Manufacturer so far, But I heard the rumour. If it existed I buy it also for the Sake.
Sensor restarts can really screws things up
1 more reason I want to start using a wixel
@jasoncalabrese I experienced the same 2day
wish i had tested 2 hours ago
i dont even know what a wixel is
@benhamou I don't think the carelink stick will work with the Bayer Contour Next. I thought you had a Paradigm with version 2.8B on it?
i just am not sure if i was 107 aor 300. i can’t imagine anything screwing me up that much when i took 5u.
@tghoward my pump bas version 2.8B. Now i want to access from my pc. So what do i need carelink or is Bayer also feasible
The wixel is what they use for xdrip, to listen to G4 transmitters, then you don't have dexcoms schedule
@benhamou you need a carelink or a TI stick
Carelink is most documented, but after setup and testing the TI stick has better range
@benhamou the best documentation and the software that is best developed is for the hardware listed here: https://github.com/openaps/docs
https://github.com/openaps/docs/blob/master/docs/getting-started/hardware.md
https://github.com/openaps/docs/blob/master/docs/getting-started/hardware.md
is the wixel different than RL? in the ability to listen?
It's a different frequency
Hmm dumb question, does openaps recognize when a pump is suspended or in rewound mode? I was testing both since I have to replace the set and noticed that I didn't see any update in the status about it
(other than the fact it says rate 2 and duration 0
what does
openaps use latest-treatments shell return for people?
still got my loop crashing there
@tghoward thank u so much
I don't think I have that alias set up
@itsn0tm3 I assume that those states act the same as when the pump is suspended
@scottleibrand Yes, both states are the same
which returns received: false to enacted.json, which gets displayed in NS on the openaps pill as an x or similar.
ah hmm ok, I was thinking there would be a more explicit warning, but I guess it's just more subtle heh
We consider that a "normal" state during showers etc. when pump is temped to zero and then suspended.
makes sense. Was looking through my logs and that caught my eye. Will try to remember that the state means suspended
You'll also see an enacted duration of less than 30 minutes.
nice, finally back looping.
at least now i have a week of CGM without loop data :) did not have that before
57% in range vs 78-80% on openaps weeks
Did you fill out Dana's survey yet? That would be good to include.
@jasoncalabrese My in-laws are in town so I haven't had a chance to load it
Made the decision to switch to ththe wixel from dexcom receiver this week and very happy about it. We were having issues where we would get one or two bad data points and the dexcom would go into ??? Mode but wixel keeps going although you have two bad data points. We prefer that to hours of ???
how much work is it to set up these days?
The hardest part is soldering but given my work on the TI - not too bad
Wouldn't recommend as a first step for people but we were in ??? Mode maybe 5+ hours per day so had to do something.
You have a wixel soldered to the Edison? Our using a normal xdrip device
*or
Normal xdrip
Now very excited about potential with Riley up if has wixel on board
Didn't think it would be on board, but was hoping to have solder holes
Ya that would be nice too
Last time I was trying xdrip having to recompile/flash to checked transmitters was a problem, but think the xdrip can set it now, and there's some new firmware that will help too
I still had to recompile and flash. But I am still on the old xdrip. The newer one had an alarm at 55 that I couldn't turn off that I didn't like to stayed on old version.
So stayed on the old version
I commented out a line for that
We rotate transmitters to avoid the 2 hour wait or even looping with a brand new sensor
Hoping to be and to continue doing that, but will see how long the current transmitters last and when we can get more
What is the calculation 30m temp too get BG down to target ?
starts with bolus calculator math to determine how much insulin would be required to get down to target
then figures out the temp basal required to deliver that much extra insulin over 30m
Has anyone managed to tether the RPi to an iphone using bluetooth?
I've got the old ATT unlimited data plan which doesn't allow wireless tethering.,
@eluhrs yes, I was able to do that with rpi, but not with Edison
I'm interested in the Bluetooth tether trick too. Just got RasPi v3 - think it has BT built in.
@scottleibrand are you able to give an overview of what's involved or point to some documentation?
I started messing with bluez and bluemon, but I don't think the apt packages are working correctly. Can't find any of the sample scripts or binaries. Looks like bluez was refactored at some point so it doesn't match any of the documentation I've found so far.
yeah, docs suck. let me try to find what worked for me
these are most of the ones I used: https://www.google.com/search?q=bluetooth+test-network+nap
ignore anything that wants you to use
pand
@jasoncalabrese look at xbridge wixel code. I think the wiring is slightly different but you put the transmitter is in the Xdrip app not the wixel code
Thanks, @scottleibrand. This is helpful. I'll poke around some more but may have a specific question or two later on.
Is the bolus calculator math the bolus wizard ?
@KJSATSTORR it's basically the same arithmetic, yes. biggest exception is we take temp basals into account, so the net IOB we start with is often different from the pump's IOB