Two types of asset conditions are possible - those that are generated by a trigger, and those that are not generated by a trigger. When you create an asset condition, you can choose to associate a missing asset message, an alarm message, or a data expression message with the condition. You can also choose NOT to associate one of these triggers with the condition. An example of a condition not generated by a trigger is the default condition, Good. This condition has the lowest severity (1) and no associated trigger. It is the condition set by the Platform when all other conditions are unset. You cannot edit the definition of this condition nor can you delete it.
Conditions generated by a trigger are set automatically by the Platform when one of the associated triggers is true. For example, suppose you define a condition called Warning and associate it with the message, Asset is missing from the Axeda® Platform. When the asset goes missing, the Platform sets the Warning condition as the current condition. Once the asset contacts the Platform again, the Platform unsets the condition. As long as no other condition is set, the Platform sets the condition to Good after unsetting the Warning condition. With conditions generated by a trigger, no additional Set or Unset actions are really necessary.
Asset Condition actions are intended to enable you to control the setting and unsetting of asset conditions that are not generated by a trigger. More specifically, these actions can force the Platform to write a asset condition not generated by a trigger into the Platform ("set the condition") or remove an asset condition generated by a trigger from ("unset") the Platform for an associated asset.
Set Asset Condition actions are comprised of types and conditions. Types identify the action that will be performed; in this case, either setting a condition for an asset or unsetting a condition for an asset. Conditions are the actual condition value to set for the asset, for example, Good, Warning, or Error and the associated color icon.
Axeda strongly recommends that you use only trigger-generated asset conditions. Also, if you want to use asset conditions not generated by a trigger, then use the asset condition actions only with those conditions not generated by a trigger. If you try to mix trigger-generated asset conditions, asset conditions not generated by a trigger, and set/unset condition actions, you may see confusing results. Refer to Mixing Rules and Actions with Trigger-Generated Asset Conditions for details.
Important Information about how
these actions work!
When an action that sets a trigger-generated or non-trigger-generated
condition runs, this action forces the Platform to set the condition and
display the selected condition in the all the Status
fields on application pages for the asset, regardless of the severity
level of other currently set conditions. All other asset conditions are
unset.
When an action that unsets a condition not generated by a trigger runs,
the condition is removed from the Platform information for the associated
asset and from the Status
fields on all appropriate application pages.
When an action that unsets a trigger-generated asset condition runs, the
condition is removed from the Platform and the Status
fields only if all the associated triggers are false. Otherwise, the condition
remains set and no message appears to tell you why.
So why isn't the trigger-generated condition unset? One of the associated
triggers must still be true. It may be an alarm value is still within
the specified range, a data expression still evaluates to true, the asset
is missing from the Platform or from its managing Gateway. If you are
not familiar with the definition of the asset condition, go to the View and manage asset conditions
page, click the condition name to view its definition. Then check
the Asset dashboard for recent information sent in by the asset to help
you resolve the problem. For example, you can see and acknowledge an alarm
that generated the condition; acknowledging an alarm will clear the condition,
if no other triggers for that condition are true.
After an asset condition is set by the Set
asset condition action (either manually or by a rule), any new event
that is associated with a trigger-generated asset condition - such as
an alarm - will override the condition that has been set by the manual
action or the rule. For example, a rule tests the value of a data item
for a particular value and sets the asset condition to the condition called
"Error" when that value is received from the asset. The condition
"Error" has no associated trigger. After the rule and its action
run, an alarm associated with a trigger-generated asset condition called
"Warning" is received. The Platform automatically unsets the
asset condition "Error" and sets the asset condition to "Warning."
o If you would not want to lose the information that caused the condition "Error" in the example above, consider making "Error" a trigger-generated asset condition, where the trigger is a data expression that tests the value of the data item. The trigger-generated condition would set Error first and then, if the trigger-generated condition, Warning, has a higher severity, it will set "Warning" as the current condition but still keep Error in the list of conditions set for the asset. "Error" will not be unset until a data item value that causes the condition to be false is received from the asset.
o Because mixing trigger-generated conditions with Set/Unset condition actions can have confusing results, limit the use of the Set/Unset Asset Condition actions to conditions that do not have any triggers associated with them.
o If you create an action for an asset condition, you cannot delete the asset condition until the associated action is deleted.