These are chat archives for nightscout/intend-to-bolus
hello... I'm not sure what I did... but hoping didn't screw anything up. Was looking up preferences and think I went into edit-pref vs cat-pref... I didn't think I made any changes and accidentally canceled out of session. This is what popped up when I went into edit-pref again...
Found a swap file by the name ".preferences.json.swp"
owned by: root dated: Tue Sep 5 22:35:34 2017
file name: ~root/myopenaps/preferences.json
user name: root host name: johnny5
process ID: 30211
While opening file "preferences.json"
dated: Sun Jul 30 20:37:08 2017
(1) Another program may be editing the same file. If this is the case,
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r preferences.json"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file ".preferences.json.swp"
to avoid this message.
Swap file ".preferences.json.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:
When I went into cat-pref nothing looked changed...advice? Sorry...so newb :worried:
I'm not sure how to read the timestamp but I used tails (-F) to see if new entires are being added and I'm seeing these:
"direction": "NOT COMPUTABLE",
and in cgm/glucose.json
"direction": "NOT COMPUTABLE",
Hi! I need some help to adjust an uncommon setup of OpenAPS for my son.
He has many emotional highs (very high, 350 md/dl and above). But we must not treat it with insulin because when emotional ends, he go quickly low (without extra insulin). He has emotional highs almost every day at school (not if we are at home) and I wish OpenAPS doesn't add insulin when he is at school (from 9:00h to 13:00h).
I have tried to reach this behavior defining a BG target range for that period from 170 to 300, but OpenAPS reports 185 mg/dl as target and then puts extra basal. Any other has a similar situation of deactivate adding insulin at certain periods of the day? I do not want to lose the ability to suspend the infusion if a low is predicted.
Well, I’m at my wits end. For the life of me, I cannot figure out how to tune the OpenAPS to handle the extreme aftereffects of very high fat meals on my son’s BG levels.
Previous to the OpenAPS, we know that almost exactly 2 hours after eating a high fat meal, my son’s BG would steadily rise upward to a 300 – 400 BG if we didn’t put in a an 8 hour/150% temp basal (immediately after finishing a high fat meal). If we missed putting on a temp basal after the meal, he would become super insulin resistant and we would have to give 2x corrections several times to get him back down until the 150% temp basal kicked in. Generally, if we got the 150% temp rate on right after the meal, this would work well and keep him in range for the ensuing 8 hours. Unfortunately, with the OpenAPS, it reacts too slowly and gets behind the 8-ball and 2 hours after a high fat meal, his BG goes through the roof (see below picture and similar rise the previous day in the 24 hours view). The OpenAPS does kick in with maximum temp basals when the BG rises but it is too little/too late and we end with very high BGs for the next 3-5 hours. We have to give manual corrections to help things along which subsequently causes the OpenAPS to counter with a lower temp rate (which is exactly what we don’t want) and things ultimately see saw for the next several hours.
Per Dana’s @danamlewis suggestion, I changed the pump’s max basal rate to 4.5 and tried changing the “current_basal_safety_multiplier" from 4 to 4.5 and to 5. And set the “max_iob to 4 and 4.5”. I have also set temp targets to 80 before and after these high fat meals to help things along. Unfortunately, none of this has worked well. On the contrary, these changes have actually caused considerably more hypoglycemic events during other times and have done little to smooth out the initial quick rising BGs 2 hours post high fat meals.
It seems to me that a prerequisite to deal with these high fat meals is that we need to have some type of temp basal rate kicking in right after the meal. So, 2 hours later, the extra insulin needed for the increased insulin resistance (or a much lower ISF), is ready and waiting and stops the rise. Thereafter, the system will need to maintain a higher temp basal for several more hours to deal with the impact of the triglycerides/fat on his BG. Perhaps a switch that can be set to indicate a high fat meal has been consumed so the OpenAPS knows the person’s insulin resistance is very high for the next 6-8 hours.
Any and all help with solving this maddening dilemma would be greatly appreciated!
@scottleibrand Re-reading what Dana said, I do think she was suggesting both adding carbs AND also a bolus,
"...That would give you more bolus up front, which is what it sounds like you need given initial rise? and "It may be easier to add 1-2u (or whatever number you decide is beset) to a fatty/protein dinner"
That said, i am wondering if your idea of just adding the equivalent carbs would work and would be enough where the AMA could actually counter the rise with high temping. It would seem to be the equivalent to setting a manual temp rate, yes?
@scottleibrand Ok, we will try entering ONLY a carb equivalent for the fat (i.e., no bolus) along with the normal carbs and bolus and see how that works at smoothing the initial rise.
It would still be great if this could be automatically managed by the OpenAPS so we don't have to be thinking about the fat in EVERY meal. As I said, the goal with moving him to a closed loop is to reduce the load. Wondering how the other closed loop systems are handling the rise and sustained insulin resistance due to high fat / protein meals.
@cbrenner we (my daughter is 15yo with t1) do have to manage proteins and fats. She definitely can't eat just even plain chicken without needing insulin. Prior to looping, we tried to find a ratio based on protein type and grams of protein/fats. It's just never worked out well. Way too complex and I just wasn't interested in that much work when the results still came out varied for other reasons (that seems to be the diabetes way). So, instead...we just sort of learned over time how much to eyeball equivalent carbs of certain things...a hot dog is about 5g, each egg is 3g, a heap of shredded chicken is 6g, a chunk of red meat about 8g.
It's not super tight estimates as a result of eyeballing things, but overall, it's worked well over time. The conversations usually go like this now:
Me: how much does the package say?
Anna: 35g grams, but I'll probably round up to 40g
Her rounding usually is just based on enough experience with similar types of food in the past or past spikes from same food.
Things get a little complicated when fats are significant though because all the behavior changes for when we can bolus for those extra grams. So she needed help on OpenAPS to know how to split those total carbs up best (we prebolus 20 minutes for first part of bolus for a meal...usually did second part of split after finishing the meal). We found that once we hit about 4-5 hours though with meals...if carb absorption was still going, we'd need to enter in more carbs to help OpenAPS realize more absorption was still happening (aka the algorithm had decayed the carbs a little too quickly) to help the system keep control.
git pullfirst to bring in the 0.6.0-dev branch and then check it out.
npm run global-installtoo