Can apps get real-time estimated glucose values (EGVs) with the Dexcom API?
Currently, the Dexcom API offers EGV data on a three-hour delay. The Dexcom API is intended for software developers to retrieve retrospective CGM data and CGM-derived metrics for use in software applications. Real-time treatment decisions should not be made based on the data displayed to the end user, and the delay helps clarify this. Dexcom settled on the three-hour delay after consultation with FDA.
what page did you see that on? I missed it when reviewing their API docs.
perhaps https://gitter.im/nightscout/decoding-dexcom would be a good place to discuss further?
FYI - I just merged 0.6.0-dev into the dev branch. Which means dev branch is packed with new things and HIGHLY experimental, so huge caution urged for testing this branch. At this point, I wouldn't test without looking at the code diff. There's a few notes in the PR (https://github.com/openaps/oref0/pull/650#issue-256564183), but we need some more help with other documentation and flagging other major changes. So, please proceed testing dev with caution, ask questions, and comment on the PR with notes and tips for others as you move forward with testing.
big thanks to @tim2000s @scottleibrand @sulka (for exponential curves work!) & others for all the behind the scenes work on this branch.
SO minor in the grand scheme but was wondering if its worth scribing an issue relating to inability to read SMBs in NS?
Hi. I use xdripAPI and a bluetooth tether to my phone to get my cgm data onto my rig. The cgm data is not being sent and in xdrip+ under restAPI it has 'marking records failed'. Same issue that I had a couple of months ago for which I ended up having to reflash my rig.
@garykidd if you have any ideas for better ways to visualize SMBs, it might be worth discussing...
@tepidjuice - I’ve a new rig setup - let me test it and see. Fwiw when I updated to the latest Code, xdripaps continued to work on my older rigs.
@tim2000s thanks I really have to get a back up rig running. I've ordered the parts can have a test rig.
been trying for hours with no luck now. Because it happens on both rigs is it likely to be a pump problem? It did work showing pump status in nightscout last night for about 30 minutes.
But now i just get the following errors
.mmtune: mmeowlink.vendors.serial_interface.AlreadyInUseException: /dev/spidev5.1 already in use
CommsException("Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?"
@tim2000s if it helps debugging... I think it occurs after updating my rig.
Is dexcom server down?
Temp target question: in the graph above, temp target is 80 and the eventual bg is predicted to be 141. The temp basal was just set higher at 0.85, but this still won't be enough to reach a temp target of 80. In fact, the next OpenAPS pill after this shows that 0.95 is required, but it decides that 0.85 is close enough for now so it doesn't change the temp basal. I'm fine with all this, but I'm trying to understand the logic. If OpenAPS is trying to reach the temp target of 80 and eventual bg is predicted to be much higher than that, why isn't it temping much higher (our maxsafebasal would be 1.05).
If it predicts that it'll end up as 141, how much extra insulin do you think is needed to hit 80?
(I can't remember exactly which numbers it uses, but it's likely it's actaully using 134 in the calculation)
With 0.39 on board and ISF of 175, that would theoretically bring bg down to about 100. So I guess another 0.1 would bring it down to about 80.
134 - 80 = 54 mg/dl. With an ISF of 175, that's a requirement of ~0.308u insulin. To deliver that over 30 minutes, that's an increased in basal rate of 0.616u/hr. Baseline looks like 0.25u, so 0.25 + 0.616 = 0.866u/hr.
That makes sense, but why doesn't it just deliver that through a higher basal rate over a shorter time?
You can only set basal rates in 30-minute increments. If it sets the basal rate higher, it has to manually cancel the temp basal when the correct amount has been delivered. If you walk out of range of the rig, or its battery dies, or there's interference, or ...., then the pump will end up delivering more insulin than it needs to get to the target range, which may cause a hypo
@cjo20 Yes, thank you. That makes perfect sense now.
So when it sets basal rates, it only sets a rate that is safe to leave to run to compeletion
So the limitation is the minimum length of the temp basal
I believe that is what led to the design decision, yes. As the minimum length of temp basal decreases, it approaches SMB.
Just upgraded to 0.6.0 on my dev rig to test today, already like the look of some of the new settings and the log output
We don't use SMB because our lowest basal is too low (0.25) so I'm not very familiar with it. Does it work to correct high non-meal bg, or does it only come into play at meal time?
I don't use SMB myself yet
I use SMB primarily at meal time or on the (lately) rare occasion that I want it to aggressively correct a high
So you could use it either way
@jaylagorio When you say you use it at certain times, does that mean you need to actively engage it? I thought it worked in the background similar to the normal OpenAPS temp basal adjustments.
You have to enable it since it's off by default, and you choose any of three scenarios when it kicks in
When you manually bolus, when you have carbs on board, or when you set a temp target
Got it. Thanks.
I chose COB and temp targets so if I want to manually bolus to do a correction myself I only have to worry about the normal OpenAPS temp adjustments
I assume I need to delete the corrupt file, but I'm not sure how to get there.
Can someone describe the predCIs/remainingCIs entries in the logs during SMB loops?
ReadTheDocs doesn't seem to have a description
jaylagorio: I don't know, I've not looked at it, but I would guess it's to do with carbs it thinks you're yet to absorb, and their impact on blood sugar
Sure, but lack of units is throwing me off. 0.1 carbs remaining to be absorbed? 0.1 units of insulin needed to counteract absorption? That's why I'm looking for more detail.
can you paste an example?
Sure!
predCIs: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
remainingCIs: 0 0 0 0 0 0 0 0 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0
.1 0.1 0.1 0.1 0.1 0.1 0.1 0 0 0 0 0 0 0 0 0
hmm. Not sure. You could probably look at the code and work it out
You're right, and I tend to do that - but I ask here first to make sure it isn't an FAQ or the answer isn't apparent first
update on corrupt git object: it was under myopenaps directory and there were a lot more corrupt files. Changed the name of the directory and am trying the setup script again
@scottleibrand regarding the less than ideal viewability of SMB in NS...the most simple quick fix that I can visualize would be to simply limit the viewed time frame to a smaller duration--most-likely 60 mins.
@mar5477 that git directory will automatically be rebuilt by the system. You don't need to reinstall.
I think that'd create enough space to better see amounts. Of course something more substantial in work could involve plotting SMBs on the basal line---really they don't need to be shown on the commensurate BG level line
@Kdisimone I ran git fsck until I it didn't come back with anymore corrupt objects. But then I was getting "error: HEAD: invalid sha1 pointer" and wasn't sure what to do from there. Googling led me to believe I needed to point back to an okay object, but git pull/fetch/checkout didn't work
@Kdisimone should I just have let time fix things after removing the corrupt objects?
myopenaps# git status came back with "fatal: bad object HEAD"
It depends on where your git corruption was. If it was in myopenaps, I typically do
cd ~/myopenaps && rm -rf .git That will remove the directory and it will be rebuilt by the cron. If that (the rebuild) doesn’t happen automatically, then I would remove the openaps directory too and run the script fresh cd && ~/src/oref0/bin/oref0-setup.sh
cd && rm -rf myopenaps to remove to the myopenaps directory
@jaylagorio those are debugging lines I intend to remove before release rather than documenting. they display the predicted carb impact for each 5m period out to 4h. the units are mg/dL per 5m.
@scottleibrand Unless you plan to have this info in some other format, I think if you wanted to leave them in but add units that'd be pretty cool!
they give me a way to visualize how much of the carb impact is coming from actual observed carb absorption projected out in a
\ shaped predCI curve (the first line) vs. remainingCI that isn't projected to absorb over ~4h and is being projected as part of the /\ shaped remainingCI curve
rm -rf .git looks like it worked? in the meantime, changing the directory name, and running the setup script again allowed the loop to start work again
I like it!
@jaylagorio I think for normal users, looking at the COB purple line prediction in NS gets them the info they need. I think this level of detailed visualization will only be needed as long as I'm playing around with this part of the code
if I decide I no longer need it, I'll remove it. If I fall in love with it and think it's worth the extra space in the pump-loop.log, I'll make it clearer what it's showing. :)
Haha, I think that's a good compromise
Speaking of visualization, I think I'm seeing some lag for what the loop does vs. when it gets to Nightscout. As an example:
- Do the loop, SMB delivers 0.2 U
- Loop finishes. Nothing appears on Nightscout. Refresh Nightscout just to make sure - no change.
- Next time through the loop, Nightscout gets updated.
I've noticed this for basal changes too, the run through the loop when it happens doesn't deliver the change to Nightscout, only the run through after it already happens
@jaylagorio That’s typical NS behavior for DIY looping…a lag from delivery of info to confirm and recording, finally visualization of the info. Happens in Loop environment too.
Yeah, I don't think it's brand new, just more noticeable now that I'm using SMB and trying to eyeball what the IOB is based on Nightscout pills
Is that something that can be fixed?
@jaylagorio not so far as I can see
we would have to add another pumphistory refresh to the end of oref0-pump-loop
I'd avoided doing that until now, but if an SMB was delivered, there's not much else that needs to be done right away, so maybe it'd be a good idea. will have a slight battery hit, but maybe worth it
Can you do a shorter pumphistory refresh when you know you just did a change? Or format the SMB/temp change/etc as a treatment when it happens and deliver that to Nightscout?
we already do a short pumphistory refresh now. no reason to re-do the pumphistory-24h refresh
I don't want to assume something got delivered if it might not have: that's why we wait until it's confirmed present in pumphistory before uploading
one other thing is I'd need to wait until the SMB has finished delivering before refreshing pumphistory. need to figure out how to know how long that is...
maybe I'll just check if it's still bolusing, and if so wait 30s before retrying once:
smb_verify_status || ( sleep 30 && smb_verify_status ) ) && gather
Yeah, agree on not doing the 24 hour history. I think it was written that oref1 does a check of the reservoir, does the SMB, then when the SMB finishes confirms by checking the reservoir again. Would that confirmation not be enough?
But you're totally right that some form of confirmation should be done to make sure what gets pushed to Nightscout actually happened
I didn't know whether temps are double-checked as to whether they were successfully delivered or not. Maybe if the temp is sent and that action doesn't error out that is indicative that it was delivered successfully?
too many additional points of failure if we start guessing about pumphistory contents. would be a pain for deduplicating too. better to just refresh it and see if the bolus/temp is actually there
That sounds best. If you do a short pumphistory refresh I wouldn't worry too much about the battery vs. the load it already puts on the pump and I think the immediate feedback is important with SMB.
I could be comfortable skipping that with temps
:+1:
I guess the pump wearer gets instant feedback on SMBs as they feel/hear the pump. Maybe not amount, but if I need to worry about that, that’s what pushover is for.
scottleibrand @scottleibrand doesn't wear the pump, so I've already implemented this in a branch for my own benefit. :)
Lol
Parents will probably like this too
I've gotten plenty of SMBs without noticing visual or vibration feedback=good thing for me though.
@danamlewis @scottleibrand @Kdisimone How many people have been able to loop with a 512/712? I am at a deadend with my 712. If the number of 512/712 success stories is negligible, would it be better to drop those pumps from the supported pumps list?
sounds like we need a volunteer who could work on getting a 512/712 set up with a dev rig, and make the necessary changes to oref0-setup etc. to support it more automatically
There are half a dozen or so in past two months. I think the challenge is people scavenge and find other pumps that they switch over to, keeping their 12 for backups. Other challenge is not having a volunteer to help test and doc things on 12s.
@thisistheusername the last I saw, your files looked significantly different than the files that the docs spell out. How closely did you use the docs to set up your 512 and rig? As a troubleshooter, it is hard to know where issues may be when people use a method so different than the recommended way. I'd be happy to take a look at things again, have you posted new versions of the files? Did you successfully edit your openaps aliases? Did you set your remote devices to on in the pump and enter a dummy remote ID?
Where is the documentation on the remote id? I asked about that initially but was told it didn't matter.
wondering if it's normal/expected to see increased basals before seeing appearance of SMBs when following normal meal pattern of bolusing a buit upfront...and inverse as it unwinds ..meaning if you had some SMBs as carbs continue to metabolize as BG drops....first you'd see SMBs and then temp basals increase as you encroach on target BGs?
I'm not following. If you don't have a lot of IOB yet, oref0-pump-loop first sets a high temp, and then tries to SMB, and then lowers the temp (eventually down to zero) on subsequent runs once there's enough IOB from the SMBs.
right--you are actually following....
@Kdisimone
@Kdisimone could you point me at the documentation regarding the remote settings for the x12 pumps?
@thisistheusername I don’t have one, and yes, people have said that is not a required step. I tend to do the things people suggest, even when they are “optional” when troubleshooting. I asked you several follow up questions. Can you answer them too?
@thisistheusername also, can you confirm if you were trying to run this with SMB, or just a regular initial setup?
I am testing the 512 instructions, and just confirmed that x12 won't be compatible with SMBs
but fine for regular looping
just clarified in the docs: http://openaps.readthedocs.io/en/latest/docs/Build%20Your%20Rig/x12-users.html
finding some other interesting x12 potential issues, too.
looks like x12 looping was broken with the switch to oref0-pump-loop in 0.5.3, but we didn't have any x12 testers to notice that.
should be fixable though
yep, working on it..
Okay, so I'm trying to get my personal hotspot working again on my iPhone. Looking at the oref0-online.sh script, I noticed that it wasn't finding an IP address for bnep0:
root@binky:~# ifconfig
bnep0 Link encap:Ethernet HWaddr 98:4f:ee:04:1c:ca
inet6 addr: fe80::9a4f:eeff:fe04:1cca/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:67 (67.0 B) TX bytes:276 (276.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:85 errors:0 dropped:0 overruns:0 frame:0
TX packets:85 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12012 (11.7 KiB) TX bytes:12012 (11.7 KiB)
usb0 Link encap:Ethernet HWaddr 02:00:86:27:c3:e5
inet addr:10.11.12.13 Bcast:10.11.12.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr 78:4b:87:ac:5a:e8
inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::7a4b:87ff:feac:5ae8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:409243 errors:0 dropped:0 overruns:0 frame:0
TX packets:419070 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:128221700 (122.2 MiB) TX bytes:53393204 (50.9 MiB)
root@binky:~# ip -4 -o addr show dev bnep0 | awk '{split($4,a,"/");print a[1]}'
root@binky:~#
Scanning over the ifconfig output, I realized I didn't have an ip4 address, and I didn't know how to get one. @scottleibrand , can you tell me what I'm missing, please?
That is, I'm not picking up an ip4 address for BT.
@danamlewis can you extract the number of loopers in .de from your dataset? (either total or even better by type of loop?) I'm going to give a presentation next month and would like to include this information...
always kept updated here: https://openaps.org/outcomes/
Or anybody else who can help. :)
do you mean in germany specifically? @savek-cc
exactly @danamlewis - so the part of (n=1)*401+ ;)
@daveklingler you can try manually running the dhclient that oref0-online does to get an IPv4 address via DHCP
I can skim the list and give you an eyeball account. no good automated way to do it since everyone fills it out so differently. do you want that now, or closer to your presentation?
won't be by loop-type, will just be eyeball count
guess once the ac combo will be supported by aaps it might increase in .de
eyeball right now is fine...
or any time within the next 2 weeks or so - when you have the time
@scottleibrand , ah, thanks, that's what's not happening. I ran dhclient and it pulled an IP. Now I just have to figure out why it's not happening in the script.
@savek-cc ~34
thanks @danamlewis
boo yea! temp set on the 512. and bugs fixed for 512. @thisistheusername if you want to go pull a fresh oref0 master, I bet it'll work now.
(cut the 0.5.4 release to include the x12 fixes)
these instructions do work well still: http://openaps.readthedocs.io/en/latest/docs/Build Your Rig/x12-users.html
(same URL with spaces encoded as %20 so it's clickable)
Howcome the x12s don't work with SMB?
the status checks we rely on don't have the same format status files in the x12
so if someone wants SMB to work with x12, would need to do the work to help figure out suitable alternative for safety checks
That's a shame - do you think that's something that can be overcome or is there data that's straight-up missing?
the suspend/bolusing checks we use for x15/22/23/54 fails on 12s because it has a different status.json
Gotcha
honestly, didn't dig in it too hard - was focusing on a) fixing basics for x12s (done now) and now b) trying to automate the set up process for x12
Yeah, I think those are higher priorities for sure
so if you take alook at what we just changed in 0.5.4, that'll show you where to maybe start digging in if you want to tackle it
I just want to keep x12 in the family for basic looping
Unfortunately I don't have a x12 to bang on
But today with 0.6.0 was actually really good. No meal boluses and I didn't go over 200
nice :)
^^ Graphs with a few annotations
w/ fiasp or humalog/novolog?
fiasp? or just regular insulin?
You guys weren't kidding about the sharp rises and sharp drops now
Novolog U100, regular
ya
oh interesting
Is Fiasp available in the US?
yea on fiasp it's even sharper in both directions. the first few times I overcorrected w/ it on both sides
no
you can order online from pharmacies in canada, though
Well, "regular" meaning whatever I've been using in my pump for 8 years. I think there's actually an insulin type called "regular" and I don't know if this is it
ha, no
It's an orange box and I know it's called Novolog U100
"the usual ole Humalog/Novolog" is what I usually mean by regular
yep
Yeah, that's the one
So I don't have access to Fiasp but I'd be interested in trying it with this
Apidra is also pretty similar. in all three cases we recommend the "rapid-acting" curve
it's valuable to see 0.6.0 tested with Novo/Humalog, though, so will be curious to see more feedback from it
I noticed that the first thing I did today was a meal temp for a bit and that rise was less sharp than the others during today, which I didn't do a meal temp for
did you switch to exp curves, or still bilinear?
But I was pretty aggressive in fighting things down so maybe that's where some of the steep drops came from
https://rxcanada4less.com/ will ship Fiasp to the US
It's still bilinear, I didn't immediately see where to switch it and I figured since it's the same insulin I shouldn't change that
I would recommend switching to exponential curves before relying on no-bolus eSMB
Interesting link! That's a little outside my price range but it's good to know it's possible. I would consider switching after seeing some more info online and bringing it up with my doctor
So there's a knowledge gap for me - what's the difference if it's the same insulin?
there are cheaper options if you (or your mail forwarding service) are in Canada
Just looked up my current type there, they want more for one box than my insurance charges for three boxes, so I think I'm going to stay put for the time being
yeah, if you don't have insurance canada is cheaper, but usually more than copays
It's something I've always kept in the back of my head in case I lose my insurance but I'm glad to have a link people find reputable
I saw the thing about the different curves in the 0.6.0 Issue Dana posted last night but what's the difference between the curve types if the insulin doesn't change? And how do I go about setting a different one?
So I'd use
"curve": "rapid-acting"For Novolog, or is that for Fiasp?