Problem / use case
There are situations where the absence of BG/CGM data is intentional and expected.
A typical example is swimming: a child leaves the phone behind while swimming, so AAPS will intentionally not receive BG data for a known period of time.
The same applies to other activities where the user deliberately accepts that the AAPS phone will temporarily not receive BG values.
Currently, AAPS and connected AAPSClients will eventually raise the “No BG data received” / stale BG alarm.
This alarm is useful when BG data disappears unexpectedly. However, when the interruption is planned, repeated alarms on the Master and especially on multiple AAPSClients are disturbing rather than informative.
Disabling the local alarm permanently via:
Settings → Local alarms → “Alert if no BG data is received”
does not really solve this use case. The alarm is valuable during normal operation and should remain enabled.
Proposed feature: “Expected BG interruption”
Could AAPS provide a temporary mechanism similar to Pump Disconnect or Loop Paused?
For example:
Expected BG interruption
- 30 min
- 60 min
- 90 min
- 2 h
- Custom duration
- Until manually resumed
During this period, the “No BG data received” alarm is temporarily suppressed.
This should affect only the alarm behavior. It should not change how AAPS handles missing BG data or how the loop operates.
In particular, AAPS obviously cannot execute the loop without BG data and will fall back to the existing behavior (e.g. profile basal). This feature should not modify that safety behavior.
Automatic reactivation
The suppression should automatically end:
- when the selected time expires, or
- when BG data resumes, whichever happens first.
This would reduce the risk of accidentally leaving the alarm disabled after the activity.
The normal “No BG” alarm setting would therefore remain enabled permanently; only its notification would be temporarily suppressed because the absence of BG data is expected.
AAPSClient behavior
This becomes particularly relevant when several AAPSClients are connected.
If the Master declares:
“BG interruption expected for the next 60 minutes”
the clients could receive this state as well.
On the client UI there should be a visible indication such as:
BG alarms temporarily suppressed by Master until 14:30
A client could also receive a single notification when this state is activated, rather than subsequently generating repeated “No BG data” alarms.
This way caregivers still know why BG data has disappeared and that the interruption was intentional.
There may additionally be value in allowing an individual AAPSClient to locally suppress its own “No BG” alarms temporarily, especially when that particular client/user is currently not in charge.
This local suppression should not affect the Master or other clients.
So potentially there are two complementary mechanisms:
- Master: declares an expected BG interruption and communicates this state to clients.
- Client: may locally mute its own No-BG alarm temporarily without changing anything on the Master or other clients.
Example: swimming
A child goes swimming for 60 minutes and deliberately leaves the AAPS phone behind.
Before swimming, the caregiver selects:
Expected BG interruption → 60 min
AAPS continues to behave exactly as it currently does when BG data is unavailable.
However:
- the Master knows that missing BG data is expected,
- connected clients receive this information,
- clients show that BG alarms were temporarily suppressed by the Master,
- clients receive one informational notification,
- repeated No-BG alarms are suppressed,
- if BG data returns after 45 minutes, normal alarm behavior is automatically restored,
- otherwise normal alarm behavior is restored after 60 minutes.
The same mechanism could apply to any activity where temporary loss of BG data is deliberately accepted, not only swimming.
Possible integration with AAPS 4 Scenes
With the upcoming Scenes functionality in AAPS 4, this might also fit naturally into an activity Scene.
For example, a Swimming Scene could define a set of temporary settings for a selected duration, including:
Expected BG interruption / suppress No-BG alarm
Likewise, other Scenes such as running or activities where the phone is intentionally left behind could include this option.
This could make alarm behavior part of the activity context instead of requiring the user to change the permanent Local Alarm settings before and after every activity.
Safety / distinction from disabling the alarm
The intention is not to hide an unexpected loss of CGM data and not to alter loop safety behavior.
The distinction would be:
Unexpected missing BG → alarm
User explicitly declared temporary BG interruption → no repeated alarm, but visible state + one-time notification
After the defined period — or as soon as BG data resumes — normal alarm behavior is restored automatically.
This would preserve the safety value of the existing No-BG alarm while making it much more practical in situations where loss of BG data is deliberate and expected.
Problem / use case
There are situations where the absence of BG/CGM data is intentional and expected.
A typical example is swimming: a child leaves the phone behind while swimming, so AAPS will intentionally not receive BG data for a known period of time.
The same applies to other activities where the user deliberately accepts that the AAPS phone will temporarily not receive BG values.
Currently, AAPS and connected AAPSClients will eventually raise the “No BG data received” / stale BG alarm.
This alarm is useful when BG data disappears unexpectedly. However, when the interruption is planned, repeated alarms on the Master and especially on multiple AAPSClients are disturbing rather than informative.
Disabling the local alarm permanently via:
Settings → Local alarms → “Alert if no BG data is received”
does not really solve this use case. The alarm is valuable during normal operation and should remain enabled.
Proposed feature: “Expected BG interruption”
Could AAPS provide a temporary mechanism similar to Pump Disconnect or Loop Paused?
For example:
Expected BG interruption
During this period, the “No BG data received” alarm is temporarily suppressed.
This should affect only the alarm behavior. It should not change how AAPS handles missing BG data or how the loop operates.
In particular, AAPS obviously cannot execute the loop without BG data and will fall back to the existing behavior (e.g. profile basal). This feature should not modify that safety behavior.
Automatic reactivation
The suppression should automatically end:
This would reduce the risk of accidentally leaving the alarm disabled after the activity.
The normal “No BG” alarm setting would therefore remain enabled permanently; only its notification would be temporarily suppressed because the absence of BG data is expected.
AAPSClient behavior
This becomes particularly relevant when several AAPSClients are connected.
If the Master declares:
the clients could receive this state as well.
On the client UI there should be a visible indication such as:
A client could also receive a single notification when this state is activated, rather than subsequently generating repeated “No BG data” alarms.
This way caregivers still know why BG data has disappeared and that the interruption was intentional.
There may additionally be value in allowing an individual AAPSClient to locally suppress its own “No BG” alarms temporarily, especially when that particular client/user is currently not in charge.
This local suppression should not affect the Master or other clients.
So potentially there are two complementary mechanisms:
Example: swimming
A child goes swimming for 60 minutes and deliberately leaves the AAPS phone behind.
Before swimming, the caregiver selects:
Expected BG interruption → 60 min
AAPS continues to behave exactly as it currently does when BG data is unavailable.
However:
The same mechanism could apply to any activity where temporary loss of BG data is deliberately accepted, not only swimming.
Possible integration with AAPS 4 Scenes
With the upcoming Scenes functionality in AAPS 4, this might also fit naturally into an activity Scene.
For example, a Swimming Scene could define a set of temporary settings for a selected duration, including:
Expected BG interruption / suppress No-BG alarm
Likewise, other Scenes such as running or activities where the phone is intentionally left behind could include this option.
This could make alarm behavior part of the activity context instead of requiring the user to change the permanent Local Alarm settings before and after every activity.
Safety / distinction from disabling the alarm
The intention is not to hide an unexpected loss of CGM data and not to alter loop safety behavior.
The distinction would be:
Unexpected missing BG → alarm
User explicitly declared temporary BG interruption → no repeated alarm, but visible state + one-time notification
After the defined period — or as soon as BG data resumes — normal alarm behavior is restored automatically.
This would preserve the safety value of the existing No-BG alarm while making it much more practical in situations where loss of BG data is deliberate and expected.