Handling Temp Basal events in NightscoutTreatments.

[jan-rycko]

This is a proposal of handling "Temp Basal" eventType entries from Nightscout.

I'm not Java-native, so NightscoutTreatment class might me the wrong place for it. Yet it's working fine as this class processes treatments anyway.

WIP - as we don't have NS profile yet. I plan to add support for it once I have the gist of how BasalProfile is working. For now there's a 0.15U base hardcoded.

I tested it on Nightscout follower flow. I have yet to test it when xDrip pushes data to Nightscout and loads treatments from it while AAPS loads profile.

I believe this PR will fix:

• Not getting Temp Basals as a Nightscout Follower #895
• Basals / TBR are not showing from AndroidAPS #1593 - adds an ability to send temp basal vie aaps -> nightscout -> xdrip

[wirbel-at-vdr-portal]

Could pls explain any of your abbreviations?
Those are difficult to understand and might be misunderstood.

Thank you.

1. WIP - (work in progress, walking in a park, .. ?)
2. NS profile (netscape communicator profile?, nightscout profile?)
3. AAPS loads profile (American Association of Pharmaceutical Scientists: ... ?)
4. "Temp Basal" eventType

[Navid200]

@wirbel-at-vdr-portal

If you believe that xDrip will be changed in a negative way if this submission is approved, please let's talk about it here.

Otherwise, if you have questions about what different acronyms mean, please open a discussion here: https://github.com/NightscoutFoundation/xDrip/discussions

The person who needs to understand those acronyms in order to review this submission, understands every one of them perfectly.

Thanks

[wirbel-at-vdr-portal]

Hi Navid200,

i think any change request to a software should be 100% clearly understandable without secondary discussions.
If someone would request such way in my repos, i would plain reject.

[jan-rycko]

@wirbel-at-vdr-portal this PR (pull request) is marked as draft. It serves a purpose (possibly just in my head, each person can have their own standards) to state my intent of working on the issues mentioned above related to passing temporary basal from Nightscout to xDrip. When I finish I'll provide more detailed description of the resolution as well as possible issues.

Feel free to reject any pull requests. I'm also comfortable with this PR being rejected as this is not my codebase and I have little-to-no knowledge of standards that @Navid200 keeps. But I'm also open to comments and suggestions that might help me get it working and in a good enough shape to merge. In other case I'll just use fork for my own purposes when I have it fully functional.

WIP – work in progress, NS – nightscout, AAPS – Android APS, "Temp Basal" eventType – one of event types passed from nightscout /api/v1/treatments endpoint.

@Navid200 thanks for answering. I'll be updating this branch possibly in the near future.

[Navid200]

Feel free to reject any pull requests.

No, no one who has posted here so far can reject this pull request.
The only one who can reject it has not reviewed it yet.

Thanks for your submission.
I cannot promise that it will be approved because I am not the one who can. But, based on my experience over the past 4 years, all submissions are reviewed, and he is reasonable.

[wirbel-at-vdr-portal]

Hi jan-rycko,

Sorry for dropping a comment.
Comments are not welcome in this repo, not going to bother anymore.

[jan-rycko]

Ok, so few updates from me.
I cleaned up the solution.

Main part is moved to separate class NightscoutBasalRate to handle temporary basal rate as well as profile to fill the gaps in graph. There should also not be any Refusing to create record older than current... errors caused by handling treatments that were already used before.

There are two new settings:

First one turns on loading of profile and uses treatments to plot TBR. Second one is to load data from Nightscout more frequently – it's up for discussion here if it's too much. I find it very helpful in some situations.

When the first setting is turned on, we also sync xDrip "active" Profile with Nightscout one:

I wrongly assumed that Basal Rate graph behaves similarly to Nightscout one and that it shows Basal Profile with dashed line. It's not – it always show straight line, which means 100% of profile. I suppose we can think of changing that in the future, but it's a case for another PR.

As such, I'll mark this PR as ready and wait for comments from maintainers of this repo.

In the near future I'll try to apply same functionality to NightscoutUploader, but let's try to review this one first.

[asavageiv]

Could the setting be "Nightscout connect frequency" with a default of "every 5 minutes" That way users aren't locked in to the developer choices.

[jan-rycko]

Could the setting be "Nightscout connect frequency" with a default of "every 5 minutes" That way users aren't locked in to the developer choices.

Probably yes, but it should still be min 1 minutes. Anything shorter will be rate limited.

Anyway, still up for debate if such setting is actually ok. Possibly it will influence battery.

[jan-rycko]

Since there is no much movement here, I'll add something that I wanted to try. I added graphical indicator of basal based on profile. Dashed line represents profile, loaded from Nightscout and basal graph is relative to it (or actually – properly scaled absolute value).

Also – current time is represented, without lacking value at the end – graph is shown up to current moment.

Code concerning plotting this data needs to be properly secured for edge cases (at least leaving former behavior as an option or testing is basing this chart on default profile is good enough).

Anyway, I started to work on NightscoutUploader – for it to also load profile along treatments and calculating APStatus, thus allowing to show Basal Rate on chart. NightscoutUploader code is in not-so-good shape, but let's hope for the best.