Skip to main content

Rule Chains

Rule Chains are the automation engine of SensoCAN. They process incoming sensor data through a visual node-based workflow to trigger alerts, transform data, or perform custom logic.

Overview​

When a device sends telemetry data, it flows through configured Rule Chains. Each Rule Chain is a series of connected Nodes that process, filter, or act on the data.

Example Flow:

Sensor Reading → Filter (Temp > 50°C?) → Send Email Alert

Creating a Rule Chain​

  1. Navigate to Management > Rule Chains
  2. Click + Create Rule Chain
  3. Enter:
    • Name: Descriptive name (e.g., "High Temperature Alert")
    • Description: (Optional) Purpose of this rule chain
  4. Click Save

You'll be redirected to the visual Rule Chain editor.

Rule Chain Editor​

The editor is a drag-and-drop canvas where you:

  1. Add Nodes: Drag node types from the left sidebar onto the canvas
  2. Connect Nodes: Click and drag from one node's output port to another node's input port
  3. Configure Nodes: Click a node to edit its settings in the right panel
  4. Save: Click Save to persist your changes

Node Types​

Input Nodes​

Sensor Input​

Purpose: Entry point for sensor data into the rule chain.

This node is automatically triggered when a sensor reading arrives. It passes the sensor value and metadata to connected nodes.

Filter Nodes​

Filter nodes evaluate conditions and route data to either the "True" or "False" output.

Filter: Value Comparison​

Purpose: Compare sensor readings against static thresholds.

Configuration:

  • Operator: >, <, >=, <=, ==, !=
  • Comparison Value: Numeric value to compare against (e.g., 50)

Example: Trigger alerts when temperature exceeds 50°C.

Filter: Consecutive Threshold​

Purpose: Prevent false alarms by requiring multiple consecutive breaches.

Configuration:

  • Operator: Comparison operator
  • Threshold Value: Value to compare against
  • Consecutive Count: Number of times the condition must be met in a row (e.g., 3)
  • Time Window: (Optional) Maximum time between readings

Example: Only alert if temperature is above 50°C for 3 readings in a row.

Filter: Time Range​

Purpose: Only process data during specific time periods.

Configuration:

  • Days of Week: Select which days (Mon-Sun)
  • Start Time: Beginning of active period (e.g., 09:00)
  • End Time: End of active period (e.g., 17:00)
  • Timezone: Device timezone

Example: Only send alerts during business hours (Mon-Fri, 9am-5pm).

Filter: Sensor Type​

Purpose: Route data based on sensor type.

Configuration:

  • Sensor Types: Select which sensor types to match (Temperature, Humidity, GPS, etc.)

Example: Apply specific processing only to GPS sensors.

Filter: Notification Type​

Purpose: Filter notifications by their type (for downstream processing).

Configuration:

  • Notification Types: Select types to match

Example: Route SMS notifications differently from email notifications.

Filter: Script​

Purpose: Custom JavaScript logic for complex conditions.

Configuration:

  • Script: JavaScript code that returns true or false

Available Variables:

  • value: Current sensor reading
  • metadata: Additional data from the sensor
  • previousValue: Last sensor reading (if available)

Example Script:

// Alert if value increased by more than 10% from previous
return previousValue && (value > previousValue * 1.1);

Transformation Nodes​

Transform: Value​

Purpose: Modify sensor values before processing (e.g., unit conversion, scaling).

Configuration:

  • Operation: multiply, divide, add, subtract
  • Value: Numeric value for the operation

Example: Convert Fahrenheit to Celsius: (value - 32) * 0.5556

Enrichment Nodes​

Enrichment: Attribute​

Purpose: Add device attributes to the data flow for use in downstream nodes.

Configuration:

  • Attribute Keys: Select which device attributes to include

Example: Add device location or firmware version to notification messages.

Enrichment: Metadata​

Purpose: Add custom metadata fields.

Action Nodes​

Action nodes perform operations when data reaches them.

Action: Send Email​

Purpose: Send an email notification.

Configuration:

  • To: Recipient email address(es) (comma-separated)
  • Subject: Email subject (supports variables: {{sensorName}}, {{value}})
  • Body: Email body (supports HTML and variables)

Available Variables:

  • {{deviceName}}: Name of the device
  • {{sensorName}}: Name of the sensor
  • {{value}}: Current sensor reading
  • {{timestamp}}: Reading timestamp

Action: Send SMS​

Purpose: Send an SMS text message.

Configuration:

  • Phone Number: Recipient phone number (E.164 format: +1234567890)
  • Message: SMS text (max 160 characters, supports variables)

Note: SMS messages consume your tenant's monthly SMS quota.

Action: System Notification​

Purpose: Create an in-app notification visible in the platform.

Configuration:

  • Title: Notification title
  • Message: Notification body
  • Severity: info, warning, critical

Action: Save Timeseries​

Purpose: Persist the sensor reading to the database.

Configuration:

  • Enabled: Always enabled by default

Note: This node is typically always included in rule chains to store data.

Action: Log​

Purpose: Write debug information to the system logs.

Configuration:

  • Log Level: debug, info, warning, error
  • Message: Log message (supports variables)

Testing a Rule Chain​

  1. Open the Rule Chain in the editor
  2. Click the Test button in the top-right
  3. Enter sample sensor data: 
    {
      "sensor_id": 123,
      "value": 55,
      "timestamp": "2023-10-27T10:00:00Z"
    }
  4. Click Run Test
  5. The editor will highlight the path the data took through the nodes

This helps validate your logic before deploying to production.

Best Practices​

1. Always Save Timeseries​

Include the "Save Timeseries" action node in every rule chain to persist sensor data.

2. Use Consecutive Thresholds​

For noisy sensors, use the Consecutive Threshold filter to prevent alert fatigue.

3. Limit SMS Usage​

SMS messages have costs. Use email or system notifications when possible.

4. Test Before Activating​

Always test rule chains with sample data before enabling them on live sensors.

5. Name Nodes Clearly​

Rename nodes to describe their purpose (e.g., "High Temp Filter" instead of "Filter 1").

Troubleshooting​

Data Not Flowing Through​

  • Check that all nodes are properly connected
  • Verify the sensor is sending data
  • Use the Test feature to debug

Notifications Not Sending​

  • Check your tenant's SMS/Email quota
  • Verify email addresses and phone numbers are valid
  • Check the system logs for error messages

Rule Chain Not Triggering​

  • Ensure the Rule Chain is enabled
  • Verify the sensor is assigned to the correct Rule Chain
  • Check filter conditions are correctly configured