Fmegen/3.3.0.0 - Adding VeryHigh Overview Display Option

[vanmegen]

This is analog to the nightscout Very High setting which displays bg values higher than a configurable value in a different color.
I did set the default to 400, but it can be set to 240 to be a similar threshold as nightscout uses.

(in the following screenshot red dots mark values higher than 240)

I have added this to the overview settings

as well as to the onboarding wizzard

[MilosKozak]

I kept it without "very high" to match dexcom setting
But I'm open to discussion about this

[olorinmaia]

I prefer keeping red color for lows.

But, default value is set to 400 mg/dl which translates to about 22 mmol/l so I think this is a win / win for everyone. This new setting can be set so high that it won't have affect on the visuals in most cases as we rarely go above 13 mmol\l. Then I can just set it to e.g. 20 mmol/l and it will display like before. Or if users want it lower they have the freedom to do so.

So I think this will be a good change, regardless if you prefer it like before, or want red color for very high.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vanmegen]

@olorinmaia

So I think this will be a good change, regardless if you prefer it like before, or want red color for very high.
Thanks for the comments!

@MilosKozak

I kept it without "very high" to match dexcom setting But I'm open to discussion about this
The reason I added this to aaps is that this display format is one of the defaults in nightscout and quite useful to get at-a-glance information about the current range. like "green" == all good, "yellow" == not-great-not-terrible, and "red" == bad.

here is the corresponding nightscout screenshot

in nightscout, you can set this via environment variable

I agree that this should be the "high" externally (i.e., in the UI), however, internally, the range above 180 is already named "high_value", which is why I used the very_high_value names instead.

should I do any change to the PR?

[Philoul]

Hum, if we want to be fully consistant, we should also review Watch graph (to include the "Very High color") and watchfaces colors for Very High BG...
So probably a bit more work to do.
I should also have to update a bit Custom Watchface code to keep compatibility with Custom Watchfaces V1 for BG color management

[Philoul]

If this proposal is merged, maybe it's better to manage Watch update for color consistancy in a different PR 🤔

[koelewij]

As @olorinmaia already mentioned, setting the "Very High" threshold to a very high value is basically allowing you to disable it would in my opinion, not bother me to implement this.

[vanmegen]

Hi @Philoul

If this proposal is merged, maybe it's better to manage Watch update for color consistancy in a different PR 🤔
I would suggest so too as I dont have a physical watch for testing,

[vanmegen]

Hi @koelewij,

As @olorinmaia already mentioned, setting the "Very High" threshold to a very high value is basically allowing you to disable it would in my opinion, not bother me to implement this.
thanks you for your feedback

[Philoul]

@vanmegen I will manage watch update (with Phone app impact for data communication) on my side.

• I will have to manage compatibility with v1 and v2 custom watchfaces
• don't know if complications are impacted or not

[vanmegen]

Hi @Philoul

@vanmegen I will manage watch update (with Phone app impact for data communication) on my side.
Awesome! thank you very much

@MilosKozak
what do you think? Is it worth merging?

kind regards,
friedel