Guide to Event Detector Types in Mango

Overview

Event detectors are the foundation of Mango by Radix IoT’s alarm and monitoring system. They watch data point values and raise events when specific conditions are met.

The architecture has two parts:

• Event detectors — watch data point values and decide when something noteworthy happens
• Event handlers — decide what to do when a detector fires (send email, set a point, run a command)

This guide covers the detector side: every detector type, when to use it, and how to configure it effectively.

Prerequisites

• Admin or data source edit permissions
• At least one data source with active data points
• Basic understanding of data point types (numeric, binary, multistate, alphanumeric)

Detector Types Reference

Mango ships 18 point event detector types. When you add a detector, the Event detector type dropdown only offers the types that apply to that point's data type, so a numeric point and a binary point present different lists.

Every detector, whatever its type, also carries these settings:

• Event detector type — chosen once, on creation
• Event detector (name) and XID
• Alarm level — severity of the resulting event
• Time domain — Real time or Timestamp time (see the note at the end of this article)
• View event detector and Edit event detector permissions

High limit

What it does: Triggers when a numeric value exceeds a specified threshold.

When to use it: Over-temperature alerts, over-pressure warnings, high current draw, tank overflow prevention.

Key settings:

• Greater than / Less than or equal to — which side of the limit is the alarm condition
• High limit — the threshold
• Duration and Duration unit — how long the condition must hold before the event fires (prevents transient spikes from triggering alarms)
• Use a different limit for reset, Reset limit and Reset duration — the deadband and delay for returning to normal

Example: Supply air temperature point with a high limit of 85°F and a duration of 60 seconds. If the temperature exceeds 85°F for more than one minute, the alarm fires.

Low limit

What it does: Triggers when a numeric value drops below a specified threshold.

When to use it: Low battery voltage, low tank level, freezestat monitoring, low refrigerant pressure.

Key settings: the mirror of High limit — Less than / Greater than or equal to, Low limit, Duration, and the same Reset limit / Reset duration controls.

Example: Battery voltage point with a low limit of 11.5V and a duration of 30 seconds. If voltage stays below 11.5V for 30 seconds, the event fires.

Range

What it does: Triggers when a numeric value is within OR outside a defined band.

When to use it: When you need to monitor for a value band rather than a single threshold—acceptable operating range for a process variable.

Key settings:

• Outside range / Within range — whether to fire when the value leaves or enters the band
• Low range limit — bottom of the band
• High range limit — top of the band
• Duration — how long the condition must hold

Example: A humidity sensor should read between 30% and 60%. Set the range to 30–60 and select Outside range.

Analog change

What it does: Triggers when a numeric value moves by more than a set amount within a period, regardless of the absolute value.

When to use it: Catching step changes and jumps — a setpoint being moved, a sensor glitching, a meter reading that leaps rather than climbs.

Key settings:

• Increase / Decrease — which direction counts
• Change limit — how much movement is a problem
• Duration and Duration unit — the window the movement is measured over
• Update event — All, Changes only or Logged only, deciding which incoming values the detector considers

Important distinction: High limit cares where the value is. Analog change cares how far it moved. A point that jumps from 20 to 60 never breaks an 85 high limit but is an obvious analog change.

Rate of change

What it does: Triggers when a numeric value changes faster than a threshold rate — units per unit of time.

When to use it: Pressure rising too fast, tank draining faster than the process allows, temperature climbing at a rate that indicates a failure rather than a load change.

Key settings:

• Instantaneous / Average — whether the rate is taken between consecutive values or averaged over the window
• Greater than, Less than or equal to, Less than or Greater than or equal to — the comparison against the threshold
• Threshold and Threshold unit — the rate, expressed as units per second, minute, hour or day
• Use reset threshold and Reset threshold — the deadband for returning to normal
• Use absolute value — count movement in either direction
• Duration and Duration unit

Positive CUSUM

What it does: A cumulative sum detector for detecting gradual upward drift from a reference value.

Explained simply: Instead of alarming on a single spike, CUSUM tracks the running total of how far each value sits above the reference. Small, repeated deviations add up. When the accumulated total exceeds the limit, the detector fires. This catches slow, creeping increases that a simple high limit would miss. The running total is floored at zero, so values below the reference pull it back down but never negative.

Key settings:

• Positive limit — the cumulative deviation threshold
• Weight — the reference value deviations are measured from
• Duration and Reset duration

Negative CUSUM

What it does: The mirror of Positive CUSUM—detects gradual downward drift from a reference value.

Use case: Detecting slowly declining efficiency, gradual pressure loss, or slow temperature drop over time.

Key settings: Negative limit, Weight, Duration, Reset duration.

Smoothness

What it does: Scores how smooth a numeric signal is over a moving window and triggers when that score drops below a limit. A clean signal scores near 1; the noisier the signal, the lower the score.

When to use it: Sensor health. A signal that starts to jitter is often a failing transducer, a loose connection, or electrical interference — none of which move the value far enough to break a limit detector.

Key settings:

• Low limit — the smoothness score below which the event fires
• Boxcar length — the number of samples in the moving window. Minimum 3, and 3 is the default.
• Duration and Reset duration

Change

What it does: Triggers whenever the value changes at all, regardless of direction or magnitude.

When to use it: Binary or multistate points where any transition is significant—door open/close, equipment on/off, mode changes.

Key settings: Alarm level only.

Note: No duration setting for this detector, and no return to normal. Every change raises its own event immediately.

Point value update

What it does: Triggers on every update the point receives, whether or not the value changed.

When to use it: Sparingly. It is the tool for auditing that a point is being written to, or for driving a handler on every poll. On a fast-polling point it will generate an event per poll.

Important distinction: Change fires only when the value is different. Point value update fires even when the same value arrives again.

No change

What it does: Triggers when a value has not changed for a specified duration.

When to use it: Detecting stuck sensors, frozen readings, or equipment that should be cycling but isn't.

Key settings: Duration and Duration unit.

Example: A temperature sensor that hasn't changed value in 2 hours likely has a problem. Set Duration to 2 and Duration unit to hours.

No update

What it does: Triggers when a data point has not received any update (poll) for a specified duration.

Important distinction: No change means the value stays the same. No update means the point stopped receiving data entirely. No update indicates a communication failure—the data source is not polling or the device is unreachable.

Key settings: Duration and Duration unit.

Example: A Modbus point that normally polls every 5 seconds hasn't updated in 60 seconds. This likely means the device or network connection is down.

State

What it does: Triggers when the point sits in a nominated state. It is one dropdown entry with three implementations, picked automatically from the point's data type — binary, multistate, or alphanumeric.

When to use it: Monitoring for specific operating modes or fault states on equipment that reports status as a state rather than a number.

Key settings (multistate):

• When state is / When state is not — match or invert
• State — the state to match
• Detect multiple states and States — match any of several states instead of one
• Duration and Reset duration

On a binary point State is a Zero / One choice. On an alphanumeric point State is matched as an exact, case-sensitive string — for a pattern, use the Regex detector below.

Example: An AHU reports state 4 as "Fault." Set When state is and State to 4.

Bitmask

What it does: Triggers on individual bits within a multistate value.

When to use it: Devices that pack several independent flags into one status register — a common BACnet and Modbus pattern where bit 0 is "running", bit 2 is "fault", and so on.

Key settings:

• When state matches / When state doesn't match — match or invert
• Bitmask — entered as a hexadecimal value. The detector fires when the value ANDed with the mask is non-zero, so a mask selects one or more bits at once.
• Duration and Reset duration

Regex

What it does: Triggers when an alphanumeric value matches a regular expression.

When to use it: Monitoring status messages, log outputs, or any text-based data point where you need a pattern rather than an exact string.

Key settings: Regex, Duration, Reset duration.

Example: A device that returns a status string containing "ERROR" should trigger a warning event. The pattern is searched for anywhere within the value, so ERROR on its own is enough — no wildcards or anchors needed.

State change count

What it does: Triggers when a value changes more than N times within a specified time window.

When to use it: Detecting flapping or chattering equipment—a relay cycling on and off rapidly, a damper oscillating, a status that keeps toggling.

Key settings:

• State change count — number of changes that constitute a problem. Minimum 2, and 2 is the default.
• Duration — the time window to count changes within

Note: This detector is offered on binary, multistate and alphanumeric points only. It is not available on numeric points — for a noisy numeric signal, use Smoothness or Analog change instead.

Example: A compressor status point that changes more than 10 times in 5 minutes is short-cycling and needs attention.

Setting Alarm Severity Levels

Every event detector requires an alarm level. Use severity consistently across your system to ensure operators can prioritize effectively. Note the two labels that catch people out: the lowest logged level is called Minor, not "None", and the highest is Safety, not "Life Safety".

Duration Settings (Debouncing)

Duration is one of the most important settings in event detection. It prevents transient spikes or momentary dips from triggering alarms. It is entered as a number plus a Duration unit — seconds, minutes, hours or days — so long windows do not have to be converted into seconds.

How it works: When you set a duration of 60 seconds on a high limit detector, the value must stay above the limit continuously for 60 seconds before the event fires. If it dips back below the limit at any point during that 60 seconds, the timer is cancelled and the count starts again from the next crossing.

Reset duration is the mirror image: once the event is active, the clear condition must hold for the reset duration before the event returns to normal. Set it when you want the alarm to persist briefly after conditions recover.

Guidelines:

• 0 seconds (instant) — Not recommended for most use cases. Every transient spike fires an alarm.
• 30–60 seconds — Typical for process values like temperature and pressure. Filters out noise while still catching real problems quickly.
• 5–15 minutes — Appropriate for slow-moving values or situations where brief excursions are acceptable.

How to choose: Consider the normal fluctuation range of your data point. If a value routinely bounces 2–3 degrees above your limit for a few seconds during normal operation, set the duration long enough to ignore those bounces (30–60 seconds). If even a momentary excursion is dangerous (e.g., life safety), use a very short or zero duration.

Note: Not every detector supports a duration. The Change and Point value update detectors fire on the event itself and have no duration and no return to normal.

Connecting Detectors to Handlers

Detectors raise events. Handlers respond to them. Without a handler, your detector will still log the event in Mango's event history, but nobody will be notified.

Mango core provides four handler types, listed in the handler Type dropdown as:

• Email — sends an email notification when the event fires (see Configuring Event Handlers and Email Alerts)
• Set point — writes a value to another data point (e.g., shut down equipment)
• Process — runs an operating-system command
• Script — runs a Mango script

Installed modules add more to the same dropdown: with the Excel Reports, SNMP and Slack modules installed it also lists Excel report, SNMP and Slack message, seven types in all. How to Configure Event Handlers: Email, Scripts, Set Points, and Process covers all seven; see it and Configuring Event Handlers and Email Alerts for detailed instructions.

Event Permissions

If a user has view permission on a data point, they automatically have view permission on all events raised by that point's detectors — Mango resolves an event's permission to the read permission of the point that raised it. You do not need to assign event permissions separately when the user can already see the underlying point.

The detector itself carries its own View event detector and Edit event detector permissions, which control who can see and change the detector's configuration. That is separate from who can see the events it raises.

Best Practices

• Start with the essentials: High limit, low limit, and no-update detectors cover the majority of monitoring needs. Add other types as you learn your system's behavior.
• Always set a duration to avoid nuisance alarms. Even 15–30 seconds eliminates most transient noise.
• Use severity levels consistently. Define what each level means for your organization and stick to it. If everything is "Critical," nothing is.
• Test your detectors with an approved simulation or a controlled test point — never by forcing a production value solely to trigger an alarm. Verify the event fires and any handlers respond correctly.
• Document your alarm setpoints. Keep a record of what limits you set and why, so future operators understand the reasoning.
• Review alarm frequency. If a detector fires more than a few times a day, either the limit is set too tight or there is a real problem that needs fixing—not just alarming.
• Layer multiple detectors at different severities on the same point. For example, a supply temperature point might have a Warning at 85°F, an Urgent at 90°F, and a Critical at 95°F. This gives operators graduated escalation instead of a single on/off alarm.
• Use a consistent naming convention for detectors. Include the device ID, point name, limit type, and level—for example, RTU-01_SupplyTemp_HighLimit_Warning. This makes detector lists searchable and unambiguous when reviewing alarm history.
• Reach past the limit detectors when a limit will not catch the fault. A failing sensor that jitters without leaving its normal band is a Smoothness problem; a value that leaps rather than drifts is an Analog change problem; a value climbing too fast for the process is a Rate of change problem.

Troubleshooting