Alarm Event Properties Reference

Alarm Tag Properties

All alarm states have a list of properties that you can edit or bind when creating or editing a Tag. These are useful to know when using the system.tag.addTag() and system.tag.editTag() functions. To see the list of alarm properties that can be configured on a Tag, see the Tag Properties page.

Alarm Event Properties

An alarm event is made up of many pieces of information. The state, the value, the time, all of the configuration data for the alarm, and more are collectively known as the properties of the event. A "property" is generally a name, potentially along with a default value. There are many properties that an alarm may have, and if the property isn't present, the default value is usually assumed.

This is different than the alarm properties used during initial setup, these are the properties available when an alarm event occurs (active, clear, acknowledged).

How Properties are Used

Properties are used in a number of ways:

• Define how an alarm behaves.
• Are referenced in messages, such as the body of an Email, or SMS message.
• Are referenced in Expressions, such as in the binding of a different property, or in an Expression block.
• Are created and used in pipelines as temporary variables, such as to make a counter.
• ... and various other places.

While properties are always accessed the same (for example by using the {propertyName} syntax in a message or Expression, or the getProperty() Expression function), there are some subtle variations on where the property value comes from, and what its lifecycle will be. To understand this better, consider that an Alarm Event has the following structure:

Alarm Event
   Active Event Properties
   Clear Event Properties
   Acknowledged Event Properties
   Runtime Properties

The Active Event, Clear Event, and Acknowledge Event properties get created when the described type of event occurs. Consequently, it's possible for the same property to exist multiple times in an Alarm Event. For example, a bound configuration property or associated data is captured on both the active and clear events. When you reference a property, the alarm event will provide you with the most recent value. So, if you have a bound property called "MyData", and you reference it when the alarm is active, you may get a different result than when the reference is executed later and the alarm has cleared. The individual values are stored separately in the Alarm Journal, however.

Alarm Event Properties

Alarm Runtime Properties

As described in the previous section, Runtime Properties are different in that they only exist while the alarm event is in memory (still "live", that is, not cleared, or not acknowledged). They do not get stored in the Alarm Journal by default. In addition to properties created through the Set Property Block, the system also has a number of defined Runtime Properties that it may use for various purposes. Though these are used internally, they are technically still regular properties, and can be accessed and modified through the normal means.

Associated Data

You can extend alarm properties by creating your own associated data.  Associated data properties can be configured on any alarms that are already configured in a project. 
To learn more, refer to Alarm Associated Data.  

The AlarmEvent Object

Some system functions, such as system.alarm.queryStatus,  return an AlarmEvent object which contains many methods to retrieve additional information about the individual alarm. This section details the various methods on an AlarmEvent Object.

Note, many of the functions below return some complex object, as opposed to just a standard Python datatype. In these cases, normal Python type-casting can be used to turn the object into a native Python type. For example, getDisplayPath() returns a StringPath object, which can easily be converted to a Python string with the str() function.