[WIP] Night mode

[justmara]

This PR adds overnight SMB restriction mode (inspired by Eating Now @dicko72).

• You set up the time interval for 'Night mode' to be active
• Set the BG offset (from profile target) in which Night mode will be active during time from step 1

So during night while your BG is below profileTarget + BG offset - SMB will be disabled and only TBR will be active for plugins.
When BG escalates higher than profileTarget + BG offset - SMB overnight restriction falls off.

You can also set up Night mode to be disabled if COB > 0.
Or when Temp Target is set lower than profile target.

07..15:00 time is set here because I were testing it during a day now :)

The idea of this mode itself is to add some security mode against overnight sensor pressures. Here is my daughter's BG this night - these fast drops are sensor pressures, and quick rises - BG comes back to real after pressure released.

Usually AAPS acts like this for these quick rises (see many SMBs here)

But frankly thats a graph from my test phone connected to virtual pump, because in reality MUCH lower amount of insulin were required to deal with that:

TBS is way more safe for such beaviour

[olorinmaia]

A welcome change. I've solved exactly this myself with automations. But this will make it easier to keep nights steady for users having trouble configuring automations.

[justmara]

A welcome change. I've solved exactly this myself with automations. But this will probably make it easier to keep nights steady for users having trouble configuring automations.

Making the same with automations not only is WAY more complex and lies beyond most user's expertise, but also depends on other settings that can be unwanted during the rest of the day, but cannot be changed with automations.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2967 Code Smells

No Coverage information
2.6% Duplication

[jbr7rr]

I love the idea of being able to disable SMB at night.

However I think this adds too much settings, and also the placement of the settings is not logical to me.

I suggest the following:
Add two settings to openAPS SMB:

• Enable SMB in timewindow (This setting only shows if "SMB always" is not selected)
• Start time and End time of SMB enabled (This only shows when Enable SMB in timewindow is selected)

Make "enable SMB with COB" and "SMB with TT" also work outside the timewindow. do not add a setting for this, but maybe clarify that it will override the timewindow

This will make it more in line with the current settings for SMB we have. Additionally you could group all SMB related settings in a sub menu of openAPS SMB

Also a setting like BG offset is not obvious to many users.. With what I propose the same can be achieved by an automation (setting a low TT when BG is above a certain offset)

[justmara]

the placement of the settings is not logical to me.
Add two settings to openAPS SMB:

These settings apply to SMB and Dynamic ISF SMB (and also to other plugins like EN/Boost/AutoISF/AIMI...) - thats why I placed these to Treatments protection section instead of copy-pasting same settings to all the SMB-related plugins.
So it does not add anything new, it RESTRICTS SMBs during specific timewindow AND BG range.

Also a setting like BG offset is not obvious to many users..

Automations are much less obvious - this is an attempt to keep this as a restriction policy, confgured in one place for all of the plugins. The safety one. Without automations, tricky SMB plugin combinations etc.

[szantos]

Basically a very good point, IMHO many would need an SMB_off option - maybe not only at night.

There is another existing solution in autoISF based on even/odd temptarget (odd means SMB_off).

But the most straightforward and versatile would be an additional automation action to disable SMB.

[justmara]

There is another existing solution in autoISF based on even/odd temptarget (odd means SMB_off).

Totally unusable for mmol users :)

[szantos]

If using mmol/L the decimal is considered by autoISF.
Why do you think, this to be unusable?

[th122]

That'd be a step forward. I had been running a similar modfication in an earlier version branched from pre 3.x AAPS, and was really happy with the result. Let me include the reasoning and documentation...

stateful loop

So far I'm seeing one underlying circadian state loop with the main states "awake" and "asleep" (Profiles default and sleep) and the brief transitional states wake up and rise which both (might) introduce hormonal resistances.

Note: State changes can be implemented as profile switches, or ISF percentage modifications.

graph LR;
D ==>|go to bed\nPS sleep\nstarts circadian cycle| BED;
BED ==> S;
S ==>dawn;
dawn ==> W;
W ==> U;
U ==> D;
U--> |triggers AP| D;
BED ==>|triggers|dawn;
linkStyle 0 stroke-width:2px,fill:none,stroke:blue;
linkStyle 1 stroke-width:2px,fill:none,stroke:blue;
linkStyle 2 stroke-width:2px,fill:none,stroke:blue;
linkStyle 3 stroke-width:2px,fill:none,stroke:blue;
linkStyle 4 stroke-width:2px,fill:none,stroke:blue;
linkStyle 5 stroke-width:2px,fill:none,stroke:blue;
style D fill:#9C9,stroke:#333,stroke-width:2px;
style S fill:#9C9,stroke:#333,stroke-width:2px;
style BED fill:#69f,stroke:#333,stroke-width:2px;
subgraph awake;
  D((default));
  W((wake));
  U((rise));
  end;
subgraph asleep;
  BED{falling asleep};
  S((sleep));
  dawn{dawn};
  end;

Loading

Profile Switches (PS)

• default: based on ISF profile while awake
• sleep: insulin sensitivity raised (reducing BR to about 70%), timed to return to default at a later point in time. (The onset of sleep would be the moment to set time shifts to the circadian rhythm)
  Note: 70% usually proves too little if late meals are still showing their effects, one more vote for jiggling ISF down while there are still meal-related positive deviations.
• wake: hormonal/stress level dependent rise based on waking up. Highly variable, usually already taking effect before consciously waking up. Might merit some handling of its own. Possible idea: leave BR and Target, but lower ISF if large deltas are observed up to 2hrs prior to normal rising time. Corrections with nighttime ISF don't cut it, a rise from 90mg/dl to 140mg/dl within the span of 10min is not uncommon, and even if the calculation of ISF is not capped, it is stabilized too much against the previous hours to have any leverage (example: peregrine 2018-12-08 08:04, ISF lowered from about 135 to 120). Caveat sensor noise. Unfortunately a sudden rise like that also gets labeled as possible noise... Hence: observe plateau after that rise, and add a little leverage to ISF then?
• rise: rise IOB to daytime level. "Aufstehphänomen" Teupe: "Aufstehbolus" to get IOB back to daytime level - he is calculating with a slightly different logic: since in traditional basal rates a prolonged sleeping period is calculated in to avoid lows when sleeping in, the missing insulin needs to be accounted for when rising earlier (i.e. as for normal working days) With the profile switch to daytime dosing and ISF, this amount doesn't need to be taken into account. What the workflow from wake to rise would need to calculate and give immediately would be the difference to get the IOB to the level needed for the daytime default profile (already taking into account the activity/commute almost certainly scheduled within the acting time of that insulin. No duration needed for this.

Further implications

using this state-model, the loop also "knows" when the user is asleep, and could further peruse this information to adapt its "interruptiveness" in order to not disturb the circadian rhythm more than absolutely necessary.

• do not nag noise notifications can be suppressed. The loop takes a longer avg delta for its considerations.

[justmara]

@MilosKozak does the new 'Simple mode' mean that this PR have chances to be merged if updated to latest dev? :)

[vanelsberg]

This PR adds overnight SMB restriction mode

Love the concept! ❤️

• Fixed schedule however would not be optimal for me (not a regular sleeper). How about option to activate this nightmode through user action (like setting "activity" or eating now)?

• AutoISF already implements this successfully, be it in a tricky way through odd/even target BG in profile. So proposed PR would add inconsistency to the UI in doing similar in different ways? That said, personally I'd prefer to see the schedules implemented through profile settings - f.i using an additional settings column for nigh mode on/off?

[justmara]

Fixed schedule however would not be optimal for me

It can be overridden using lower temp target, for example. Usual schedule with manual exceptions is a better control for this.

AutoISF already implements this

Sorry, but that even/odd thing is a pretty dirty hack. You must always deal with it, every time you try to set a TT - lower/higher, exercise or pushing AAPS harder.. It conflicts with standard 'Enable SMB for high temp target' option adding inconsistency...

Some people also achieved near same results with automations for temptargets. But that's pretty unstable (there is always loop trigger between TT switches that can lead to unwanted SMB) and counterintuitive.

One global safety option for all of the loop plugins - that was the reason for this modification.