The EdgeIQ Developer Hub

Welcome to the EdgeIQ developer hub. You'll find comprehensive guides and documentation to help you start working with EdgeIQ as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    API Reference

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:


   "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": {
    "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.


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.

Updated 26 days ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.