Integration - technical overview

Alarms from Reconeyez surveillance system can be monitored via a number of different monitoring softwares used by security professionals. Integration with third party monitoring stations is done on the server level, meaning that installed devices are sending alarms to chosen Reconeyez server and Reconeyez server is forwarding received alarms and status events to monitoring stations.

Supported integration types

• Email (human)
• Immix
• Sentinel
• Patriot
• SIA DC-09.2021 (incl. ADM-CID and SIA-DCS)
• Surgard Automation Output Protocol (incl. SIA Protocol 2)
• Accellence EBÜS
• Bold Group Manitou
• Json Webhook
• SureView
• MicroKey

Supported transmission protocols

For event and visual verification transmission Reconeyez utilizes SMTP, TCP/IP and FTP(ES) protocols.

• SMTP (used by email, Immix, Sentinel, Patriot, SureView)
  - with STARTTLS
• TCP/IP (used by SIA DC-09-2021, Surgard, Manitou, MicroKey)
  - with persistent connection (used by Surgard AOP)
  - with TLS (used by Surgard AOP)
  - with FTP (SIA DC-09-2021 with photo uploaded using FTP)
• FTP (EBÜS)
  - ftps (uses explicit FTP + TLS also known as FTPES)
• HTTP(s) (used by JSON)
  

Supported event types

System events

System event notifies the status of the Reconeyez integration component status.

Alarm events
Alarm events originate directly from the physical devices on the field.

• motion alarms
• tamper/theft alarms
• routine checks
• critical battery shutdown
• [Bridge IO] lid opened
• [Bridge IO] auxiliary power lost / found
• [Bridge IO] internal battery charging fault / normal
  
  

Supervision events
Supervision events are used as defined in the corresponding integration type protocol and implement the format defined in the corresponding protocol. Supervision messages are supported in SIA DC-09-2021, Surgard AOP and Bold Manitou protocols. 

Status events
Status events reflect the status of individual devices in the Reconeyez server.

• connection lost/restored
• battery low/restored
• device armed/disarmed
  

Filtering of events possible based on

• Autoalarms (person, car, truck, bike, motorcycle detected by AD algorithm
• Routine checks (hourly / daily by device type)
• Status events (by status event type: battery, arming, connection)
• Alarm type (routine check, tamper alarm, motion alarm, critical_battery_shutdown, auxiliary power found/lost, battery removed, internal battery charging fault/normal, lid opened, Snapshot)

Event and device metadata

Propagated device or event metadata depends on the specific integration type format capabilities. For more information about forwarded metadata refer to the relevant integration type technical documentation.

Currently following data is available for forwarding:

1. Device - Device GUID
2. Name - Detector/Bridge and short ID
3. Area - Site name/ location name
4. Description - Any description related to device, also used in integrated systems to tie to specific device group or site (ie: Immix:S12345, Sentinel:12345, Patriot:0011-01)
5. Event type (converted to integration type specific event types)
6. Detected actors - Person, Vehicle, Car, Truck, Bus, Motorcycle, Bicycle, Boat
7. Timestamp - Alarm time in device timezone
8. URL - link to Reconeyez Cloud, where users can see full size photos(s), object detections, start siren etc.
9. Device battery - battery level in %
10. Location - GPS coordinates
11. Signal strength - ASU (https://en.wikipedia.org/wiki/Mobile_phone_signal#ASU)
12. Attached/uploaded Photo or Video (1 PIR trigger x N pictures (by default 1 trigger 1 photo)). (Thumbnail quality ~10-20 kB).

Connection security

End-to-end encryption should be used for every connection. TLS should be used for TCP and STARTTLS for SMTP and FTP connections.

In case self-signed certificates are used in central station server Reconeyez will need the full certificate chain including the certificate authority (CA) certificate to be provided in order to whitelist it in our trusted certificate pool.

Connection redundancy

TCP/IP transmission fallback

IP fallback (aka primary and secondary server connection) allows configuring secondary IP to which the integration message dispatcher can switch if the primary IP connection fails. The logic is that on a new connection primary IP is always tried first, if connection fails to primary IP then secondary IP is tried. The connection will run in a circular loop until a connection to either IP is established. Actually the number of fallback IPs is not restricted to 2, there can be as many as required.

Currently the feature is only available for TCP/IP transmission types.

FTP redundancy

The integration components FTP client implementation allows configuring a list of IP addresses or hostnames with a port. Hostnames will be expanded to all the IP addresses they resolve to. The client's connection pool will pick from all the addresses in a round-robin fashion. Therefore, files for even one event can end up in different hosts.

When specifying multiple hosts, these should be identical mirrors of each other. This means that the hosts need to accept the same user credentials and when TLS is used for communication encryption the certificate used must allow for identification of all hosts configured. The hostname is checked against the subject and subject alternative names of the certificate. If instead an IP address is specified then to validate the certificate successfully the IP must be given in the certificate inside the subject alternative names section, but not as an DNS entry (e.g. hostname) but instead as IP.

Round-Robin DNS

Another option to achieve connection redundancy is to add multiple host records to DNS. Clients should then semi-randomly be resolved to one of the many addresses.

Visual verification

Reconeyez detectors capture photos for alarm visual verification. Photos are captured when either motion or tamper is detected by the relevant sensor. Detectors can be configured to make up to 10 photos per detection. By default they are set to take 1 photo as this is the most optimal configuration. The integration component can dispatch the photos as separate JPG files or compose a MJPEG (AVI) video clip of the sequence. Depending on the integration type the visual verification file(s) is attached, uploaded or transmitted before or along with the event message. 

Reverse control

Third party monitoring softwares that have been fully integrated with Reconeyez system also support reverse control. There is availability to use an HTTP REST API for this purpose. This includes fetching the list of devices, activating Reconeyez siren and arming/disarming devices. Additional functionality can be added. Reverse control HTTP requests must be sent to the same Reconeyez server that is configured to your bridges except for the uk.reconeyez.com server where it is required to send the requests to https://integrations.reconeyez.com.Currently reverse control has been implemented in the following capacity:

Immix
- trigger Reconeyez Siren audio

Sentinel
- trigger Reconeyez Siren audio
- arm/disarm Reconeyez devices

EBÜS
- trigger Reconeyez Siren audio
-arm/disarm Reconeyez devices