Technical Brief: Rule Chains and Business Logic in VX-Olympus

Overview

Data collected from IoT sensors has no operational value until something evaluates it and decides what to do. A temperature reading at 92°F means nothing without a rule that says: if temperature exceeds 85°F for more than 10 minutes, create a maintenance ticket and send an SMS to the on-call technician.

VX-Olympus’s rule engine — built on Node-RED — is the layer that bridges telemetry collection and operational response. Rule chains define the conditional logic, data transformation, alert routing, and automated actions that make a monitoring system operationally useful rather than just a data store.

This brief covers the rule engine architecture, the types of nodes available, multi-condition logic patterns, alert routing design, and common rule chain configurations used across industrial deployments.

Rule Engine Architecture

Node-RED as the Execution Environment

VX-Olympus uses Node-RED as its visual rule execution environment. Node-RED is an open-source flow-based programming tool developed by IBM, widely used in industrial IoT for logic that would otherwise require custom code.

In VX-Olympus, Node-RED runs server-side — rule chains execute within the platform’s backend, not on device firmware. This means rule logic can be updated without touching device configurations, can reference data from multiple devices simultaneously, and can access external APIs and databases.

Why visual programming matters for IoT business logic: The engineers and operations personnel who define alarm thresholds, escalation policies, and maintenance trigger criteria are rarely software developers. Node-RED’s visual flow interface allows operations engineers and system integrators to build and modify rule logic without writing code.

Rule Chain Execution Model

When a telemetry message arrives in VX-Olympus:

1. The message is authenticated and decoded (ingestion layer)
2. The message is written to time-series storage
3. The message is simultaneously dispatched to the rule engine

Rule chain evaluation is asynchronous relative to storage — it runs in parallel with the storage write, not sequentially. This means rule evaluation latency does not add to the time-to-storage path, and a slow rule chain does not delay data availability in the dashboard.

Within the rule engine, execution is sequential through the chain: each node receives the message, performs its operation, and passes the message (or a transformed version of it) to the next node. Branches diverge the flow — a filter node can route messages to different downstream paths based on evaluated conditions.

Node Types

VX-Olympus’s rule engine provides pre-built node types covering the most common IoT logic requirements:

Input Nodes

Telemetry input: The entry point for device telemetry. Each rule chain is associated with one or more device profiles or specific devices. When a matching device sends a telemetry message, the chain is triggered.

State input: Triggers when a device’s state changes — for example, when a device goes offline, comes back online, or when a persistent state attribute changes.

Scheduled input: Triggers on a time schedule rather than on incoming data. Used for periodic reporting, daily summaries, or scheduled commands to devices.

Filter Nodes

Attribute filter: Evaluates telemetry field values against conditions. Example: pass the message only if temperature > 85 and device_type == "refrigeration_unit".

Device type filter: Routes messages based on the device type, vertical, or tag. Allows a single rule chain to handle multiple device types with different downstream paths.

Time-of-day filter: Passes or blocks messages based on the time of day or day of week. Used for shift-aware alerting: alert the day shift team during day shift hours, the night shift team otherwise.

Deduplication filter: Suppresses repeated alerts for the same condition. If a temperature threshold breach triggers every 15 minutes while the condition persists, a deduplication filter limits alert delivery to once per hour — preventing alert fatigue without losing visibility.

Enrichment Nodes

Device attribute enrichment: Adds device attributes (site name, zone, manager name, contact info) to the telemetry message context. These attributes are then available to downstream action nodes for populating alert messages.

Customer data enrichment: Looks up external data sources (database, REST API) to add context. Example: look up the maintenance schedule for a machine and add “next_scheduled_service” to the message context.

Calculate node: Performs arithmetic on telemetry values. Examples: calculate power factor from voltage and current, convert Celsius to Fahrenheit, calculate OEE from run time and production count.

Action Nodes

SMS notification: Sends an SMS message to a configured phone number or group. The message body is templatable — it can include telemetry values, device name, site name, and current timestamp from the enriched message context.

Email notification: Sends email to configured addresses. Supports HTML email bodies with formatted tables for multi-value alerts.

Webhook POST: Calls an external HTTP endpoint. Used to integrate with ticketing systems (ServiceNow, Jira), CMMS platforms, ERP systems, or any system with a REST API. The POST body is templatable JSON.

Device command: Sends a downlink command to a device. Example: if temperature exceeds a threshold, send a command to increase the chiller setpoint. For LoRaWAN Class A devices, commands are queued and delivered in the next receive window.

Dashboard notification: Creates an in-platform notification visible to configured users. Lower urgency than SMS/email; appropriate for conditions that need visibility but not immediate response.

Write to state: Writes a value to the device’s state record. Used to set flags, counters, or derived values that should appear on dashboards alongside raw telemetry.

Multi-Condition Logic

Single-threshold rules — “alert if value exceeds X” — cover many cases. Production IoT deployments require more sophisticated logic:

AND Logic (All Conditions Must Be True)

Use case: Alert only when a machine is running AND vibration is elevated. Elevated vibration on a stopped machine is irrelevant. The alert should only fire when the machine is in a state where elevated vibration indicates a developing problem.

In Node-RED, AND logic is implemented with a Join node that collects conditions from parallel paths and passes the message only when all conditions are satisfied within a configurable time window.

OR Logic (Any Condition Triggers)

Use case: Alert if temperature exceeds upper threshold OR drops below lower threshold. Either direction is a problem condition; either should trigger the same maintenance team notification.

OR logic uses a Merge node — the downstream path activates when any upstream condition fires.

Time-Window Logic

Use case: Alert only if a condition persists for a configurable duration. A temperature spike that resolves in 30 seconds may be a transient reading artifact; the same temperature sustained for 10 minutes is a real condition.

VX-Olympus’s Duration node holds a message until it has been continuously matched for a configured time window. If the condition clears before the window expires, the held message is discarded. If the condition persists, the message is released to downstream action nodes.

Derived Metric Rules

Use case: Alert based on a calculated value, not a raw sensor reading. A rule that alerts when a motor’s current draw exceeds its baseline by more than 15% — accounting for normal startup current — requires a calculate node to derive the delta before the threshold comparison.

Use case: Alert on rate of change rather than absolute value. A bearing temperature rising 5°F per hour is a warning sign even if the absolute temperature is within normal range. A derivative calculation node computes the rate of change over a sliding window.

Alert Routing Design

Tiered Escalation

Production IoT systems need tiered alert routing — early warning conditions go to one group, critical conditions go to a different group, and conditions that remain unresolved escalate.

Pattern:

• Watch condition (early warning): in-platform notification to shift supervisor
• Warning condition (approaching threshold): SMS to maintenance team
• Critical condition (threshold exceeded): SMS to maintenance team + email to site manager
• Critical condition unresolved after 30 minutes: SMS to site manager + operations director

VX-Olympus implements escalation with a combination of the timer node and conditional routing. When a critical alert fires, a 30-minute timer starts. If the condition clears (tracked via a state write), the timer is cancelled. If the timer expires without the condition clearing, the escalation path fires.

Shift-Aware Routing

Alert routing that ignores shift schedules creates alert fatigue or missed notifications. A 3 AM alert to the day shift manager is ignored; the same alert to the on-call night shift contact gets a response.

VX-Olympus’s time-of-day filter nodes, combined with device attribute enrichment (which can carry shift contact information as device or tenant attributes), route alerts to the correct recipient based on the time of the triggering event.

Multi-Site Hierarchy Routing

For multi-site deployments, alert routing should follow the organizational hierarchy: site-specific alerts go to site personnel, alerts across a site group escalate to the area manager, and system-wide alerts reach the operations director.

VX-Olympus’s multi-tenant structure organizes devices and alert routing by tenant hierarchy. Rule chains can be defined at the tenant level (applying to all devices in that tenant) or at the individual device level (device-specific thresholds). Escalation paths follow the hierarchy.

Common Rule Chain Patterns

Pattern 1: Equipment Health Monitoring

Trigger: Continuous vibration or temperature telemetry from production equipment.

Logic:

1. Receive telemetry
2. Enrich with device attributes (machine name, line number, assigned maintenance tech)
3. Evaluate vibration against baseline + 15% threshold (calculated)
4. If threshold exceeded: check time-of-day filter, route SMS to appropriate shift contact
5. If critical threshold exceeded: send to shift supervisor + create webhook to CMMS

Key design considerations: Baseline calculation requires historical data; use a 30-day rolling average of the same machine’s normal operating readings rather than a fixed value.

Pattern 2: Cold Chain Compliance

Trigger: Temperature telemetry from refrigeration units.

Logic:

1. Receive temperature telemetry
2. Compare to setpoint range (e.g., 34–38°F for a walk-in cooler)
3. If above upper limit for >5 minutes: warning alert to store manager, write compliance event to state
4. If above upper limit for >15 minutes: critical alert, write compliance excursion record
5. If temperature returns to range: resolution event, calculate and log duration of excursion

Key design considerations: Time-window logic prevents false alarms from door openings. The duration between excursion start and resolution is the compliance record required for food safety documentation.

Pattern 3: Multi-Site Fuel Level Management

Trigger: Fuel level telemetry from tank monitoring sensors.

Logic:

1. Receive level reading (percent of tank capacity)
2. Calculate days-to-empty based on consumption rate (requires historical consumption calculation node)
3. If days-to-empty < configured reorder threshold: generate reorder webhook to fuel management system
4. If level drops below minimum reserve: critical alert regardless of days-to-empty calculation

Key design considerations: The reorder threshold should be configurable per-site to account for different delivery lead times and tank sizes.

Pattern 4: Device Offline Detection

Trigger: State change event (device transitions from online to offline).

Logic:

1. Receive offline state change event
2. Apply deduplication (only alert once per offline event, not on every missed heartbeat)
3. Determine if device is in business-hours context (offline devices during maintenance windows are expected)
4. Route alert to network admin with device name, last-seen timestamp, and device location

Key design considerations: Expected offline windows (maintenance, seasonal shutdowns) should suppress alerts. VX-Olympus maintenance mode flags suppress offline alerts for devices in scheduled maintenance.

Performance Considerations

Rule Chain Evaluation Latency

Simple threshold rules with no external lookups evaluate in 50–100 ms. Rules requiring historical data queries (rolling average, baseline comparison) add 100–300 ms for the database lookup. Rules that call external APIs via webhook (CMMS, ERP integration) add the external API response time — typically 200 ms–2 seconds.

Because rule chain evaluation is asynchronous from the data pipeline, this latency affects how quickly an action fires after a condition is detected — it does not affect dashboard data freshness.

Alert Volume Management

Design rule chains with explicit deduplication: alert once when a condition begins, optionally re-alert if the condition persists beyond a configurable window, and send a resolution notification when the condition clears. This pattern provides full visibility without flooding notification channels.

Rule Chain Versioning

VX-Olympus maintains version history for rule chain configurations. When a rule chain is modified, the previous version is retained and can be restored. This is particularly important for compliance-relevant rule chains (cold chain, environmental monitoring) where the threshold history may need to be auditable.

Related Technical Briefs

• Technical Brief: VX-Olympus Architecture — Sensor to Dashboard — where rule chain evaluation fits in the overall pipeline
• Technical Brief: Multi-Tenant Security Architecture — how rule chains operate within tenant isolation boundaries
• Technical Brief: MQTT vs HTTP vs CoAP — protocol selection for devices that receive commands from rule chains

Talk to our team about designing rule chains for your VX-Olympus deployment.