Creating alarms on MQTT tags is a simple process and is no different than creating alarms on any other Ignition tag (as documented here). However, there are some best practices that one should follow depending on the location of these MQTT tags and application specific use cases.

Alarming on MQTT Tags on the Central Gateway

Alarm & MQTT Engine Module Configuration

As stated previously, configuring alarms on MQTT Tags is no different from creating alarms on any other Ignition tag. However, when creating alarms on MQTT Engine tags, one must consider the following:

1. How best to persist alarm configuration if the MQTT Engine tag must be deleted at any point.
2. How best to configure the MQTT Engine module if alarms are to be triggered by historical data from the Edge Gateway (i.e., via MQTT Transmission).

The following two sections will provide details around the considerations above.

Alarm Configuration Persistence

Deleting an MQTT Engine tag will result in a loss of alarm configuration. Deleting MQTT Engine tags can be required in certain cases. One example is if UDTs are being propagated from the Edge and the UDT definition on the Edge has been updated. This requires one to delete all instances of the UDT under MQTT Engine and delete the corresponding UDT definition so that it can be recreated/updated at MQTT Engine for the Edge side changes to take affect. There are two options for persisting alarm configuration in this case and they are as follows:

1. Use Reference tags to indirectly reference MQTT Engine tags such that alarm configuration can be persisted on the Reference tag when the underlying MQTT Engine tags are deleted. This is the recommended way of configuring alarms on MQTT Engine tags (indirectly) so alarm config persists.
2. Use Ignition scripting to reapply alarm configuration directly on MQTT Engine tags on demand. This is a bit more cumbersome as there must be some mechanism to "trigger" the script execution. 

Trigger Alarms for Historical Data

Depending on one's project requirements, triggering alarms on historical data from the Edge Gateway may be necessary. In this case, MQTT Engine and MQTT Transmission module configuration must enable direct writes of historical metrics to MQTT Engine Tags and MQTT Transmission must flush history in-order. See this documentation for more details on these configuration requirements.