Sentinel
Last updated
Last updated
In order to setup the Sentinel integration, you must select 'Sentinel' as the ARC integration type.
The 'ARC Identity' field should be set the SiteID you have configured in Sentinel.
The SMTP details should be matched to your Sentinel server ones. Please note the emails are sent by connecting to your server rather than via our mail servers.
It is important to setup the 'Camera ARC identity' on the 'Advanced' tab of the camera settings page.
The Camera ARC identity is what will be sent through to Sentinel as the CameraNo in the event emails. If the Camera ARC identity is left blank, we will send the unique Giraffe camera ID instead.
If you have multiple Edge Controllers on a single site, there are two ways that you can configure the integration:
by setting up each Edge Controller as an individual transmitter in Sentinel
by setting up a single transmitter in Sentinel for the entire site, and configuring multiple Edge Controllers with identical settings.
In the second option above, it is important to give each camera a unique Camera ARC identity in order to differentiate the cameras in Sentinel.
If multiple Edge Controllers are configured using the same Transmitter ID in Sentinel, you can differentiate between tamper and system alarms from the Edge Controllers using the Edge Controller ID sent along with the event (TODO: is this actually sent? Should we send a G-number?)
You can easily test any individual event type by copying from the examples below and pasting them into the test email feature on the ARC configuration screen.
For instance, if you want to test a mains failure alarm, you would need to send the following text:
Giraffe will send Sentinel emails in the following formats. We have tried to map our events to the Sentinel events as much as possible, but sometimes we have had to use some artistic license.
In all of the following templates, the following variables will be replaced
{{ site_id }} => the SiteID configured in the ARC configuration
{{ camera_id }} => the ARC identity configured on the camera record, or the Giraffe camera ID if the ARC identity is blank.
{{ camera_name }} => the cameras friendly name in the Giraffe platform.
`
Where the event was generated by an object detection (person or vehicle), we will send the following event to Sentinel. We will also attach snapshot images if available.
If the object detected is a vehicle, the Event parameter will be set to VehicleDetected
Up to five snapshot images will be attached to the email sent to Sentinel. These images will be named with the timestamp they were each taken like in the following photo:
The Giraffe platform will wait for 30s after an initial event is received for the snapshots to be received. As soon as 5 snapshots are received, the Giraffe platform will immediately forward the event to Sentinel.
If the 5 snapshots have not been received within 30s, the Giraffe platform will forward the event to Sentinel anyway with whatever snapshots it has received. The Giraffe platform will not attempt to resend the snapshots if they are subsequently received later.
Where the event originated from a source that did not provide a snapshot (such as a PIR sensor) we will send the following:
{{ pir_id }} will be replaced with the ID of the PIR sensor that triggered. This will typically be an integer between 0 and 3.
Where it is a wireless PIR sensor that has triggered, the event will be as follows:
The wireless PIR sensor ID will be between 0 and 63.
When an intrusion event other than those mentioned above is generated, it will be sent to Sentinel in the following format using Sentinel's 'GeneralAlarm' event.
{{ module }} => the module that triggered the event, eg. 'doors'
{{ action }} => the action that triggered the event, eg. 'opened'
{{ metadata }} => any additional information that was passed along with the event, eg. '{ "door_id": 4 }'
When the mains power is disconnected, we will send the following event to Sentinel
When the power is connected again, we will send an event like this. Unfortunately Sentinel does not have an event to indicate restoration of power loss.
Similar to mains power, when auxilliary power is disconnected, we will send the following event. Sentinel does not have a specific event for auxiliary power.
And the restore message is similar:
Sentinel does not have a specific event for door opened / closed, so we use the generic 'Trouble' event.
When the doors are closed again, we send the following 'TroubleRestore' event:
When the tilt sensor is triggered, we send the following event (again using the generic 'Trouble' event:
And the following when the tilt sensor position returns to normal:
The generic tamper sensor is almost identical to the tilt event:
As is the restore:
For any other tamper events that do not match the above, we send the following generic message:
We use the generic Sentinel 'Tamper' event.
{{ module }} => the module that triggered the event, eg. 'doors'
{{ action }} => the action that triggered the event, eg. 'opened'
{{ metadata }} => any additional information that was passed along with the event, eg. '{ "door_id": 4 }'
If there is a fault with the hard disk used by the recording system, we send the following event using the 'RecordingFailed' event
{{ reason }} => can be either disk_missing or fsck_failed
Unfortunately Sentinel does not have a recording restored event, so we have to send the RecordingFailed event again when recording is restored:
When the system battery falls below a certain number of minutes remaining, the following event is sent:
{{ time_remaining }} => the remaining time in minutes
{{ battery_voltage }} => the battery voltage at the time of the alert
{{ percent_remaining }} => a percentage indication of how much battery is left vs the overall capacity of the battery.
When the battery time remaining rises back above the threshold, the following event is sent (again using the 'BatteryFail' event because Sentinel does not have a battery restore event):
The threshold for the battery time to go alarm is configured in your device definition. Please contact Giraffe support if you wish to change it.
If the Giraffe platform notices the Edge Controller has gone offline, the following event will be generated using the 'DeviceCommunicationLost' event.
When the system comes online again, we use the 'DeviceCommunicationRestore' event to signal it as online again
Online / offline notifications may be delayed by a couple of minutes. This is to avoid 'nuisance' alerts that may be caused by temporary blips in internet connectivity.
For any other system events that do not match the above, we send the following generic message using the Sentinel 'GeneralAlert' event:
{{ module }} => the module that triggered the event, eg. 'doors'
{{ action }} => the action that triggered the event, eg. 'opened'
{{ metadata }} => any additional information that was passed along with the event, eg. '{ "door_id": 4 }'
