Looks like you didn't get the log file by email because it was too large. It failed because the basal profile it's taken from your NS has a single 0 rate, and as Autotune works by multiplying your existing basal rates by different factors it can't work when the starting point is zero. Update your profile in NS first with your actual current basal rates and try again.
with autotune web it looks like it uses the currently active profile, would it be possible for it to use the profile that was active at the time/offer a selection of profiles to use? and any possibility of choosing dates to look at rather than previous x days?
thinking I may have to run it on my own machine to look at particular days if I want to use it now that i'm using aaps with automatic profile switches
thinking I may have to run it on my own machine to look at particular days if I want to use it now that i'm using aaps with automatic profile switches
Hi. I have some questions re:
Found at least 1h of carb absorption: assuming all meals were announced, and categorizing UAM data as basal. the issue is - I have NOT announced any meals = I have not entered any carbs. I get this while running autotune with both --categorize-uam-as-basal=false and --categorize-uam-as-basal=true.
let me try again starting 2/9, just to see if that changes things.
Thank you!
(That's using AutoTuneWeb.)
Hello all, one of the rigs we've been using for months started having issues. It doesn't seem to stay connected to WiFi for long after restarting. I couldn't hunt down the issue so I thought I'd just start the rig fresh to see if that fixes it. What do I need to do to start over? Just erase the microsd card?
I have been using AutotuneWeb a few times a week for several months now. About 4-5 days ago I started getting error "An error occurred while processing your request." after I chose my carb ratio and enter my insulin type, email address, etc and click the green "run now" button. I'm surprised nobody else seems to be mentioning this issue. Is it really just me?
Hi! I use edison medtronic 722 and enlite, oref version 0.7.0. When working in offline mode, the entire chart and BG values are not visible on the web page. When you click on the BG icon, data from OpenAps is visible. How do I set up an offline web page, I need it for Hiking when I don't have access to nightscout. Thanks https://s.amsu.ng/xqCQWpYIxyxN - this is my offline page
Does anyone know if it is possible to use the Nightscout bolus wizzard instead of the bolus wizzard on my Medtronic Paradigm 754 pump. I recently turned SMB and autotuning on and that part works fine ( I see the SMB's on Nigtscout and on my pump) , but as I have read in the OpenAPS docs, when you use the pums bolus wizzard, SMB stops for 6 hours.... When I use the Nightscout bolus wizzard, I see the dot Carbs / Units of Insulin (but no Percent delivered: 100 % like on SMB dots) on my NS graph, but I don't see any changes on my pump... Did I got this correct? Is it possible to use NS bolus wizzard on my Medtronic 754 pump at all?
@MarkoJ1974, no you can't use the calculator from NS to bolus. You have to do it manually from the pump. Another way could be to let openaps smb to do his job and you must enter just carbs you eat in NS without bolus. This way openAPS will see that has COB and no IOB and will bolus for you.
Hello,
I'm trying to use autotune on a virtual machine. I installed latest master version (but no loop running, because it's only for autotune).
Autotune works but impossible to change insulin (I tried to use --tune-insulin-curve with a specific insulinpeaktime in pumpprofile.json, I also tried to create a preference.json file with "curve":"ultra-rapid" inside, but I always have same results...).
Can someone help me please ?
I'm trying to use autotune on a virtual machine. I installed latest master version (but no loop running, because it's only for autotune).
Autotune works but impossible to change insulin (I tried to use --tune-insulin-curve with a specific insulinpeaktime in pumpprofile.json, I also tried to create a preference.json file with "curve":"ultra-rapid" inside, but I always have same results...).
Can someone help me please ?
Hey all, i'm looking to sell/give away some of my old openaps hardware. Please contact the Craigslist email if you are interested. Thanks! vancouver.craigslist.org/van/sop/d/vancouver-openaps-rigs-intel-edison/7118818276.html
I've been playing with the autotune webservice https://autotuneweb.azurewebsites.net/ a bit. My first two runs of 7 and 15 days were successful. Then I tried 30 days, which came back with an error and now it seems that irrespective of the number of days it leads to an error. Here's a log of a failed 7 days try: https://www.dropbox.com/s/63r5fao8dlfx0of/autotune.2020-05-06-171240.log?dl=0
@ArthurusDent I'm not a specialist of Autotune (but I'm working on code to adapt it for AndroidAPS), I think the problem comes from your BG data (see line "could not parse ns-entries.2020-05-05.json")... There is a problem for this day (probably not very easy to check) See your entries table in MongoDB to find the error and correct it (json table)...
1) are you sure to have BG values for this day?
2) if yes it could be a missing " : or } character....
No other idea...
1) are you sure to have BG values for this day?
2) if yes it could be a missing " : or } character....
No other idea...
I've been playing with the autotune webservice https://autotuneweb.azurewebsites.net/ a bit. My first two runs of 7 and 15 days were successful. Then I tried 30 days, which came back with an error and now it seems that irrespective of the number of days it leads to an error. Here's a log of a failed 7 days try: https://www.dropbox.com/s/63r5fao8dlfx0of/autotune.2020-05-06-171240.log?dl=0
I'm having the same issue, regardless of the date it returns the same error if I set it to 7 days, 1 day etc ('could not parse entries' for the earliest date within the range I run it for). I'm just wondering what could have changed since all the successful runs I've had
"entries" file contains all BG values, but if it worked previously, may be there is an issue with your NS web site (overloaded, too long time between query and answer so timeout...). Are this error always on the same day (05/05/2020)?
You ran your autotune on 06/05/2020, if BG readings are missings or are corrupted in your NS the day before (005/05/2020), that could also explains why all new autotune webservice including 05/05/2020 day are in error... I advise you to check your entries table in MongoDB of your NS website on this day...
You ran your autotune on 06/05/2020, if BG readings are missings or are corrupted in your NS the day before (005/05/2020), that could also explains why all new autotune webservice including 05/05/2020 day are in error... I advise you to check your entries table in MongoDB of your NS website on this day...
@scottleibrand For my adaptation of autotune into AAPS, I tried to be as close as possible to the OAPS algorithm (and I export all the data to allow a cross execution of oref0-autotune with AAPS data in order to verify coherence). My AutotuneCore is full consistent with oref0, but I have some gaps in autotunePrep module, that come from iob calculation algorithm (I use standard iob calculation available in AAPS and not a modified one dedicated to autotune).
i.e. I saw that you use the average of last 4 hours of pumpprofile basal rate for iob calculation when no running TBR (in AAPS I calculate iob with real basal rate using profileswitches informations...).
=> Should I deep dive into oref0 iobCalculation algorithm (is it a part of autotune calculation) or can I use standard iob calculation ? (and how can I test results to check if I can trust or not with results ?)
i.e. I saw that you use the average of last 4 hours of pumpprofile basal rate for iob calculation when no running TBR (in AAPS I calculate iob with real basal rate using profileswitches informations...).
=> Should I deep dive into oref0 iobCalculation algorithm (is it a part of autotune calculation) or can I use standard iob calculation ? (and how can I test results to check if I can trust or not with results ?)
That’s one of the tests I did when originally developing autotune. Just make sure that your source data in NS records temp basals always running. If you have gaps where default basals were in play, autotune can incorrectly assume you got however much insulin it thinks your basals are, rather than the actual pump basal that was running at the time.
In my NS records, I have all temp basals records, but only temp basals records... and when default basals were in play, I only have profileswitch record in NS to get default basal rate (but I'm not sure oref0-autotune use profileswitches information to get default basal rates...). Does that means that oref0-autotune results could be wrong ?
When I calculate iob inside AndroidAPS plugin, I use internal calculation that include default basal rates when no TBR is running...
When I calculate iob inside AndroidAPS plugin, I use internal calculation that include default basal rates when no TBR is running...
As you can see, in screenshot (oref0-autotune in my virtual machine compared with autotunePlugin in AAPS with 15 days) results are not full consistent, especially the significantly different carbratio! I'll try to export from aaps a set of data including "neutral TBR" when no TBR is running (ns-treatment format) and run oref0 with these data...
Thank's for your help.
Thank's for your help.