What AE-ACK-A Is
AE-ACK-A (Alarm and Event-Acknowledgment Initiate-A) is the BACnet Interoperability Building Block (BIBB) for a device that sends AcknowledgeAlarm on an operator’s behalf. A workstation claiming AE-ACK-A is what an operator’s “acknowledge” click actually triggers: a service request naming the alarming object, the transition being acknowledged, and its timestamp, sent to the device that raised it.
It is the initiating half of the pair completed by AE-ACK-B, which the originating controller claims to execute the request. AE-ACK-A sends the request and constructs it correctly; AE-ACK-B is the one that actually matches it against the transition it recorded and updates Acked_Transitions.
What It Requires
AE-ACK-A does not require the workstation to understand the event algorithm that raised the alarm, only to construct a correct acknowledgment: the right object, the right transition, and the right timestamp, taken from the notification the workstation already received under AE-N-A. Getting the timestamp wrong is the common failure, since it is what lets the originating device tell an old occurrence from a new one that happens to be the same transition type.
Where You Meet It in the Field
Every BAS front-end and alarm-management console with an “acknowledge” button is claiming AE-ACK-A. The interesting field question is not whether the button sends the request, it is whether the operator’s acknowledgment actually reaches the specific occurrence rather than the alarm type in general, which is what makes a re-fired alarm surface again instead of staying silently marked handled.
What Chipkin Provides
Acknowledging alarms is the workstation’s role rather than the embedded stack’s, so this BIBB is most relevant to tools built on the CAS BACnet Stack rather than to a controller. The CAS BACnet Explorer initiates AcknowledgeAlarm from its event view, which is the fastest way to test the receiving end, AE-ACK-B, against a real acknowledgment round trip.