Open simonp22 opened 3 weeks ago
Looking at the logs the first loop seems to be using a TDD of 1, when my past 24h TDD was actually 70.5U
Using weighted TDD average: 1 U, instead of past 24 h (70.5 U), weight: 0.65
Thanks for the report.
You’ll find the relevant code around here, the oref0 for Trio is in a separate repository (although you’ll also find a copy of the JavaScript code in the Trio repo)
I believe the issue comes from https://github.com/nightscout/Trio/blob/6433d947ac6abffb4e381c32b59662314b65aa38/FreeAPS/Sources/APS/OpenAPS/OpenAPS.swift#L274
My swift is a bit rusty, but looks as if something is causing currentTDD
to be 0. Which could be because I had to reinstall Trio around the 13/08/2024 so don't have the 10 days of data we are looking for on L134
https://github.com/nightscout/Trio/blob/6433d947ac6abffb4e381c32b59662314b65aa38/FreeAPS/Sources/APS/OpenAPS/OpenAPS.swift#L134
You might be onto something here. But why would the result change at the next loop? You’d still be missing the data from ten days ago?
True. However previous to turning on the dynamic settings I was never able to see my TDD anywhere. And TDD looks like it defaults to 0.0
It now appears in the Suggestion/enacted popup since turning on the dynamic settings. Do we know where TDD is first saved to the store? Could it be that TDD does not have a value until after the first loop with dynamic settings on?
The TDD data are stored in Trio/monitor/oref2_variables.json on the phone.
Here is a sample after running with nearly 24 hours of sim pump data (with external insulin added to fake 24 hours of pump history)
{
"duration" : 0,
"isEnabled" : false,
"isf" : false,
"smbIsOff" : false,
"isfAndCr" : false,
"smbIsScheduledOff" : false,
"unlimited" : true,
"uamMinutes" : 40,
"useOverride" : false,
"advancedSettings" : false,
"past2hoursAverage" : 2.75,
"weightedAverage" : 2.75,
"date" : "2024-08-22T11:21:44.990Z",
"presetActive" : false,
"hbt" : 160,
"overridePercentage" : 100,
"overrideTarget" : 0,
"start" : 0,
"end" : 0,
"cr" : false,
"average_total_data" : 2.75,
"smbMinutes" : 50
}
And here is the initial state before running with 24 hours of data (or possibly on the first run, I’m not sure).
Edit: the below is similar to what this file looks like with a clean install, no dynamic ISF and no pump history.
After clean install:
{
"useOverride" : false,
"smbIsScheduledOff" : false,
"end" : 0,
"average_total_data" : 0,
"uamMinutes" : 40,
"isf" : false,
"presetActive" : false,
"smbMinutes" : 50,
"hbt" : 160,
"unlimited" : true,
"smbIsOff" : false,
"start" : 0,
"date" : "2024-08-22T12:25:11.293Z",
"overridePercentage" : 100,
"cr" : false,
"overrideTarget" : 0,
"past2hoursAverage" : 0,
"isfAndCr" : false,
"duration" : 0,
"isEnabled" : false,
"weightedAverage" : 1,
"advancedSettings" : false
}
But I think the raw TDD estimates per loop is being stored to core data, which I don’t know too much about. I did notice that the average TDD values were persisted when I tried to delete the json files.
Someone else will probably be able to tell you more about the core data storage if you can’t figure it out yourself.
Yeah I think what is happening is that the TDD that is fetched from core data doesn't have a value and defaults to 0.
The only place I can see in the codebase where the TDD core data is saved is https://github.com/nightscout/Trio/blob/6433d947ac6abffb4e381c32b59662314b65aa38/FreeAPS/Sources/APS/OpenAPS/OpenAPS.swift#L94
But for that line to be hit, TDD has to be above 0 to begin with.
Confirmed by looking at the logs for the loop before dynamic settings were enabled
2024-08-21T08:03:27+0100 [OpenAPS] OpenAPS.swift - determineBasal(currentTemp:clock:) - 80 - DEV: SUGGESTED: {
"temp": "absolute",
"bg": 194,
"tick": "+13",
"eventualBG": 233,
"insulinReq": 3.1,
"reservoir": 3735928559,
"deliverAt": "2024-08-21T07:03:27.741Z",
"sensitivityRatio": 1.2,
"CR": 6.5,
"TDD": 0,
"current_target": 99,
"insulinForManualBolus": 4.47,
"manualBolusErrorString": 0,
"minDelta": 8.3889,
"expectedDelta": -9.4,
"threshold": 3.9,
"predBGs": {
"IOB": [
194,
198,
202,
205,
207,
208,
208,
208,
207,
205,
203,
200,
196,
192,
188,
185,
182,
179,
177,
174,
172,
170,
168,
166,
165,
163,
162,
160,
159,
158,
157,
156,
156,
155,
154,
154,
153,
153,
152,
152,
152,
152,
151
],
"ZT": [
194,
188,
182,
176,
170,
165,
160,
155,
151,
147,
143,
140,
137,
134,
131,
129,
128,
126,
125,
124,
124,
123,
123,
123,
123,
124,
125,
125
],
"UAM": [
194,
202,
209,
215,
221,
227,
232,
237,
241,
244,
248,
250,
253,
255,
256,
257,
258,
258,
257,
256,
255,
253,
251,
249,
247,
246,
244,
243,
242,
241,
240,
239,
238,
238,
237,
236,
236,
235,
235,
235,
234,
234,
234,
234,
234,
234,
233
]
},
"COB": 0,
"IOB": 3.455,
"BGI": -0.3,
"deviation": 4.8,
"ISF": 1.7,
"target_bg": 5.5,
"reason": "Autosens ratio: 1.2, ISF: 2→1.7, COB: 0, Dev: 4.8, BGI: -0.3, CR: 6.5, Target: 5.5, minPredBG 10.7, minGuardBG 11.2, IOBpredBG 8.4, UAMpredBG 12.9; Eventual BG 12.9 >= 5.5, insulinReq 3.1; maxBolus 0.6. Microbolusing 0.6U. adj. req. rate: 7.35 to maxSafeBasal: 3, temp 0.45<3U/hr. ",
"units": 0.6,
"duration": 30,
"rate": 3
}
You can see that TDD here is 0 and is not calculated until dynamic ISF is enabled in https://github.com/nightscout/trio-oref/blob/363fd116bf69d728502a46f1df0f842a05944c7b/lib/determine-basal/determine-basal.js#L412
Proposed solution in https://github.com/nightscout/trio-oref/pull/31 to always calculate the TDD whether dynamicISF is enabled or not
Describe the bug
Turned on dynamic ISF/CR for the first time. Loop ran. My predicted BG was -1120 and I got a notification saying that I needed to eat 3658g of carbs. When the next loop ran everything was back to normal
Attach a Log
TrioLogs.txt
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A sensible recommendation
Setup Information (please complete the following information):
Smartphone:
Pump:
CGM:
Trio Version:
Technical Details
If applicable, provide any technical details that might help in diagnosing the problem. This could include logs, error messages, or relevant configuration details.
Additional context
Add any other context about the problem here.