How can we help?

Searching:

0 results found

Axonize Message Keywords

Axonize Rules and AlarmInstances enable you to include or send a message. Axonize keywords enable you to include information retrieved by Axonize in the message. Keywords are defined per product using the ‘additionalProperties’ property in the Axonize API Products Post request. These keywords must be included in the message inside curly brackets {}. For example:

“message”: “{severity} alarm from {deviceName} – {triggeringEvent} {operator} {threshold} on value {value}”,

The following describes these keywords, each of which is a property included in the Rule and/or the reading that triggered the Rule.

{value}

The value of the reading that triggered the Rule.

For example, a Rule may be triggered when the temperature of a refrigerator goes over 20°. The value represents the first reading that was higher than 20°, such as 23°.

{currentValue}

The current value keyword is relevant for a duration Rule, meaning that the Rule uses the ‘conditions/durationInMinutes’ property. The ‘conditions/durationInMinutes’ property specifies how long a condition must continuously exist on a Device before the Rule is triggered.

The current value keyword provides the reading after a duration Rule is triggered.

For example, a Rule can be triggered after 10 minutes (duration) of a refrigerator being over 20°. In this case, the current value represents the last reading received when the Rule was triggered. This means that if the Rule was triggered after 10 minutes of the temperature being over 20°, this might be the reading that was received after 11 minutes, such as 21°. In this case, the value property (described above) can still be used, and it represents the first reading that was higher than 20°, such as 22°.

{datetime}

The timestamp of the reading that triggered the Rule.

{datetimeISO8601}

The timestamp of the reading that triggered the Rule, in ISO8601 format. Use this keyword in a machine-to-machine scenario. For example, for Axonize webService or command rule actions.

{deviceName}

The name of the Device that triggered the Rule.

{idsCsv}

Sends a comma-separated list of the Device IDs that triggered the Rule. For example, let’s say that you have a Product-level Rule that is scheduled to check at midnight whether doors are open. Let’s assume that this check determines that 10 doors were open at midnight for the Product. In this case, you can use the {idsCSV} keyword to send a comma‑separated list of all the device IDs that were in the open state for the Product at midnight.

{operator}

The operator of the Rule used to compare the reading with a value in the Rule. This operator is provided as a symbol, such as =, <, >.

{operatorVerbose}

The operator used to compare the reading with a value in the Rule. This operator is provided as text, such as equal, greater than, less than and so on.

{name}

The name of the Rule, which typically specifies the event indicated by the reading. For example, Temperature is too high.

{severity}

The severity of the Rule. These values may be translated according to the local language.

{threshold}

The threshold used to compare the reading with a value in the Rule.

{triggeringEvent}

The event name on the Device that triggered the reading.

{applicationName}

The application name of the device that triggered the Rule.

{tenantName}

The tenant name of the device that triggered the Rule.

{unit}

The unit of the reading that triggered the Rule, if a unit was provided (for example, by the reading or from the Product).

Adding Device Properties or Settings

You can add the value of a property or setting of the Device that triggered the Rule. This option can be used for any Device property of the Devices/Post endpoint.

To do so, add {device.[property name/setting name]}, where property name/setting name represents the actual name of the property or setting on the device. This must be the actual name of the property/setting and not the display name, which may be different.

For example, “Error occurred at {datetime} on refrigerator model {device.model}”.

Let’s look at another example in more detail. Let’s say that you define the additionalProperties/name property with the name = color, and that this property has the values yellow and blue. In addition, you define a Rule to display a message to indicate when a yellow or blue reading is received from a Device. In this case, you would use the {device.color} property, which means that the message will contain the word yellow or blue based on the value of the reading from the Device.