nightscout
Feature Request: Activity-/Illness-aware DynISF scaling
Description
DynISF adapts ISF based on recent TDD (7-day avg, yesterday, 8-h extrapolation). This works well on “normal” days, but atypical days can distort the calculation:
High activity days → TDD is lower (some carbs not logged, much COB absorbed directly in muscles). DynISF interprets this as higher sensitivity (stronger ISF). Later, when activity ends, ISF may be unrealistically strong. Illness/stress days → TDD is higher (insulin resistance). DynISF interprets this as lower sensitivity (weaker ISF). Later, when illness ends, ISF may be unrealistically weak.
These are not rare edge cases but recurring situations for many users.
Existing Analogy
The Autotune plugin already allows excluding specific days from analysis (e.g. weekends, outliers). A similar mechanism for DynISF would prevent atypical days from skewing sensitivity.
Expected Behavior
- Allow manual exclusion of selected days from DynISF TDD averaging.
- (Optional) Allow weighting or automatic outlier detection (e.g. if TDD deviates > X% from baseline).
- If too many days are excluded, DynISF should fall back to its standard logic.
Benefits
- Prevents ISF from drifting unrealistically after activity or illness days.
- Keeps DynISF closer to baseline needs → improves loop safety and reliability.
- Gives users more trust and transparency in DynISF behavior.
Thanks for the input, Milos – adjusting profile percentage is indeed a helpful workaround to modulate DynISF impact in the moment.
However, it doesn’t solve the root issue I’m trying to address: if atypical days (e.g. high activity or illness) distort TDD, the resulting ISF calculation becomes inaccurate before any profile percentage is applied. This means the baseline ISF estimate itself is already skewed.
For example:
After a high-activity day, TDD is artificially low, DynISF overestimates sensitivity, ISF is too strong, and there's a higher hypo risk post-exercise.
After illness or stress, TDD is inflated, DynISF underestimates sensitivity, ISF is too weak, and there's a delayed hyper risk once things normalize.
These are not rare edge cases – they’re quite common in real-world use, especially in kids, athletes, or those with fluctuating routines.
That’s why I’m suggesting a way to manually (or optionally automatically) exclude specific days from DynISF’s TDD averaging, similar to how Autotune allows outlier exclusion. This would prevent atypical days from distorting the ISF baseline, increase user trust and transparency, and improve loop predictability and safety.
I see value in your workaround for short-term mitigation, but a more robust solution would be to prevent the distortion in the first place.
Well DynISF is designed to save your work. If your lifestyle prevents you from using DynISF, switch back to SMB. Making something simple more complicated again doesn't make sense to me
Especially with children ISF testing is a difficult thing. DynISF makes things easier. However. I do actually know if a day will mess up future calculations and it would improve overall performance if you know to exclude such a day for better performance. It actually wouldn't get more complicated form the user perspective, but it would ad an option you can choose to take advantage of it or not. In my case I would take advantage of it for sure.