|
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.
Properties are used in a number of ways:
| • | To define how an alarm behaves |
| • | Referenced in messages, such as the body of an email, or sms message. |
| • | Referenced in expressions, such as in the binding of a different property, or in an expression block. |
| • | 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:
The first three collections of properties get created when the described type of event occurs. Consequentially, 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 call "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.
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. 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.
Commonly Used Properties
| • | Name - The name of the alarm (ie. not of the tag) |
| • | ActivePipeline, ClearPipeline |
| • | TimeOnDelaySeconds, TimeOffDelaySeconds |
| • | IsInitialEvent - Set to "true" when the event is caused by the initial state of the alarm. |
| • | SystemAck - Set to "true" when the alarm has been acknowledged by the system, due to an overflow of the "live event queue". Live events are alarm events that are active or not acknowledged, and are limited for each alarm by the general alarm settings. |
| • | IsShelved - Is the alarm currently shelved? |
| • | ShelfExpiration - When the shelf will expire for this event. |
| • | EventCanceled - If set, the event will drop out as soon as possible from the pipelines. |
| • | EventId - the unique id (uuid) of this alarm event. Each event gets a completely unique id. |
| • | Source - the qualified path to the item that generated this event. |
| • | DisplayPathOrSource - Gets the display path if defined, otherwise returns the source. |
| • | State - The current overall state of the alarm: ClearUnacked (0), ClearAcked (1), ActiveUnacked (2), ActiveAcked (3) |
| • | EventState - The transitional state that caused the current event: Active (0), Clear (1), Ack (2) |
| • | EventValue - The value associated with the current event. |
| • | AckUser - The user who acknowledged this event. |
| • | IsAcked - "True" if the event has been acknowledged. |
| • | IsActive - "True" if the event is still active. |
| • | IsClear - "True" if the event is not still active. |
| • | ActiveTime, ClearTime, AckTime - The timestamp for each event. |
| • | PipelineTransitionCount - How many transitions the event has made inside of the pipelines. |
|