> For the complete documentation index, see [llms.txt](https://support.powerio.com/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.powerio.com/hub/codesys-hvac/hvac-alarm-message-library/funktionsbausteine/alarmmanagerhandler.md). # AlarmManagerHandler ## `AlarmManagerHandler` (FB) FUNCTION\_BLOCK AlarmManagerHandler Dieser Funktionsbaustein stellt für jeden Alarm, der in der Konfigurationsliste konfiguriert wurde, eine Alarmpufferliste zur Verfügung. Er ist unabhängig vom Alarmzustand; selbst inaktive Alarme und Alarme im Normalzustand werden angezeigt. Der „AlarmTraversalConsumer“ wird verwendet, um alle Alarmdaten abzurufen. Die Daten werden nicht direkt über diesen Funktionsbaustein selbst gelesen; der „AlarmTraversalConsumer“ kann als Listener verstanden werden. Auf die Daten wird ausschließlich über den Zeiger auf den „AlarmManagerBuffer“ zugegriffen. Dieser Zeiger wird vom „AlarmTraversalConsumer“ zurückgegeben, der dafür eine Get-Methode bereitstellt. Sämtliche Daten für jede Alarmzeile werden in der „stAlarmRowStructure“ gehalten, und jede Zeile wird im Buffer-Array „m\_paAlarmBuffer“ abgelegt. Auf den Buffer kann über den „ppaFilterAlarms“-Zeiger zugegriffen werden. Nur die gefilterten Daten werden in diesem Buffer bereitgestellt. Bitte beachten Sie, dass nur die Daten innerhalb der maximal konfigurierten Alarmanzahl gelesen werden. Dies führt zu einem deutlichen Performancegewinn. Die Daten werden außerdem nur einmal im „AlarmManagerBuffer“ gespeichert; der Buffer wird ausschließlich über den Zeiger angesprochen. Mit diesem Funktionsbaustein sind alle Alarme per IEC-Code zugreifbar, was Ihnen die Möglichkeit gibt, sie für weitere Zwecke zu verwenden oder Verhaltensregeln zu definieren. Es gibt einige Standardregeln, die verwendet werden können. Unterschiedliche Feldinformationen können zur Filterung aller Alarme herangezogen werden. Die „IMessageExecution“ kann implementiert werden, um eigene Alarmregeln zu definieren. InOut: | Scope | Name | Type | Comment | | ------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | Input | `xForceDeactivateAlarmMessages` | `BOOL` |

Deactivate Alarm Messages (deactivates all alarm messages
and ignores the last state of them)

| | Input | `itfMessageExecution` | IMessageExecution | Interface to define message execution rules. | | Input | `paPolicyList` |

POINTER TO ARRAY
\[0..ConstantParameters.gc\_iMaxPolicyRules]
OF stPolicy

| The list which holds all policy rules. | | Input | `paGroupList` |

POINTER TO ARRAY
\[0..ConstantParameters.gc\_iMaxGroupRules]
OF stGroup

| The list which holds all groups. | | Input | `xCreateFilterList` | `BOOL` |

On raising edge the “ppaFilteredAlarms” list will be created
with the configured parameters “sFilterByType” and
“sFilterString”.

| | Input | `sFilterByType` | eFilterType | Filter by type (e.g.: “AlarmClass” or “AlarmGroup”) | | Input | `sFilterString` | `STRING` |

Filter the list with the configured type and the matching
filter string

| | Inout | `ppaFilteredAlarms` |

POINTER TO POINTER TO
ARRAY
\[0..ConstantParameters.gc\_iMaxAlarms]
OF POINTER TO
stAlarmRowStructure

|

The filtered list, which is dynamicly created by the given
filter parameters.

| | Output | `iFilteredAlarmRows` | `INT` |

the upper border to the size of the filtered alarm buffer
list.

| | Output | `eError` | ERROR | | | Output | `stEmailStateInfo` | stEmailState | | | Output | `sAlarmTextPortal` | `STRING(255)` | | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://support.powerio.com/hub/codesys-hvac/hvac-alarm-message-library/funktionsbausteine/alarmmanagerhandler.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.