BACnet GetEventInformation Service

GetEventInformation returns a device's active event states with paging (Clause 13.12): how it works, the error codes it returns

What GetEventInformation Is

GetEventInformation is an alarm-and-event service in BACnet, defined in Clause 13.12 of ANSI/ASHRAE 135-2024. A client uses it to obtain a summary of a device’s active event states, meaning every event-initiating object whose Event_State is not NORMAL, or whose Acked_Transitions has any of its off-normal, fault, or normal bits unset. It is a confirmed service: the device answers with the list, or with an error.

This is the modern replacement for the deprecated GetAlarmSummary. It reports fault and unacknowledged states that GetAlarmSummary cannot express, and it pages its results so a large active set fits inside the message limit. The standard intends it to be implemented in every device that generates event notifications.

How It Works

The client sends the request, optionally with a “last received object identifier” to continue a previous paged response. The device returns a list of event summaries, each carrying the object identifier, the event state, the acknowledged transitions, the timestamps of the last off-normal, fault, and normal transitions, the notify type, the event enable bits, and the event priorities. A “more events” flag tells the client whether the device had additional matching objects that did not fit in this reply. To page through them, the client repeats the request with the last object identifier it received, and the device resumes after that object.

Where You’ll See It

  • Workstation alarm view. A head end (the central BMS server) that shows the current alarm and fault state of a device uses GetEventInformation and pages through the results until “more events” is FALSE.
  • Post-restart resynchronization. After a workstation restarts, it queries each device with GetEventInformation to rebuild its picture of what is currently in alarm and what is still unacknowledged.
  • Fault visibility. Because the summary includes objects in fault and objects with unacknowledged transitions, an operator sees conditions that a plain active-alarm list would miss.

GetEventInformation Error Codes

Clause 13.12 defines one service-specific situation with its own error class and code; other failures return an error under the general model of Clause 18 of the standard.

SituationError classError code
The “last received object identifier” no longer exists and no successor object can be determinedOBJECTUNKNOWN_OBJECT

Reading these in the field:

  • UNKNOWN_OBJECT on a paged continuation means the object the client cited as its last-received marker was deleted between pages and the device cannot find where to resume. Restart the query without the marker to rebuild the list from the first object.
  • An empty list is a valid, successful answer that means the device has no active event states, 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.

Profiles That Require It

GetEventInformation splits by direction. Executing it (returning the summary) comes from the AE-INFO-B building block and is required of essentially every controller that generates event notifications. Initiating it comes from AE-INFO-A and is an operator-workstation behavior.

DirectionRequired by BIBBProfiles
Execute (return the summary)AE-INFO-BControllers that generate alarms: B-BC, B-AAC, and the advanced life-safety, access-control, and elevator controllers
Initiate (request the summary)AE-INFO-AOperator workstations and alarm-summary display profiles

What Chipkin Provides

The CAS BACnet Stack executes GetEventInformation on the server side, including the paging that lets a large active-event set span multiple exchanges; the workstation initiate side is implemented in Chipkin’s BACnet test tooling. Talk to us about adding BACnet client or server support to your device.