Skip to content

DeviceBoard Alarms & Notifications – Complete User Guide

DeviceBoard Alarms & Notifications – Complete User Guide

DeviceBoard Alarms & Notifications – Complete User Guide

This document explains how Alarms and Notifications work inside DeviceBoard, how to configure them, trigger them through telemetry and RulesFlow, and display them on dashboards.

DeviceBoard offers a powerful event-driven alerting system that lets users detect abnormal conditions, notify users, and take automated actions.

1. Introduction to Alarms in DeviceBoard

An Alarm in DeviceBoard represents an event that indicates:

  • An abnormal condition
  • A failure event
  • A threshold violation
  • A predicted AI anomaly
  • A rule-based decision in RulesFlow

Alarms help users monitor device health, operational risks, safety conditions, and performance metrics.

Key Alarm Capabilities

  • Auto-create & auto-clear based on rules
  • Multilevel severity
  • Rich metadata (originator, timestamps, attributes)
  • Acknowledgment workflow
  • Trigger notifications (Email/SMS/Webhook)
  • Display on dashboards using Alarm widgets
  • Fully integrated with RulesFlow

2. Alarm Lifecycle Overview

DeviceBoard supports a standard lifecycle for alarms.

2.1 Alarm States

State Meaning
Active Unacknowledged Alarm is currently active; user has not acknowledged it.
Active Acknowledged User has acknowledged the alarm, but the cause still exists.
Cleared Unacknowledged Condition has cleared but user hasn’t acknowledged yet.
Cleared Acknowledged Final state; resolved + acknowledged.

2.2 Alarm Events Generated

Each state change generates events:

  • Alarm Created
  • Alarm Updated (severity, details, duration)
  • Alarm Cleared
  • Alarm Acknowledged
  • Alarm Deleted (if system configured to auto-clean)

These events can be consumed by widgets, automation rules, and external systems.

3. Alarm Structure in DeviceBoard

Primary Fields

  • Alarm ID
  • Device or Asset Originator
  • Alarm Type
  • Severity (Critical/Major/Minor/Warning/Indeterminate)
  • Status (Active/Acknowledged/Cleared)

Time Information

  • Start Time
  • End Time
  • Acknowledge Time
  • Clear Time
  • Total Duration

Details (JSON Object)

Used to store:

  • Expected vs actual values
  • Threshold triggered
  • Model prediction results
  • Contextual telemetry

Example details JSON:

{
  "measured_value": 92,
  "threshold": 75,
  "reason": "Temperature too high"
}

4. Creating Alarms with RulesFlow

Alarms in DeviceBoard are almost always created through RulesFlow.

4.1 Alarm Creation Node

Use Alarm Rule Node to automatically create alarms.

Node Configuration Includes:

  • Alarm Type (e.g., “TempHigh”, “VibrationAlert”)
  • Severity
  • Condition (JS expression, filter, or telemetry check)
  • Auto-clear condition
  • Alarm metadata
  • Whether to propagate alarm upstream or downstream in the flow

4.2 Example: Temperature Alarm Rule

Trigger Condition
If telemetry temperature > 70

Auto Clear
If telemetry temperature <= 65

5. Alarm Propagation in RulesFlow

Alarms in DeviceBoard can propagate across:

  • Other rule nodes
  • Linked devices
  • Asset hierarchies
  • User notification flows

This enables:

  • Facility-level alerts based on child devices
  • Automated routing for notifications
  • Global monitoring dashboards

6. Manual vs Automatic Alarms

6.1 Automatically Generated Alarms

These come from:

  • RulesFlow logic
  • Anomaly detection models
  • Threshold checks
  • Predicate rule nodes

6.2 Manual Alarms

Users may create alarms via:

  • REST API
  • DeviceBoard UI (Admin/Operator)
  • Custom scripts

7. Alarm Severity Levels

DeviceBoard provides predefined severity levels:

Severity Use Case
Critical Unsafe operating conditions
Major High probability of device failure
Minor Noticeable deviation from normal behavior
Warning Situations requiring attention
Indeterminate Condition detected but severity unknown

8. Clearing and Acknowledging Alarms

8.1 Acknowledge

Marks the alarm as seen by a user.

8.2 Clear

Indicates that the underlying issue is resolved.

Devices or rules can auto-clear the alarm based on logic.

9. Alarm Storage and Retention

All alarms are stored in the Alarm Table.

Stored Data Includes:

  • Severity
  • Metadata
  • Start/end time
  • Clear/acknowledge time
  • Device ID
  • Alarm type

Retention Policies

Admins can configure retention by:

  • Maximum days
  • Maximum record count
  • Automatic archival or deletion

10. Notifications System

Notifications alert users when alarms occur.

DeviceBoard supports:

10.1 Notification Channels

  • Email
  • SMS
  • Mobile Push Notification
  • Web Notifications
  • Webhook/REST Callback
  • Messaging Integrations (Slack, Teams if enabled)

10.2 Notification Triggers

Notifications can be triggered by:

  • Alarm created
  • Alarm severity change
  • Alarm cleared
  • Alarm acknowledged

10.3 Notification Templates

Users can configure templates with placeholders:

Example:

Device: ${deviceName}
Alarm: ${alarmType}
Severity: ${severity}
Triggered At: ${ts}
Details: ${details}

11. Notification Groups & Routing Rules

User Groups

Admins define groups like:

  • Operators
  • Maintenance Team
  • Supervisors
  • Safety Team

Routing Rules

RulesFlow determines:

  • Which group to notify
  • Which channel to use
  • When to escalate if no acknowledgment

12. Alarm & Notification Widgets

DeviceBoard includes widgets to visualize alarms:

12.1 Alarm List Widget

Shows:

  • Active alarms
  • Severity filters
  • Device filters
  • Acknowledge/Clear actions

12.2 Alarm Cards

Compact view for dashboards.

12.3 Alarm Timeline Widget

Shows alarms over time, grouped by device or severity.

12.4 Notification Status Widget

Shows sent notifications and delivery status.

13. Typical Use Cases

Use Case 1: Temperature Threshold Alarm

  • Device sends temperature = 90
  • RulesFlow triggers “High Temperature” alarm
  • Email sent to maintenance
  • Dashboard alarm widget highlights alert

Use Case 2: AI Anomaly Detection

  • AI model outputs anomaly_score > 0.7
  • RulesFlow triggers anomaly alarm
  • Alarm stored + real-time visualization

Use Case 3: Predictive Maintenance

  • Predicted failure probability > 0.5
  • Alarm is created
  • Auto-escalation if not acknowledged in 30 minutes

Use Case 4: Battery Low Notification

  • Telemetry battery_level < 20%
  • Alarm created
  • Mobile push sent to field technicians

14. Troubleshooting Alarms & Notifications

Issue Solution
Alarm not appearing Check RulesFlow logic and alarm enable flags
Notifications not delivered Verify channel configuration (email/SMS credentials)
Alarms not clearing Review auto-clear conditions
Users not receiving alerts Check user group membership & permissions

15. Best Practices

  • Use structured alarm names like TemperatureHigh, OverVoltage, AI_Anomaly.
  • Store contextual telemetry inside alarm details.
  • Use auto-clear conditions to reduce alarm clutter.
  • Use acknowledge workflow to maintain operator accountability.
  • Configure notification rate-limits to avoid spam.
  • Use dashboard widgets to centralize monitoring.