Merge 0.6.0-dev to dev for eventual 0.6.0 release #592
Conversation
Number one error for beginners that blocks looping is when people don't have the pump set to absolute u/hr (in % basal type instead), which prevents the rig from being able to set temp basals.
* echo status * try preflight twice * check radio 10x, and mmtune if all checks fail * echo Preflight when starting it * mmtune 30% of the time * it's ok if refresh_profile or refresh_pumphistory_24h fail * Revert "check radio 10x, and mmtune if all checks fail" This reverts commit 6ea8637. * remove extra any_pump_comms debugging * removing duplicate 30s wait_for_silence before mmtune * show just last line of any_pump_comms 1 output when Radio check fails * check radio thrice * echo "Done waiting for rigs with better signal." * case-insensitive grep to match 'Comms with pump detected' too * print when preflight fails * retry radio check one more time * exponential backoff on Radio check * echo -n . when retrying Radio check * print any_pump_comms output when it doesn't succeed * ignore mmeowlink-any-pump-comms.py exit code and just check output * reduce debugging
…r zombie-carb safety
…ir-own' into 0.6.0-dev
scottleibrand
force-pushed
the
0.6.0-dev
branch
from
72a60d9 to
279750d
Compare
* remove unneeded stuff * reverse order to glucose_data to process oldest data first * exclude meal periods from autosens using autotune logic * add parentheses around meal periods * split cob-autosens into two separate files * split cob-autosens into two separate files * tag meal periods with carb amount or u(), and exclude avgDelta >= 6 * pull 24h+ carbhistory data for cob-aware-autosens * refresh pumphistory-24h more frequently now that autotune is faster * consider 60-70% Edison battery as charging * round COB for display * use carbhistory.json for autosens * use Math.round() not round() * don't use >24h-old carb treatments * don't interpolate missing data points for autosens * inputs.mealTime is only set in cob.js, not autosens.js * remove stuff that depends on mealTime * remove COB/UAM stuff that depends on ciTime * fix backwards logic * remove unused line * rename autosens main function * clean up autosens stuff from cob.js * fix to lastbgTime calc to properly bucket data from 2 receivers * only use last 8h worth of non-meal deviations for autosens * cleanup * remove bucketed_data[0] and properly filter meals before lastSiteChange
* carbs: should only include carbs actually used in calculating COB * remove old unused mealAssist boluses field
|
I've noticed that the upload to Nightscout shows all insulin given by oref1 as SMB in the OpenAPS pill as Basal IOB. Would it make sense to separate out Basal IOB from meal specific Bolus IOB in the pill? |
|
How exactly are you thinking we'd separate them out? The only real function of the bolus vs. basal IOB is to decide whether to bolus snooze. If you recategorized SMBs as boluses, that would trigger bolus snooze, which would sometimes prevent oref1 from zero temping after microbolusing. |
|
It was more an information point. Most people are used to a bolus/background model, and this changes the thinking paradigm yet again. It may simply be that we need to document what's going on carefully. |
|
I've just updated to include the latest commits. I've been noticing some slightly frustrating patterns, but I'll wait to comment until I've run with this for a couple of days. |
* use profile.sens instead of autosens-adjusted sens * model remainingCarbs as a /\ shaped bilinear curve * typofix * wait 90m before setting minCOBPredBG * if IOB covers less than half of COB, microBolus 1/2 the insulinReq * syntax * logging cleanup * consider BG predictions out to 4h now * make SMB maxBolus configurable via maxSMBBasalMinutes * fix variable reference * fix variable reference * debugging * debugging * remove extra variable * debugging * fix math * still SMB 1/3 of insulinReq if that's more than halfMealInsulinReq * only allow more than 30m of basal as SMB when COB is uncovered * if IOB covers more than 3/4 of COB, limit maxBolus to 30m of basal * if IOB covers more than 3/4 of COB, limit maxBolus to 30m of basal * default to 30m if typeof profile_data.maxSMBBasalMinutes == 'undefined' * default to 30m if typeof profile_data.maxSMBBasalMinutes == 'undefined' * round mealInsulinReq * fix debug output * ignore bolusing status if pump is suspended * use insulinReq/2 up to 2/3 of COB, and maxSMBBasalMinutes up to 100% * allow SMBs every 2 minutes * microBolus 1/2 the insulinReq if IOB covers less than 3/4 of COB * if IOB doesn't cover COB, microBolus 1/2 the insulinReq * debugging * debugging * debugging * predict IOB out to 4h, regardless of DIA * debugging * cid debugging * limit cid to 4 hours: the reset goes to remainingCI * remove extra debugging * remove extra debugging * cid debugging * fix cid formula to end after 4h not 8h * debugging * for purposes of categorizing boluses as SMBs to add to basalIOB, use max_daily_basal
* remove avgDelta-bgi < 6 check * use x for excluded now that we're not doing > 6
Conflicts: package.json
scottleibrand
changed the title
…#644) Autotune: calculate CR directly
* make 2h remainingCIpeak and 4h remainingCATime a variable * adjust remainingCATime based on temp target * clearer logging output
|
This is ready to merge to dev whenever @danamlewis is satisfied that we have things well documented enough for general testing. |
|
I think we need a lot of warnings in there. Over the past few days I've been seeing a lot of post prandial rises of 110+ mg/dl. It's almost always the same phenomenon and pretty much always comes with food with a higher fat content. When a meal is announced, the 50% load gets done quite quickly, then it pauses whilst there appears to be a period of no increase in glucose level. I then see a later absorption, for which there is not enough IOB, and the kick up starts. This is often at the point where the Fiasp peak has passed by about 30-60 mins, and as the earlier dose has not started to bring glucose levels back down, the new rise has a higher starting point. I've also found that when I stack carbs (with about an hour between them) it often struggles. I'm using SMBBasalMins=90 at the moment. |
|
Warnings on what? We won't be encouraging people in the documentation to try no-bolus just because they're using 0.6.0. If people want to try reducing or eliminating boluses in certain situations, they certainly can. They'll undoubtedly still get better outcomes with partial manual boluses, but that is a tradeoff against usability. |
|
I think it's worth being aware of the kinds of questions that will get asked in looped and how those should be handled. |
|
Adding notes for 0.6.0 dev update relating to Exponential curves: Exponential Curves
In order to use the rapid-acting or ultra-rapid curves, your pump must be set to 5 hour DIA, or longer. 6 hours is recommended as the starting point. The details of the curve calculations and discussions can be found PR #568 |
|
If your pump DIA is set to less than 5h, and you turn on exponential curves, oref0 will use 5h as their DIA without complaining. |
|
Enhanced SMB (eSMB) The default behaviour for SMB is that the max bolus that can be delivered is no greater than 30 mins of basal insulin. An additional preferences value, "maxSMBBasalMinutes", has been added to allow SMB to deliver a different amount of insulin as an SMB. This gives the ability to make SMB more aggressive if you choose. As with standard SMB, it is triggered by temp targets, carb entries and a pump bolus. Increasing "maxSMBBasalMinutes" will allow the SMB functionality to deliver more insulin, earlier in the SMB process. "maxSMBBasalMinutes" can be added into It is not recommended to set this value higher than 90 mins, as this may affect the ability for the algorithm to safely zero temp. It is also recommended that pushover is used when setting the value to be greater than default, so that alerts are generated for any predicted lows or highs. |
|
I'm running a clean install from flashing the Edison through installing everything, including totally fresh Bluetooth. Will let you know how it goes. |
|
Clean install worked very well. From nothing to 0.2.0 + OpenAPS fully looping in about 45 mins. Pulling data from Night Scout only. Need to test the xDripAPS setup with a clean install. |
|
TY @tim2000s for the starter notes and for the confirmation of clean installs. merging to dev for further testing. |
No description provided.