Alarm States

Alarms can have only one state, which is represented by TAlarmState.

Clients can obtain alarm information from the server using several methods. They can query the server for alarm information by ID for a specific alarm (irrespective of type), for a Pending Alarm or for a Session Alarm. If no ID is specified, then the method returns the first alarm in the specified category: the alarm with the alarm time closest to the current time.

Clients can also populate an array with alarms of a specified type from the Alarm Server. Using this method allows clients to obtain arrays of pending alarms, review alarms, orphaned alarms or snoozed alarms.

The diagram below shows the states that an alarm can go through:

Alarms that are set in the future are said to be pending. Alarms in this state can be cancelled. If they are orphaned or Session Alarms they are also removed by the server if the system time changes. When the alarm time is reached the alarm moves to another state, where it awaits acknowledgement.

If an alarm is set in the past, or if its alarm time is due, its state is moved to awaiting acknowledgement. In this state the user has been notified that an alarm is due, and the alarm is in the server awaiting acknowledgement list. The list can contain 8 unacknowledged alarms. If more alarms arrive the oldest ones are removed.

Alarms may be snoozed, in which case they return to the pending state. If an alarm is acknowledged then it moves to the review state.

Alarms which have been acknowledged are placed in the server review list. This list will automatically drop older Review Alarms as new ones are entered. It is also cleared if the system time is changed.

These are alarms which have been deferred after activation. When any alarm is snoozed it is also orphaned.