Alarmbridge Service - Heartbeat Function

Download OpenAPI specification:Download

Heartbeat Function

Overview

Alarm devices typically send periodic messages, known as heartbeat requests, to indicate they are operational. The frequency of these messages depends on the device configuration and protocol. In large-scale deployments, managing high volumes of heartbeat traffic can become resource-intensive.

The Heartbeat Function in Alarmbridge Service optimizes this process by reducing unnecessary traffic. Instead of forwarding every heartbeat message, the function tracks device states and only reports state changes to the ARC platform. This ensures that the system integrated with Alarmbridge receives only relevant updates, such as when a device transitions between online and offline states.

Enabling the Heartbeat Function

The function is activated on a per-device basis by setting the heartbeatInterval property in the alarmBridge configuration object when provisioning a device. This property defines the maximum allowed time between two consecutive heartbeat messages before a device is marked as offline. The interval is specified in milliseconds.

Additionally, heartbeat monitoring can be configured at the event receiver level by setting the defaultHeartbeatInterval property. This ensures that all devices connecting through a particular event receiver have a default heartbeat interval if not explicitly set on the device.

Example Configuration

Device-Level Heartbeat Interval

{
    "serviceData": {
        "alarmBridge": {
            "heartbeatInterval": 300000
        }
    }
}

In this example, if a device does not send a heartbeat message within 300,000 milliseconds (5 minutes), it will be considered offline.

Event Receiver-Level Default Heartbeat Interval

{
    "eventReceiver": {
        "protocol": "scaip",
        "destinationMatch": "scaipalarms",
        "defaultHeartbeatInterval": 600000
    }
}

In this example, all devices using this event receiver will default to a heartbeat interval of 600,000 milliseconds (10 minutes) unless overridden at the device level.

Handling Incoming Heartbeat Messages

Alarmbridge maps all incoming alarm events to a common event format. When an event with deviceType: 'heartbeat' is received, the function follows this process:

  1. Check if Heartbeat Function is Enabled:

    • If disabled, the heartbeat event is forwarded like any other event.

    • If enabled, the event is acknowledged, and the device’s state is verified.

  2. Update Device State:

    • If the device is already online, the function updates the expiration timestamp but does not generate an event.

    • If the device was offline or has never sent a heartbeat before, the function updates the state to online and issues an event with:

      {
          "deviceType": "heartbeat",
          "statusCode": "online"
      }
      

Detecting Offline Devices

Each time a device sends a heartbeat message, its state is updated with an expiration timestamp. If a new heartbeat is not received before this timestamp, the device is marked as offline.

Offline Device Detection Process

  • The Heartbeat Function runs a check every five minutes to detect expired timestamps.

  • If a device’s timestamp has expired, its status is updated to offline, and the following event is generated:

    {
        "deviceType": "heartbeat",
        "statusCode": "offline"
    }
    

This mechanism ensures timely detection of inactive devices while minimizing network overhead.

Summary

  • The Heartbeat Function helps optimize large-scale deployments by reducing unnecessary heartbeat traffic.

  • Heartbeat monitoring can be configured per device or at the event receiver level using heartbeatInterval or defaultHeartbeatInterval.

  • Device state changes (online/offline) are the only events reported to the integrated system.

  • The system periodically checks for devices that have missed their heartbeat deadlines and updates their state accordingly.

By using the Alarmbridge Heartbeat Function, organizations can efficiently monitor device availability while reducing processing and bandwidth demands.