What GetAlarmSummary Is
GetAlarmSummary is an alarm-and-event service in BACnet, defined in Clause 13.10 of ANSI/ASHRAE 135-2024. A client uses it to obtain a summary of a device’s active alarms, where an “active alarm” is a standard object whose Event_State is not NORMAL and whose Notify_Type is ALARM. It is a confirmed service: the device answers with the list, or with an error.
The service is deprecated. The standard retains it so client devices can still interoperate with older servers, but it recommends that new server devices not implement it. GetEventInformation is the modern replacement, because it reports fault and unacknowledged states that GetAlarmSummary cannot express.
How It Works
The client sends the request with no arguments. The device answers with a list of alarm summaries, one per active alarm, each carrying the object identifier, the alarm state (the object’s Event_State), and the acknowledged transitions (the object’s Acked_Transitions). A list of length zero means the device has no active alarms. There is no filtering: the response is the whole active-alarm set at once.
Where You’ll See It
- Legacy alarm views. An older workstation polling a device’s current alarms may still use GetAlarmSummary where a newer one would use GetEventInformation.
- Interoperating with old servers. A modern client keeps GetAlarmSummary in its toolkit so it can read alarms from devices that predate GetEventInformation.
- Quick active-alarm snapshots. The no-argument request returns every active alarm in one exchange, which suits a simple “what is in alarm right now” check on a device that still supports it.
GetAlarmSummary Error Codes
Clause 13.10 defines the confirmed result but does not list service-specific situations with their own error class and code; a device that cannot answer returns an error under the general model of Clause 18 of the standard.
Reading these in the field:
- A returned error usually means the device does not support this deprecated service (many modern servers do not) or is out of resources, not that a specific alarm is malformed.
- An empty list is a valid, successful answer that means no active alarms, not an error.
- No response at all is not a service error. A timeout means the request never reached the device or the reply never came back, which is a transport or addressing problem.
- Because the whole summary rides in one response, a device with many active alarms and no segmentation (the ability to split a large response across multiple packets) can fail the reply with an abort; GetEventInformation avoids this with its own paging.
Profiles That Require It
GetAlarmSummary splits by direction. Executing it (answering with the summary) comes from the AE-ASUM-B building block; initiating it comes from AE-ASUM-A. Because the service is deprecated, few current profiles require the execute side, and modern designs favor GetEventInformation.
| Direction | Required by BIBB | Profiles |
|---|---|---|
| Execute (return the summary) | AE-ASUM-B | Server devices that retain the deprecated service for legacy interoperability |
| Initiate (request the summary) | AE-ASUM-A | Operator workstations that read alarms from older servers |
What Chipkin Provides
Because GetAlarmSummary is deprecated, the CAS BACnet Stack centers active-alarm reporting on GetEventInformation, its standard replacement. Talk to us about adding BACnet client or server support to your device, including legacy GetAlarmSummary interoperability.
Related Pages
- BACnet
- BACnet Services
- BACnet GetEventInformation Service
- BACnet GetEnrollmentSummary Service
- BACnet AcknowledgeAlarm Service
- BACnet Stop Polling: Intrinsic Event Notification: the alarms this service is summarizing