Loop frequency limit to prevent unexpected battery drain

[mcnelson]

When I first used AAPS, I was perplexed by its battery drain but then realized it was because I was using a 1-minute sensor. While the loop does look optimized, executing it every minute of the day does add up and decimates battery life.

I propose adding a "minimum time between loop iterations" setting that allows you to throttle down the frequency to 1-5 minutes at minimum. I have found setting this at 4 minutes has been a great compromise.

Since using 1 minute CGM can be a poor new user experience, maybe we could eventually set this at 5 minutes by default. It seems clear AAPS was designed around 5 minute intervals, so I believe there should be a safeguard so it's an explicit action by the user if they want to venture into battery-burn territory.

This PR adds a new item to Loop settings to choose this interval, including a "no limit" option which is currently the default. It also adds a red warning if the rate is > 500 iterations per day.

The limiting is implemented currently in IobCalculatorPlugin because it looks like the highest entry point to the chain of loop workers, but I'd love to know a possible better location? FWIW using it here has definitely worked for me / saved my battery.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ga-zelle]

In my case I do not see significant impact on the battery. I get around 1200 loops per day and the battery lasts longer than a day.

There may be indirect reasons for increased battery usage like automations (which I use), frequently triggering profile changes (which I do not do), watch (which I do not use), nightscout (which I do not use but saw doubling battery usage during tests).

[je-l]

There might be low-hanging fruits for the loop performance itself to prevent battery drain. With the new 4.0.0 changes in dev, it's a bit heavy even with almost empty db. One bottleneck seems to be excessive recompositions. This is during one loop run:

I haven't tested with larger data sets or profiler yet.

[mcnelson]

Thanks the ideas, yeah I'll keep digging on what could be expensive per loop in my particular setup. I use Nightscout but only once per day sync (should be no calls from the loop?), simple automations, no constant profile changes. I wonder if Nightscout adds work even if not constantly syncing?

To be clear, my battery still lasts through the day even with 1200 loops per day but with an noticeable, outsized impact on battery usage in the afternoon. Seems like the loop workers potentially do a lot! To me it's an efficiency question-- if I get the same outcomes at 4 min vs. 1 min intervals, it seems a bit silly to be performing 3x or more work with risk of battery burn.