Feedback on Enhanced Trend Calculation

[Brad823]

Firstly, thank you for all the work you’ve put into this integration. It has made a huge difference to our family, giving us far more flexibility than the basic LibreLink app, and it’s genuinely appreciated.
I wanted to share some feedback on the Enhanced Trend Calculation introduced in version 1.3.2. I installed it yesterday and I’m not sure it’s behaving as expected. The trend values appear to be overly sensitive to very recent readings (around the last 5 minutes) and don’t seem to sufficiently account for longer look-back periods.
I’ve included two examples from today to illustrate this.
Example 1
Blood glucose was rising and peaked at around 15 mmol/L at 16:18, then dropped back to roughly 14 mmol/L by 16:20.
At this point, the trend was shown as “Falling Fast”. While I appreciate that there was a ~1 mmol/L drop over 3–4 minutes, this followed a very rapid rise over the previous hour, which may be skewing the trend interpretation.
Example 2
A short while later, at around 16:30, glucose levels were still falling (after some correction units), now sitting at approximately 13.2 mmol/L. However, the trend had changed to “Falling” rather than “Falling Fast”, despite the overall direction remaining similar.
This isn’t intended as criticism—just feedback in the hope it helps refine and improve the application further. I’d be very happy to help test future releases or enhancements if that’s useful.
For now, we’ll revert to the previous release so behaviour matches what we’re used to.
Thanks again for all your hard work.

falling.pdf
fallingfast.pdf

[dodog]

Thank you for the feed back. I appreciate it very much.

The reason why I decided to make the enhanced trend, because the default trend from librelink is not responsive enough. It shows stable all the time, even when the glucose level is rising or falling. There must be a very sudden and major rise or drop to get the librelink's trend to change.

I do not know how the Librelink trend I calculated. So I created a new system which should better represent the future trend of glucose level. It doesn't just take a simple difference; it actively searches recent history for the best data points across multiple timeframes to calculate the most reliable current speed it can.

This is my idea of Enhanced trend

Think of it as a three-stage pipeline:

1. Collect Data
2. Calculate Speed
3. Classify Trend

Here’s a visual overview of the entire process:

Stage 1: Collect History & Calculate Rate of Change

This happens in Rate of Change. The goal is to figure out how fast the glucose is moving right now.
Grab Recent History: It looks at the last ~60 minutes of measurements stored in self.history.
Calculate Multiple Speeds: It doesn't just look at the last two points. It tries to calculate speed over three different time windows for robustness:

• 1-minute rate: How much change in the last ~1 minute? (Most sensitive, gets the highest weight of 3.0).
• 5-minute rate: How much change in the last ~5 minutes? (Medium weight of 2.0).
• 15-minute rate: How much change in the last ~15 minutes? (Lower weight of 1.0).

The high weight on the 1-minute rate ensures the trend reflects what's happening now, not just the average of the last 15 minutes.
Combine into One "Speed": A single, weighted-average rate is calculated from the available windows. This makes the trend more stable than using a single, noisy 1-minute difference.

Stage 2: Classify the "Speed" into a Trend Category

Rate to trend method takes the precise speed number and puts it into a simple, meaningful bucket.
Apply Thresholds: It runs the speed through a series of if/elif statements (the "classifier"):

if speed <= -0.166:          return "FALLING_FAST"   # Very fast drop
elif speed <= -0.0555:       return "FALLING"        # Steady drop
elif speed < 0.0555:         return "STABLE"         # Essentially flat
elif speed < 0.166:          return "RISING"         # Steady rise
else:                        return "RISING_FAST"    # Very fast rise

Get the Result.

Stage 3: Smooth the Final Trend

The Apply trend smoothing method acts as a final filter. It looks at the last few server-provided trend arrows and my newly calculated trend. If, for example, the server said "STABLE" for the last 3 readings but my calculation says "RISING," the smoothing logic might overrule the single calculation and keep it as "STABLE" to prevent a single noisy reading from causing a jumpy trend.

The enhanced system doesn't just look at "it was 7.4, now it's 8.0." It calculates how quickly that change is happening right now (rate), and then uses thresholds to answer the question: "Is this change slow and steady, or fast and concerning?" That's the enhanced trend.

If you want, I can revert back the old style conservative librelink trend and add the Enhanced trend as a separate sensor.
Or we can tweak the weight of speed or thresholds.

I would welcome any suggestions to improve this system.

[Brad823]

Thanks for the all the information. Will take some time and review. For now I've reverted our implementation back to earlier version just because it was working ok for us. Maybe having the option of both the old style sensor available would help, but maybe time to see what other users like?

Thanks again. Much appreciated.