Persistent High threshold fix

[Navid200]

This PR fixes two issues I caused adding Persistent High threshold (#3704).

1- You can enter any value as persistent high threshold.
This PR rejects all values that are outside the 40-400 mg/dL range.

2- If xDrip is already installed and mmol/L is selected and xDrip is updated to our latest Nightly (2024.10.11), the threshold will be set to 170 mmol/L.
The user will need to change units to mg/dL and back to mmol/L to correct that to 9.4 mmol/L.
This PR does the correction automatically.

[Navid200]

This is the third PR I have opened to address this. The previous 2 had problems and I decided to just close them:
#3729
#3734

However, you provided valuable advice and direction in those PRs. Thanks for that.

[Teute0815]

Hi again @Navid200
I stumbled upon this by chance. I requested adjustable thresholds for persistent high alerts a long time ago and remember us two having a discussion about it. #2091

I'm happy, that is happening now, but I would have (already had back then) an addiontal request - and while you're at it, it might be easier to apply:
My only use for persistent high alert is at night, when I don't want to wake up my partner. So I would wish for a time plan (just like the standard alarms) for persistent alarms as well.

Would that be possible/easy to apply?

[Navid200]

@Teute0815 No, it is not easy to add.

The next item on my list of the required changes to alerts is to find a way to make these alerts use volume profile.

I don't believe time of day has a purpose that cannot be addressed by other means. In return, it brings in many recipes for disaster. Of course, I am not the only developer. Others can add it.
If you like to have a conversation, I suggest opening a discussion because it can derail the PR.

[Navid200]

If someone has selected the mmol/L unit and has entered an unreasonable value of for example, 70mmol/L for their persistent high alert threshold, after this PR after they restart xDrip, their threshold will be converted to 70 / 18 = 3.9mmol/L!

I wanted to add a conditional to check the setting for having been changed and act accordingly. The problem is it will require dealing with the specific setting. I would like to avoid that so that I can easily use everything for the forecast low alert after this is settled.

What do you think?
This is what I suggest:
After this is merged, I will post in facebook as well as in GitHub asking users to verify their threshold to make sure it is between 40 and 400.

Even though this is not a perfect solution, I feel it is reasonable. This is why:
The worst scenario is that someone misses my post. Their threshold is changed to a low value of 4mmol/L. As a result, they will get a persistent high alert. This will force them look and hopefully they will see the low threshold.
It would be unacceptable if someone ended up with a very high threshold. That will never happen.
So, I am happy with this as is.

[Navid200]

I can add a method to IdempotentMigrations, with a parameter to check the setting.
If the setting is outside the range and it has never been changed, it must be mg/dL default and mmol/L must be in use. So, in this case, the method just converts from mg/dL to mmol/L.

On the other hand, if the setting has been changed and it is out of range, the method will limit the value without conversion and issue a notification to inform the user.
So, if the value is above the max, it will be set to the max and if it is below the min it will be set to the min.

The method call will require the inclusion of the setting key.
We can have a list of settings that will require this check at startup. Currently, the only setting that needs it is the persistent high alert threshold.

If we some day add a forecast low threshold setting, we will have to add it to the list in IdempotentMigrations.

---

But, I prefer that we leave it as is. This PR as is resolves the problem. If we some day add a forecast low threshold, there will be no need to correct anything.
Please let me know your preferred approach.

[Navid200]

@Teute0815 Yes, all posts that have no tag address the owner of the repository. PRs are extremely critical and I would appreciate it if you don't use PRs for conversations. We opened the discussions for that.

[Navid200]

@jamorham If you merge this, I can continue to improve it if needed.

You did not want me to use handleUnitChange except when the user changed units. I can address that. I can add a simple static method in IdempotentMigrations to address a threshold setting that is greater than the max. This will address both the default conversion at installation when setting is mmol/L as well as those who have changed the setting incorrectly before this is merged.

I just don't know how important this is for you and I don't want to delay this any longer because we are taking the chance of more people entering a value out of range.

[Navid200]

I am opening two smaller PRs hoping that they will be easier to review. And if one is not good, the other will hopefully not be held up.

[Navid200]

These two PRs should do everything we need:
#3765
#3767