Policies

EdgeIQ includes robust polices that power many features of the system, such as monitoring and alerts, data orchestration, and taking action based on device status. Policies are defined in the system as Rules. Rules are defined as JSON objects and are created, retrieved, updated, and deleted via REST APIs. See Rules API documentation for more details.

For example, consider how one might create rules for a simple wireless temperature sensor. Before rules can be defined, all of the following needs to be in place:

• A Device Type is defined for this particular type of temperature sensor.
• A Device is defined for the temperature sensor we're working with.
• An Ingestor is defined to listen for incoming reports that the temperature sensor is emitting.
• A Translator is defined to translate reports received from the device protocol to EdgeIQ's report JSON format.

When these pieces are in place, we can define rules that examine data within translated reports that have been emitted by the device. A rule consists of 3 main parts:

1. A rule condition, which when evaluated against a received report, will evaluate to either true or false.
2. One or more rule actions, which specify what actions to take (depending on whether the rule evaluated to true or false).
3. One or more devices, and/or device types to which the rule applies.

In this case, the sensor is reporting a temperature value of 101.9:

Report:

{
   "device_datetime": "2017-05-30T20:59:00.308Z",
   "device_id": "592e3174b68b78d1b87e10e3",
   "payload": {
      "battery_level": 99,
      "device_name": "d05fb84d40de",
      "external_power": true,
      "function_code": 1,
      "interval": 15,
      "temperature": 101.9
   }
}

Rule:

{
  "rule": {
    "active": true,
    "cloud_rule": false,
    "description": "Warn if device temperature exceeds threshold",
    "rule_condition": {
        "type": "greater_than",
        "property": "temperature",
        "value": 101.0
    },
    "then_actions": [
        {
            "type": "sms_rule_action",
            "integration_id": "597a11daf15559c5e3491777",
            "send_to": "13334445555",
            "action_frequency": 0,
            "body_template": "Uh oh, the temperature for device {{ .Device.UniqueId }} is {{ .Report.Payload.temperature }}",
        }
    ]
  }
}

Rule conditions

A rule condition is defined as a JSON object within a rule. Each rule has exactly one rule condition, but this can be comprised of multiple rule conditions combined with boolean logic (AND, OR). The rule conditions are evaluated against one or more values within the report payload received from the device.

Example:

This rule condition will evaluate to true when the Report's payload property temperature is equal to 101.

...
"rule_condition": {
    "type": "equal",
    "property": "temperature",
    "value": 101
}
...

Rule actions

Rule actions are triggered when a rule condition evaluates to true ("then" actions) or false ("else" actions). A rule has a single rule condition, but can define multiple "then" and "else" actions.

A rule action can have an associated action frequency, which is used to limit how often the action will be taken when a rule condition is continuously met. For example, if a rule is defined to send an SMS when temperature > 100 degrees and the device is reporting every 30 seconds, the receiver probably doesn't want to receive an SMS every 30 seconds.

Certain kinds of rule actions, for example http, allow you to relay data directly to another system. To forward the payload of the report "as is", leave the body_template field blank. For more information about templating messages, and a full list of conditions and action types, consult the Rules API documentation.