Rule

Last modified: Jun 20, 2019 @ 11:21

Contents

Introduction

Rules are configured to trigger on definable conditions based on sensor data reported from Resources. For example, a rule can trigger if the temperature crosses a threshold value. When this happens, an Actuator can be triggered to operate on a Device. In the case of a temperature issue, DDM could trigger an automated system such as heating or air conditioning. If manual interaction is needed, service personnel can be alerted.

Create/Edit Rule

Navigation: Settings -> Event Settings -> +Create or click an Event -> Rules panel: +Create New or click a Rule

Severity Level: Severity is expressed on an arbitrary scale from 1 to 5. It is up to the customer to assign a severity type to each numerical value.

Active: Choose whether the Rule should be Active, i.e. it can be triggered. If the Rule is deactivated with this setting, a Schedule attached to the Rule has no effect.

Every Resource/Only First Time: This is a mutually exclusive choice. Choose how many times a Rule trigger should occur:

  • Every Resource: The Rule triggers once for every Resource in the Resource Collection that fulfills the Rule criteria. For example:
    Two temperature sensors are present in the Resource Collection.

    1. One temperature sensor is triggered. An alarm is fired.
    2. The second sensor is triggered. An alarm is fired.
      Note: With this setting, the Rule triggers multiple times without needing to be reset.
  • Only First Time: The Rule triggers only the first time a Resource fulfills the Rule criteria; subsequent triggers of the same type are ignored. This can be used to prevent unnecessary notifications when only one trigger instance is sufficient to address the issue. For example:
    Two temperature sensors are present.

    1. One temperature sensor is triggered. An alarm is fired.
    2. The second sensor is triggered. No alarm is fired.

The Rule will only trigger while the Schedule is active. For information on Schedule this rule, see Schedule. If no Schedule is attached to the Rule, only the Active setting controls whether the Rule is active.

Trigger by Device: If selected, all Trigger Conditions must be satisfied on the same Device, for the Rule to trigger.

Trigger by Smart Object: Alarm is fired if resources belong to the same Smart Object. For example:
A Device has two Smart Objects. Each Smart Object has one temperature sensor and one humidity sensor.

Note: The condition Every Resource/Only First Time is checked first. Then condition Trigger by Device/Smart Object is checked.

  • If both sensors of the same Smart Object are triggered, an alarm is fired.
  • If the temperature sensor of the first Smart Object and the humidity sensor of the second Smart Object are triggered, no alarm is fired.

Threshold trigger reset: When activated, this option automatically resets the trigger condition once the threshold has been crossed. If this setting is not activated, the trigger condition remains set until manually reset.
Activating this setting displays additional controls in the Reset Trigger Operator and Reset Trigger Value columns of the Trigger Conditions list.

  • Trigger Operator: Sets which logical operator is used on the trigger value.
  • Trigger Value: The value that should trigger the Rule.
  • Reset Trigger Operator: Sets which logical operator is used on the reset trigger value. Only available if Threshold trigger reset is selected.
  • Reset Trigger Value: The value that should reset the Rule. Only available if Threshold trigger reset is selected.

Examples

In the following examples, the rule is Integer Value > 10. The initial state is value = 10.

Example 1

  1. When value becomes 11, the rule fires.
  2. The rule is reset. The value is still 11.
  3. The value changes to 12. The rule fires once more.

Example 2

  1. When value becomes 11, the rule fires.
  2. The rule is reset. The value is still 11.
  3. The value changes to 10. The rule does not fire.

Example 3

  1. When value becomes 11, the rule fires.
  2. The rule is reset. The value is still 11.
  3. The value becomes 11. The rule does not fire because the value did not change.

In Example 3, a change in value is required for the rule to fire once more.

Note: Updating the rule will also cause the rule to trigger, even though the value is still the same.

In the following examples, the rule is Boolean = true.

Example 4

  1. The initial value is false.
  2. Value becomes true. The rule fires.
  3. The rule is reset. The value is still true.
  4. Value becomes false. The rule does not fire.

Example 5

  1. The initial value is false.
  2. Value becomes true. The rule fires.
  3. The rule is reset. The value is still true.
  4. Value becomes true. The rule does not fire because the value did not change.

In Example 5, a change in value is required for the rule to fire once more.

Note: Updating the rule will also cause the rule to trigger, even though the value is still the same.

DDM validates the conditions of a rule by comparing the trigger values and the reset values.

Consider the following scenario:

Trigger Operator equals to Above (>); Trigger Value equals to -10; Reset Trigger Operator equals to Above (>); Reset Trigger Value equals to 0.

That is,

When the Trigger value is > -10 and the Reset Trigger Value is > 0, the trigger rule and the reset rule overlaps.

  1. When value becomes > -10, the rule fires.
  2. The rule is reset. The value will be above 0. Now, the trigger value and the reset rules overlap.

Hence, DDM checks the validity of the condition before applying. If the rules overlap, the trigger/rest rules are discarded, and a warning message is displayed to the user, as shown in the picture given below.