Page History

...

In MQTT Transmission and MQTT Engine support was added to transmit alarm events from the Edge (MQTT Transmission) to the Central Gateway (MQTT Engine) . They also now support acknowledgements from the Central Gateway (MQTT Engine) back to the Edge (MQTT Transmission).

To configure alarm event propagation from Transmission to Engine, follow these steps.:

Ignition

1. Stop the Ignition instances for both MQTT Transmission and MQTT Engine 
   
   

2. Add a line similar to the following to the data/ignition.conf file but replace on each Ignition instance replacing the 'XX' with the proper index per the wrapper.java.additional statements. This must be done on both the MQTT Transmission side as well as the MQTT Engine side. 

   Code Block
   wrapper.java.additional.XX=--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED

   
   

3. Restart the Ignition .instancesIn the

MQTT Transmission

...

1. Ensure that Alarm Event Enable has been set under the Transmitter Alarm Settings configuration
   
   
2. Ensure that a Disk Backed History Store has been configured and that the Transmitter has been configured under History Settings to use this history store. We recommend configuring a rolling buffer to manage a MQTT Transmission keep alive timeout scenario. 

MQTT Engine

1. Ensure that the Alarm Event Enable has been set under the General Alarm Settings configuration
   
   

Testing

1. Set up a tag on the Transmission side with an alarm. 

   Note
   The Ack Mode must be set to Manual or Auto The alarm properties that are currently propagated are: Name, Priority and Notes

   
   Below is an example that will generate an event if the value of the tag goes above 100:
   Image Modified

2. Trigger the alarm.
   In this example, we set the value of the memory tag to 101. This resulted in an alarm event at the Edge as shown below in the Alarm Status Table:
   
   
   
   
3. Because the alarm event was published via MQTT, we can also see it on the Central Gateway running MQTT Engine:
   
   
   
   

4. At this point, we can Acknowledge acknowledge the alarm at either the Edge or the MQTT Engine side via the Alarm Status Table by clicking the 'Acknowledge' button as shown below:

   InfoThe alarm can be acknowledged on either the Edge or the Central Gateway side

   . Once

   ackowledged

   acknowledged, it will be reflected as so on both the Edge and the

   Central Gateway

   MQTT Engine sides.

   
   

   Note

   Warning In order for the alarm acknowledgement or clearing at the Edge to be published to MQTT Engine, the Edge must be in an active Sparkplug session with MQTT Engine or have determined that the connection is unavailable such that the event changes are stored to the Disk Backed History Store for publication on reconnect. MQTT Transmission can take upto 1.5 times the configured keep alive time to determine that there is a connection failure and any alarm acknowledgements or clearings can be lost during this time leaving alarms 'stranded' at MQTT Engine. How to remove stranded alarms from the MQTT Engine Alarm Status Table. The recommended approach to mitigate this issue is to configure a Rolling History Buffer for the Disk Backed History Store which will cover data loss during a keep alive timeout scenario While testing the alarm acknowledgements whilst the Edge is disconnected, you can confirm that the connection status via the MQTT Transmission Servers view in the UI or through the MQTT Client Online tag

   
   

   Note
   In order for the alarm to be acknowledged from MQTT Engine, the Edge must be in an active Sparkplug session with MQTT Engine If the Edge node is offline, the following will be displayed in the Alarm Status Table and Ignition logs at MQTT Engine:  Image Added Image Added Once the Edge node comes online, any new alarm acknowledgement will be successful from MQTT Engine.

   
   

After doing so, you can see the acknowledged alarm on the Central Gateway (MQTT Engine side) :

Image Modified

...

and the Edge (MQTT Transmission side) :

Image Modified

Anchor
strandedalarms strandedalarms

Removing stranded alarms from the MQTT Engine Status Table

If alarms have been 'stranded' in the MQTT Engine Alarm Status Table, they can be cleared using the MQTT Engine Python Scripting API with the readAlarms and clearAlarms calls.

MQTT Modules v4.0.16 to v4.0.22

...

1. Add a line similar to the following to the data/ignition.conf file but replace the 'XX' with the proper index per the wrapper.java.additional statements. This must be done on both the MQTT Transmission side as well as the MQTT Engine side.

   Code Block
   wrapper.java.additional.XX=--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED

   
   

2. Restart Ignition.
3. Set 'Alarm Event Enable' in the MQTT Transmission Transmitter configuration to true.
4. Set up an Alarm Journal in Ignition on the MQTT Engine side.
5. Set up a tag on the Transmission side with an alarm.
6. Trigger the alarm
7. After doing so, you should see something similar to the following in the alarm journal on the MQTT Engine side:
   

Troubleshooting

If you have not updated the data/ignition.conf file on the Ignition instance(s) running MQTT Transmission and MQTT Engine correctly you will see this error in the Ignition logs from the com.cirruslink.mqtt.common.gateway.agent.alarm.AgentAlarmListener

Failed to handle the event
com.inductiveautomation.ignition.common.gson.JsonIOException: Failed making field 'java.util.concurrent.atomic.AtomicReference#value' accessible; either increase its visibility or write a custom TypeAdapter for its declaring type.

Double check that the wrapper.java.additional.XX=--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED syntax has been added to the ignition.conf file wrapper.java.additional statements and indexed correctly on both the MQTT Transmission and MQTT Engine Ignition instances.

Example from Ignition version 8.1.44
#********************************************************************
# Wrapper Java Properties
#********************************************************************
# Java Application
#  Locate the java binary on the system PATH:
#  Specify a specific java binary:
set.JAVA_HOME=lib/runtime/jre-win
wrapper.java.command=%JAVA_HOME%/bin/java

# Tell the Wrapper to log the full generated Java command line.
#wrapper.java.command.loglevel=INFO

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
...
# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=lib/wrapper.jar
wrapper.java.classpath.2=lib/core/common/*
wrapper.java.classpath.3=lib/core/gateway/*

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=lib
wrapper.java.library.path.2=lib/core/gateway

# Java Bits.  On applicable platforms, tells the JVM to run in 32 or 64-bit mode.
#wrapper.java.additional.auto_bits=TRUE
wrapper.java.additional.auto_bits.macosx=FALSE

# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
wrapper.java.additional.2=--add-opens=java.base/java.lang=ALL-UNNAMED
wrapper.java.additional.3=--add-opens=java.base/java.io=ALL-UNNAMED
wrapper.java.additional.4=--add-opens=java.base/java.security.cert=ALL-UNNAMED
wrapper.java.additional.5=--add-opens=java.base/java.util=ALL-UNNAMED
wrapper.java.additional.6=--add-opens=java.base/jdk.internal.misc=ALL-UNNAMED
#wrapper.java.additional.6=-Xdebug
#wrapper.java.additional.7=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000
wrapper.java.additional.7=--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=1024