IoT Device Automation Without Custom Backend Code

Every connected product eventually needs event-driven logic that runs automatically: send an alert when temperature exceeds a threshold, aggregate readings before uploading to save bandwidth, trigger a notification when a device hasn't been seen in 30 minutes, run a daily energy report, enable a local output when a sensor condition is met offline.

Connhex provides two IoT rule engines that handle automation declaratively, without custom backend development: one in the cloud, one at the edge.

The challenge with IoT automation​

Automation logic in IoT products tends to be scattered across multiple layers and becomes a maintenance burden:

• Threshold alerts hardcoded in firmware: changing the threshold means a firmware release and an OTA campaign, even though it's a business rule, not a firmware concern.
• Custom backend services for event detection: a dedicated microservice that watches a data stream and fires webhooks when conditions are met, now a service to deploy, monitor, and maintain.
• No historicization: when an alert fires, there's often no record of the conditions that triggered it, which makes debugging and auditing hard.
• Bandwidth waste from redundant data: devices that report every reading, even when nothing has changed, generate costs in data transfer and storage. Filtering this at the source requires custom firmware logic.
• Offline behavior: a device that loses cloud connectivity should continue to react to local conditions, enabling an output, triggering a local alarm, without that logic being hardcoded in firmware or requiring a cloud round-trip.

Two rule engines, two layers​

Connhex addresses automation at two distinct points in the data flow:

Cloud Rules Engine: act on data that has reached Connhex Cloud​

Connhex Rules Engine runs in the cloud and operates on device data already ingested. It consists of three components:

• Rules: define what to monitor, the conditions that must be met, and what actions to take when they are.
• Conditions: evaluate incoming telemetry against configured thresholds, metric trends, or variation patterns. Multiple conditions can be combined.
• Events: every rule execution is recorded as a historicized event, creating a complete audit trail of when each condition was triggered and what action was taken.

Use the cloud Rules Engine for:

• Threshold-based notifications: "if this device's temperature reading exceeds 85°C, send a push notification to the assigned installer and create a maintenance event."
• Trend and variation alerts: detect that a metric is drifting or its rate of change is anomalous, without waiting for a fixed threshold to be crossed. Rules can be defined against metric trends and variations with no predefined absolute value.
• Scheduled actions: run a daily summary of device activity across a fleet, or generate a weekly energy consumption report.
• Cross-device conditions: trigger an action based on the combined state of multiple devices (not yet possible at the edge).
• Integration triggers: send a webhook to an external system (ticketing, ERP, CRM) when a specific device event occurs.

Rules are created and modified through the API or Connhex Control, no backend deployment required. Changing a threshold means updating a rule configuration, not a code release.

Edge Rules Engine: act on data before it leaves the device​

Connhex Edge's Rule Engine addon runs locally on the device and processes data streams before they are sent to the cloud. Rules are expressed as SQL queries (compatible with eKuiper's query language) and operate on local data subjects.

Use the Edge Rules Engine for:

• Data decimation: instead of sending every sensor reading, send only aggregated values over a time window, "average humidity over the last 5 seconds", reducing data transfer and cloud storage costs.
• Conditional upload: only send data to the cloud when something meaningful happens, "upload only when temperature exceeds 30°C." Eliminates noise and saves bandwidth on metered connections.
• Offline conditional flows: control local outputs based on sensor state, enable a relay, trigger a local alarm, without a cloud round-trip and without this logic living in firmware. The edge continues operating correctly even when connectivity is lost.
• Pre-processing for downstream services: transform or filter raw sensor data before it reaches the Mapper or cloud ingestion pipeline.

Because the Edge Rules Engine runs on the device, it continues to operate during cloud disconnections. This makes it the right layer for safety-critical or latency-sensitive reactions.

Choosing the right layer​

What this means for your team​

The practical implication is that business logic (alerting thresholds, notification routing, data aggregation windows, conditional upload rules) can be managed without engineering involvement after the initial setup. A product manager can adjust an alert threshold or add a notification recipient through a configuration change. An operations team can update fleet-wide rules through the API.

This matters most in two situations: during the product iteration phase, when rules change frequently as you learn what customers actually want from their alerts; and in customer-specific deployments, where different enterprise accounts need different threshold configurations without separate code branches for each one.

For connected product teams, the practical payoff is faster iteration on alerting and automation logic, fewer deployments for business-rule changes, and the ability to offer customers configurable alert behavior, a premium feature, without engineering work per customer.

Relevant verticals​

Device automation rules are used across all Connhex verticals. A few examples:

• HVAC: alert the installer when a thermostat hasn't responded in 30 minutes; aggregate energy readings hourly before uploading → Connhex for HVAC
• Vending machines: trigger a restocking notification when stock drops below a threshold; upload telemetry only on state change → Connhex for Vending Machines
• Industrial washing: trigger a maintenance alert on vibration anomaly; enable a local safety cutoff without cloud round-trip → Connhex for Industrial Washing Machines

Read the technical docs​

• Cloud Rules Engine, Introduction
• Cloud Rules Engine, Rules
• Cloud Rules Engine, Conditions
• Edge Rule Engine addon