AE IP-RCT¶

Capabilities¶

Capability	Support	Comment
Configuration of the IP-RCT (provisioning)		This feature is currently not supported. In case of interest please contact us at info@swissdotnet.ch
IP-RCT connection state monitoring		See RCT connection monitoring
SPT connection state monitoring		Only for supported protocol (DC-09, TS-50136-9). See SPT connection monitoring
Virtual cluster of IP-RCT		See IP-RCT clustering
Changing administrative state of a SPT		See Pre-receive hook for alarms
Fetching the administrative state of a SPT		This feature is currently not supported. In case of interest please contact us at info@swissdotnet.ch
Handling alarms		See Handling alarms
Pre-receive hook for alarms		Execute action before acknowledging the received alarms, this can be done to choose the answer (ACK/NACK). See Pre-receive hook for alarms
Sending remote order (command)		See Remote orders

Examples¶

Create an alarm from a DC 09 alarm

IP-RCT clustering¶

Concept¶

Warning

The following description applies to most of the fire installation compliant with the EN-50136 norm but there are some cases where the installation can be different with this standard configuration.

In many setups, at least two IP-RCT devices work together to handle alarms. While these devices synchronize for history, configuration, and statistics, it’s crucial to note that each alarm needs to be acknowledged by the same device that initially received it. To elaborate, if an alarm is sent to a specific IP-RCT, say, IP-RCT A, OnSphere must be connected to IP-RCT A as the designated alarm receiver. This connection is necessary because the alarm receiver may vary for each IP-RCT, depending on factors such as the location of operators.

To accommodate these scenarios without causing disruptions due to different alarm receivers, OnSphere supports a cluster configuration. This allows OnSphere to treat multiple IP-RCT devices as a unified entity, ensuring smooth handling of alarms without being impacted by variations in alarm receivers.

Use-case¶

Avoid logic when working with a cluster

Usage¶

Receiving alarms¶

Clusters of IP-RCT can be configured so alarms from any path of a cluster will be correctly forwarded to the corresponding values.

Sending order and setting administrative state¶

Sending SPT states and remote orders on a cluster will try each one until one succeed or all paths have failed.

RCT Connection monitoring¶

Concept¶

OnSphere acts as an AE plugin. Connection can be monitored to detect when the system is disconnected.

Use-case¶

Raise an alarm when the AE plugin is not working as expected

Usage¶

The value associated with owner-device.ip-rct reflects the connection status between OnSphere and IP-RCT.

SPT Connection monitoring¶

Concept¶

Warning

Monitoring of the SPT can only be done for DC-09 and TS-50136-9 protocols.

There are three different alarms linked to the monitoring of an SPT :

Alarm type	Description	Supported types
`PRIMARY_ATP`	The state of the primary ATP (the primary path is usually an internet physical link)	`BOOLEAN`
`ALTERNATIVE_ATP`	The state of the alternative ATP (the secondary path is usually a GSM link)	`BOOLEAN`
`ATS`	The global state of the ATS (the ATS is fine if at least one path is connected)	`BOOLEAN`

Use-case¶

Raise alarm when an SPT is not connected and thus cannot send alarms
Check the connectivity of every path (example : stats)

Handling alarms¶

Concept¶

Alarms received from IP-RCTs are acknowledged when they can be matched with at least one destination in the hierarchy. If there’s no suitable destination, the alarm remains unhandled. In cases where the alarm is directed to an alarm value with an associated linked action, acknowledgment depends on the successful execution of that linked action. If the linked action fails or exceeds a set expiration time, the alarm is considered unhandled.

Warning

IP-RCTs don’t store alarms. The validity of a criteria’s state depends on both the IP-RCT and the osp-module being online during the last occurrence of the alarm. In alarm transmission, the device creating the alarm (typically an IP-SPT) repeats it until an end device acknowledges. If another AE acknowledges the alarm in a multi-AE scenario, OnSphere will not be notified..

Use-case¶

Mobilize people when an alarm is raised

Usage¶

When an alarm is generated, a specific field can be made available as a simple value. The value type depends on the accessed field. The configuration is done by the owner-criteria.ip-rct schema definition.

When the CRTIERIA alarm data is used, criteria’s alarm and restore expressions are used to generate the value content. If the alarm matches the criteria’s alarm expression the value content is set to true, and if the alarm matches the criteria’s restore expression the value content is set to false.

See owner-device.ip-rct file for details

Accessible fieldsAdvanced¶

Warning

Depending on the SPT protocol used for alarm transmission, some fields may not be available (empty).

Alarm data	Supported types
CRITERIA	`BOOLEAN`, `INTEGER`, `DECIMAL`, `TEXT`
MAINTENANCE	`BOOLEAN`, `INTEGER`, `DECIMAL`, `TEXT`
STATE	`BOOLEAN`, `INTEGER`, `DECIMAL`, `TEXT`
SPT_NAME	`TEXT`
SPT_DESCRIPTION	`TEXT`
SPT_CUSTOMER_COMPANY	`TEXT`
SPT_CUSTOMER_CONTACT	`TEXT`
SPT_CUSTOMER_ADDRESS	`TEXT`
SPT_CUSTOMER_PIN	`TEXT`
SPT_CUSTOMER_PHONE	`TEXT`
SPT_CUSTOMER_EMAIL	`TEXT`
BUILDING	`TEXT`
LOCATION	`TEXT`
ROOM	`TEXT`
VERIFICATION	`TEXT`
INFO	`TEXT`
OCCURRENCE	`TEXT`
SITE	`TEXT`
LONGITUDE	`TEXT`
LATITUDE	`TEXT`
ALTITUDE	`TEXT`
ACCOUNT	`TEXT`
ACCOUNT_INFO	`TEXT`
TYPE	`TEXT`
TYPE_INFO	`TEXT`
ADDRESS	`TEXT`
DATE	`TEXT`
DATE_INFO	`TEXT`
TIME	`TEXT`
TIME_INFO	`TEXT`
USER	`TEXT`
USER_INFO	`TEXT`
AREA	`TEXT`
AREA_INFO	`TEXT`
PERIPHERAL	`TEXT`
PERIPHERAL_INFO	`TEXT`
AUTOMATED	`TEXT`
AUTOMATED_INFO	`TEXT`
PHONE	`TEXT`
PHONE_INFO	`TEXT`
LEVEL	`TEXT`
LEVEL_INFO	`TEXT`
VALUE	`TEXT`
VALUE_INFO	`TEXT`
PATH	`TEXT`
PATH_INFO	`TEXT`
GROUP	`TEXT`
GROUP_INFO	`TEXT`
SUBSUBSCRIBER_INFO	`TEXT`
SUBSUBSCRIBER	`TEXT`

Examples¶

Create one OSP alarms from a DC-09 device

Pre-receive hook for alarms¶

Concept¶

A linked action can be set up to react to alarms reception (in owner-alarm.ip-rct).

Unlike outputs, only one linked action can be set on an alarm value and it will have to be completely executed before acknowledging received alarm. The alarm will not be acknowledged if the action fails to execute or if it takes longer than the expiration time.

Use-case¶

ACK alarm when it must be treated on OnSphere.
NACK alarms when it must be treated elsewhere than OnSphere.

Usage¶

A linked action is simply a reference to an action (action.ospp) and the parameters to pass to the action (parameters and their type depend on the action type). The description of this link is done in the owner-alarm.ip-rct file.

Parameters can be :

A constant

{
    "value": "text"
}

A value field

{
  "field": "ID"
}

CONTENT of an alarm

When accessing the CONTENT field of an alarm value, a field can be extracted from the json representation :

Available fields are :

ID : The id of the value
TIMESTAMP : The timestamp of the value
CONTENT : The content of the value
TYPE : The type of the value
ERROR : The error of the value

{
  "field": "ID"
}

A list of parameters

{
    "values": [
        {
            "field": "ID"
        },
        {
            "field": "CONTENT",
            "fieldParser": "tni.ip"
        },
        {
            "value": "42"
        }
    ]
}

Examples¶

Create one OSP alarms from a DC-09 device Create an alarm from a DC 09 alarm

Change SPT administrative state¶

Extract from the IP-RCT manual version 1.2.2 :

../../_images/spt-administrative-state.png

Use-case¶

Disable SPT during a maintenance.

Usage¶

Changing the administrative state is done using a SET_SPT_STATE action in the output.ip-rct file

Configuration example :

deviceId: string : The id of the targeted device of the set state operation
sptState: string : The state to send to the targeted device (MAINTENANCE, ACTIVATE, DEACTIVATE)

Remote orders¶

Context¶

A remote order is a command sent to an external SPT device in an asynchronous way. Most of the time, the command is sent back to a polling from the end device, but this is protocol dependent. Be aware that not all SPT products support this feature so consult the user manual of the end device to ensure compatibilities.

Use-case¶

Activate actions on remote site * Open a door * Close a door * Start a video stream

Usage¶

Setting a remote order is done by using the SEND_REMOTE_ORDER action in the output.ip-rct file

Configuration example :

deviceId: string : The id of the targeted device of the remote order
remoteOrder: string : The remote order to send to the targeted device

Remote orders can be sent to a device using callbacks and outputs. The content of the remote order is defined from the triggering value of the callback, and only TEXT values are supported as IP-RCT callbacks trigger. The remote order content is dependent on the protocol used by the SPT