GarmingPlugin local server at /sgv.json endpoint returns constant tbr:0

[suside]

Just like in the title, tested on Android Pixel+Spirit Combo and emulator+virtual pump, latest version of AAPS 3.3.1.0

Whatever the temp basal actually is, the endpoint will always return 0.

Current behavior, given basal rate 90:

GET http://127.0.0.1:28891/sgv.json?brief_mode=true&count=1
[
  {
    "tbr": 0
    // other fields irrelevant
  }
]

Expected behavior, given basal rate 90:

GET http://127.0.0.1:28891/sgv.json?brief_mode=true&count=1
[
  {
    "tbr": 90
    // other fields irrelevant
  }
]

Simple POC fix I did is just a copy & paste from XDrip plugin like so:

--- a/plugins/sync/src/main/kotlin/app/aaps/plugins/sync/garmin/LoopHubImpl.kt
+++ b/plugins/sync/src/main/kotlin/app/aaps/plugins/sync/garmin/LoopHubImpl.kt
@@ -89,8 +91,8 @@ class LoopHubImpl @Inject constructor(
     /** Returns the factor by which the basal rate is currently raised (> 1) or lowered (< 1). */
     override val temporaryBasal: Double
         get() {
-            val apsResult = loop.lastRun?.constraintsProcessed
-            return if (apsResult == null) Double.NaN else apsResult.percent / 100.0
+            val tbr = processedTbrEbData.getTempBasalIncludingConvertedExtended(System.currentTimeMillis())?.rate
+            return if (tbr == null) Double.NaN else tbr / 100.0
         }

     override val lowGlucoseMark get() = profileUtil.convertToMgdl(

Unit tests didn't catch that because they are mocked at higher level.

Should I create PR? Please advise, have a nice day 🙂

[MilosKozak]

@swissalpine

[swissalpine]

I can't reproduce this problem, as I have already changed it for myself privately.
The reason was not that the function did not work, but rather the occasional deviation from the real values.
Because here @buessow used the result of the algorithm, not what actually arrives at the pump. For example, despite disconnecting the pump, the calculated TBR is output, e.g. 280%, although running a zero temp is running.
I have therefore set the overview data as a string for myself.
I can live with the fix, but I don't know what @buessow thinks, who, as far as I know, also uses this data.

[buessow]

Thanks for adding me @swissalpine and proposing a fix @suside. I don't really understand why my implementation doesn't work (anymore?) but anyway, it would be great if you'd fix it!

[suside]

Thanks for the feedback guys, PR on the way.