Kt verification/dev33 auto isf plugin

[ga-zelle]

AutoISF Plugin

AutoISF is an extension of the SMB algorithm and modulates the profile ISF
based on certain patterns in the recent glucose history.
The full list of capabilities as available in the current stand-alone-solution is described in https://github.com/ga-zelle/autoISF/blob/A3.2.0.2_ai3.0/autoISF3.0_Quick_Guide.pdf

Most of those features get enabled with this PR with 3 exceptions:

• no automations triggered by or actioned for AutoISF variables; a related PR can follow once this one is merged.
• no sensitivity adaptation based on step count results; this needs step counts from the phone rather than the watch.
  This probably requires a debate first of how to handle and organise secondary data like steps and heart rates.
• exercise mode adaptations work, only the button for quick activation/deactivation is missing.
  This has to wait for potential GUI adaptations.

Behaviour of AutISF in this plugin was verified against my APS emulator
and results align with current stand alone AutoISF.

Port of javascript to kotlin

• DetermineBasalAutoISF.kt was developed based on DetermineBasalSMB.kt and is already included.
• The jsons included (23.Dec., 5.Jan., 6.Jan.) for AutoISF passed the ReplayApsResultsTest

Acknowledgement

A big thank you goes to @Philoul for continued consultancy, for setting up the basics of
the plugin structure and for extending the "kt versus js" test struture
so I could include AutoISF in both.

[sonarcloud]

Quality Gate failed

Failed conditions

20 Security Hotspots
3.5% Duplication on New Code (required ≤ 3%)
C Security Rating on New Code (required ≥ A)
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[jbr7rr]

How different is this version of autoISF from the previous version which was based on 3.1.x? I have tested that before but I'm very wary to have that for a wider audiance as I found that misuse of the settings can lead to severe overdosing. Also I found the settings to be hard to understand.

If this version is improved and addressed these concerns I'd like to know and will test again

[Philoul]

@jbr7rr This version is included in a dedicated plugin (it's not the case in previous version of autoISF) and can be used only after beginning of objective 11 (so definitivly not for beginners, you must be skilled users).
This PR also limit usage of this plugin to dev version and engineering mode only. (we will see later if this proposal is merged within dev branch, with @MilosKozak , if it can be included within master for wider range of users, and the associated limitations if necessary).
Note that your comment associated to misuse of settings is applicable to all APS plugins especially for DynISF.

I let @ga-zelle complete my first answer...

[ga-zelle]

I agree with what @Philoul said. Before it becomes part of a master release dedicated objectives need to be implemented. Only then can the range of parameters be widened to allow its use in Full Closed Loop mode as advocated by BerNie. Intially, in dev mode objective 11 is a good start as it ensures experience with loop and SMB. For production use specific knowledge should be proven on how it works for which objective 11 is clearly unsuited.

Don't forget that even without Full Closed Loop and with a narrowed range of parameters it offers clear improvements .

[ga-zelle]

outdated, see later PR