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 than 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.

Alarming on MQTT Tags on the Edge Gateway

Creating alarms on Ignition tags being consumed by MQTT Transmission on the Edge Gateway requires no special configuration; simply create the alarm on the desired tag as documented here.

Alarm Propagation

A common scenario beyond simply creating the alarm is propagating the alarm to the Central Gateway so it can be managed on the Edge, but present at both the Edge and Central Gateway. In Ignition 8, Cirrus Link MQTT modules used to allow for alarm configuration to be propagated from the Edge side tag to the MQTT Engine tag using the "Filtered Properties" feature. This is no longer possible as of MQTT modules version 4.0.6 due to potential timing issues around alarm evaluation at the Central Gateway that could result in incorrect evaluation. The recommended best practice for alarm propagation from the Edge to the Central Gateway is to use the Ignition Gateway Network to propagate alarms between gateways. 



Additional Resources

  • No labels

New to MQTT? Start Here!