Configuring Rate of Change (ROC) in Alarm Rules

The Rate of Change (ROC) feature in Zoho IoT allows alarms to be defined based on how a datapoint value changes over time, rather than only on absolute values. This feature improves alarm rule configuration by allowing advanced conditions and simple calculations to be defined directly within the primary condition.

Note: The Rate of Change (ROC) feature in alarm rules is currently not available by default in the product. Contact support@zohoiot.com to avail the ROC feature.

For example, consider an administrator managing diesel generators in a facility who wants to detect abnormal operating conditions early to prevent breakdowns and unplanned outages. Instead of triggering alarms only when values cross fixed thresholds, the administrator can use the Rate of Change (ROC) feature in Zoho IoT to monitor how critical parameters change over time.

Rate of Change Use Cases

For better understanding, let us consider the below two instances of ROC-based alarm rule configuration for a diesel generator.

ROC-based alarm on the engine temperature

The administrator can configure a ROC-based alarm on the engine temperature datapoint. The alarm is set to trigger if the temperature increases by more than 8°C within 5 minutes, even if the absolute temperature is still within the safe operating range. This helps identify rapid overheating caused by issues such as cooling system failure or excessive load.

ROC-based alarm on the fuel level

Additionally, the administrator can apply a ROC rule on fuel level to detect sudden drops in a short duration, which may indicate fuel leakage or unauthorized fuel usage. By using ROC calculation options, the administrator can fine-tune conditions and compare changes precisely over defined intervals. If real-time data is temporarily unavailable, the rule automatically evaluates the next available saved datapoint value, ensuring uninterrupted monitoring.

Note: The ROC feature is available with limited access. Please contact support@zohoiot.com to enable the feature and for further details.

Why Use Rate of Change (ROC)

To summarize, ROC in alarm rules,

enables basic calculation capabilities on the alarm conditions.

provides greater flexibility in alarm rule creation for more precise and meaningful data monitoring.

allows the rule to use the next available saved datapoint value when real-time data is unavailable.

Types of Rate of Change

ROC feature in Zoho IoT supports both Absolute Rate of Change (AROC) and Relative Rate of Change (RROC), enabling alarms to be triggered based on how values change over time.

AROC: Computes the absolute difference between new and old values based on user-selected intervals.
RROC: Calculates the relative change percentage as ((Old−New)/Old)×100%.

Note:
* ROC calculation is available for numeric data points only.

* ROC feature is supported only for real-time alarm rules and is not yet implemented for KPI alarm rules.

Note:
Handling Missing Real-Time Data - Users can configure the rule to use the next available datapoint value when the current real-time value is unavailable.

Rate of Change (ROC) calculation in non-linear (erratic) patterns

In non-linear or erratic patterns, Rate of Change (ROC), the system evaluates changes over short time intervals to capture local trends instead of calculating using a simple linear slope.

Consider the scenario, where in a manufacturing unit, a CNC machining center is monitored for spindle vibration and motor temperature to predict bearing wear and tool imbalance. During normal operation, the machine frequently switches speeds and loads, causing vibration and temperature values to fluctuate in a non-linear and erratic manner. To avoid false alarms, the system calculates the average rate of change over short intervals (for example, every 5 minutes) and applies moving averages to smooth sudden spikes caused by tool changes or load variations.

With this approach, alarms are triggered only when a sustained upward trend is detected rather than reacting to momentary fluctuations.

Here’s how ROC is typically managed in Zoho IoT in such cases:

Short term time-based evaluation

Instead of reacting to every sudden spike or drop, ROC is calculated over a defined time window (for example, 5 or 10 minutes, etc.). This smooths out short-term noise and focuses on meaningful changes rather than instant fluctuations.
Aggregation before ROC calculation

For erratic signals, the system often applies aggregation (average, max, or min) to datapoints within the time window before computing the ROC. This reduces sensitivity to random spikes and makes the rate calculation more stable.
Thresholds tuned for trend detection

ROC thresholds are set to trigger only when changes exceed expected operational variations. This helps differentiate between normal non-linear behavior (such as load changes) and abnormal trends that indicate potential faults.

Creating an Alarm Rule with ROC

Note: Refer to the Alarm Rules creation document for the basic steps.

1. While creating the Alarm Rule State, click the Select Datapoint or Field option.
(Link to Alarm Rule creation document.)
Note: Currently, the ROC feature is supported only for real-time alarm rules and is not yet implemented for KPI alarm rules.
2. Set the toggle to Datapoint.
3. Select the datapoint from the displayed list of available datapoints, and click Next.

4. Select Rate of Change (ROC) option.
Note: Choosing the Current Value option instead of Rate of Change option uses the data point value as received. Refer Creating an Alarm Rule with Current Value document for complete details.

5. Select the Comparison Mode from the the drop down list.

Absolute Rate of Change(AROC): Computes the absolute difference between new and old values based on user-selected interval.
Relative Rate of Change(RROC): Calculates the relative change percentage as ((Old−New)/Old)×100%.

6. Select the Time Interval, Last Message, Minute(s), or Hour(s) to set the timeline for fetching this data.

7. Set the Absolute Value Only toggle to ON/OFF. Setting the toggle to ON helps to calculate the change value without a positive or negative sign.

8. Click Add.
9. The LHS of the Primary Condition is constructed and displayed.

10. Provide the operator and the value to verify in the condition.

Creating an Alarm Rule with Current Value

The Current Value option in the Set Condition part of alarm rule configuration uses the datapoint value as it is received. Here, if the datapoint value is missing, enabling Use Recent Value allows the system to retrieve the next available saved value.

Let us consider the scenario in a manufacturing plant, where an IIoT system continuously monitors the vibration level of a critical motor to detect early signs of mechanical failure. Due to intermittent network connectivity or brief sensor downtime, the motor may occasionally stop sending real-time vibration data.

To ensure uninterrupted alarm evaluation, the administrator can enable the Use Recent Value option in the alarm rule. When a real-time datapoint value is missing, the system automatically retrieves the most recent saved vibration value and uses it for condition checks. This allows alarms to continue functioning reliably, preventing gaps in monitoring and ensuring timely alerts even during temporary data loss.

To configure an alarm rule using the Current Value option,

Note: Refer to the Alarm Rules creation document for the basic steps.

1. While creating the Alarm Rule, in the Set Condition tab, click the Select Datapoint or Field option.
2. Set the toggle to Datapoint.
3. Select the datapoint from the displayed list of available datapoints, and click Next.

4. Select Current Value option.

Note: Choosing the Current Value option instead of Rate of Change option uses the data point value as received.

5. Select Use Recent Value to configure the application to retrieve the next available saved value if the datapoint value is missing.

6. Select a timeline, whether 5, 15, or 30 minutes for fetching the recent value.

Note: If a value is received immediately after enabling the Use Recent Value option, it will be considered, as it falls within all the specified timeline.

7. Provide the operator and the value to verify in the condition.