Skip to content

Conversation

@trixing
Copy link

@trixing trixing commented Mar 10, 2017

With this settings the Bolus and Basal recommendation will be limited to a certain amount of Insulin. It does not reject a Bolus above this amount if manually entered in the Bolus view. If an exceeding amount is detected, the Basal rate will be set to the default rate.

[first pull request on github, please be kind]

@trixing
Copy link
Author

trixing commented Mar 10, 2017

In case it is not obvious, but this is factored out of my master branch at https://github.com/trixing/Loop - that's where the merge conflicts come from.

Copy link
Collaborator

@ps2 ps2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @trixing. I think there is going to be some work to get ready to merge. I hope the number of requests doesn't put you off; we really appreciate you working on this!

So I've added some inline comments to the code, and have a few general remarks as well.

It's seems like the code is validating current IOB, not the potential IOB from enacting a dose. You could be at max - n but then allow a dose that puts you > max. It seems to me that this feature should be preventing that. I think it's ok to let a user override that, but we should not ever recommend a bolus that would put them over max.

case GlucoseTargetRangeSchedule = "com.loudnate.Naterade.GlucoseTargetRangeSchedule"
case MaximumBasalRatePerHour = "com.loudnate.Naterade.MaximumBasalRatePerHour"
case MaximumBolus = "com.loudnate.Naterade.MaximumBolus"
case MaximumIOB = "com.loudnate.Naterade.MaximumIOB"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New defaults keys should have the com.loopkit prefix.

)

XCTAssertEqual(0.0, dose)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be tests around the case when maxBolus is nil

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And also for when a low temp is needed but IOB is above max

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should validate that it still low-temps correctly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should happen for maxIOB = nil? throw an error like all the other missing preferences or not have a limit?

return vc
}

static func maxIOB(_ value: Double?) -> T {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setting VC should have explanatory text to explain how the feature works and that it can be left blank to disable the feature.

@trixing
Copy link
Author

trixing commented Mar 13, 2017

"It's seems like the code is validating current IOB, not the potential IOB from enacting a dose. You could be at max - n but then allow a dose that puts you > max. It seems to me that this feature should be preventing that. "

Are you referring to the temp basal or bolus calculation?

For the temp basal calculation:
here
if iob > maxIOB {
I guess you want me to check against (iob + determinedRate/2)? To be even more correct I'd also need to pass in the lastBolus as long as it is non-nil?

For the bolus calculation - I think that already takes the last basal rate into account. I guess I should take the lastBolus amount into account here as well?

Thanks for the feedback.

@ps2
Copy link
Collaborator

ps2 commented Mar 18, 2017

Please re-open this as a PR against dev.

@ps2 ps2 closed this Mar 18, 2017
@scottleibrand
Copy link

@ps2 If you're not already aware, Github recently added a feature that lets you (as the maintainer) change the branch a PR targets, via an edit button at the top. That lets you preserve all the comment history while still getting it retargeted as needed. Not sure if that's what you need in this case, but it took me quite awhile to figure out that feature existed, so not sure if you know about it yet.

@ps2
Copy link
Collaborator

ps2 commented Mar 18, 2017 via email

ps2 pushed a commit that referenced this pull request Jun 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants