Skip to main content

Rules

A rule defines:

  • the data of interest
  • the processing methods
  • the actions that follow the occurrence of a condition defined by the processing methods

The processing methods are defined through mathematical functions and temporal conditions. Specifically:

  • comparison functions: allow you to compare the data of interest with a threshold value
  • average functions: allow you to calculate the average of the data of interest
  • temporal conditions: allow you to define the time interval of interest (both the duration and the position in time)

Actuations can be divided into three categories:

  • notification: send notifications based on the results of the processing
  • storage: write the result of the processing resulting from the rule
  • hook: execute third-party functions

Predefined rules​

There are four predefined rule types, which encompass the most common functionalities. These are distinguished based on the type of conditions that must be verified for the rule to be executed:

  • offline: the rule is executed when a device is offline for a certain amount of time

    • allows to define actions to be taken when a device is offline for a certain amount of time (X seconds)
    • the value of X is defined within the condition (conditions, see below)

  • threshold: the rule is executed when a certain threshold is exceeded

    • allows to define actions to be taken when a certain threshold is exceeded
    • the threshold value is defined within the condition (conditions, see below) defined as a set of logical operators, data sources and threshold values
    • allows to generate alarms based on the data coming from the device

  • correlation:

    • allows to apply the threshold rule across different devices
    • e.g. process the data X of the device Y if the condition W of the device Z is true

  • external matching:

    • allows to apply a rule only if certain external conditions are met, coming from third-party APIs
    • e.g. process the data of the device X only if the temperature returned by the API Y is greater than Z
    • this rule is used to integrate Connhex Rules Engine with Connhex AI

Rules and Connhex IAM​

For every CRUD operation on a rule, the Connhex Rules Engine service emits a notification. This is used by Connhex IAM to update the policies related to the rule.

Structure​

A rule is defined by:

export interface CptRule {
  id: string;
  name: string;
  description?: string;
  processable: CptProcessable;
  conditions: Partial<CptCondition>[];
  notification?: {
    messages: {
      policy: CptNotificationPolicy;
      medium: CptNotificationMedium;
      text: string;
    }[];
  };
  status: CptActivityStatus;
  createdAt?: string;
  updatedAt?: string;
  deletedAt?: string;
}

export enum CptProcessable {
  Enabled = 'enabled',
  Disabled = 'disabled',
}

In particular:

  • name and description allow the user to identify the rule
  • conditions represents the conditions that must be applied to the processing
  • notification specifies the notification modes associated with the rule. The policy field defines for each notification whether it should be sent:
    • when the conditions that trigger the processing are met (trigger)
    • when the conditions above are met again (reentry)
    • if you want to send a notification in both cases, you can simply add two distinct elements to the messages array: this allows you to specify different notification texts
  • status represents the current status of the rule, based on the data and the conditions.