Each alarm has one condition that governs when the alarm state for a given camera is OK and when it is ALARM. Each alarm also can have a series of actions that will be executed when a given cameras state changes to ALARM and the other execution conditions in the general parameters are satisfied.

Right now, there is only one type of condition and one type of action. More are planned in the future, to monitor more aspects of a camera and to provide the option for more automated reactions. For now, the one available condition already enables the detection of a wide range of potential misbehaviours, and the provided action will allow you to more easily stay on top of things.

The following is a list of available conditions and actions, and an explanation of their function and configuration.

Conditions

On Event Alarm Condition

The OnEventAlarmCondition allows you to listen to camera events, and raise an alarm if more than a certain amount of a certain event occur within a certain time.

Event Type: The type of camera event the alarm should listen to. Note that some events won’t make sense for certain types of cameras, since some events are specifically produced by certain peripherals. There is no verification whether the event you selected matches your default peripherals configuration. There’s a bit of help with that further down if you feel unsure.

Severity: What exact severity of the specified event type the alarm should listen to. Usually this will be ERROR. In fact, some events, like the MissingImageEvent or MissingHeartbeatEvent, only occur with severity ERROR.

Events in Period: The alarm is raised if a camera produces this many or more events of the selected type and the selected severity within a certain period of time.

Period length: The length of the measuring period in seconds. If a camera produces as many or more of the configured events as is set in “Events in Period” within this many seconds, the alarm will be raised. Note that the period does not refer to a fixed time window. At each evaluation (usually every minute), the condition will evaluate all camera events that occurred during the last <Period Length> seconds.

Typical events and how to use them

On Camera State Alarm Condition

The OnCameraStateAlarmCondition allows you to listen to the state of one of your cameras monitoring domains directly. In case you’re wondering what those are, take a look here: https://avisec.atlassian.net/wiki/spaces/YDEN/pages/693207064/Monitoring+your+camera+in+the+yellow+portal#%5BinlineExtension%5DCamera-conditions-in-detail

Whenever the condition the configured domain of a camera using the alarm switches to one of the configured states, the alarm will be raised for this camera. Obviously, the basic alarm configurations like action execution interval and trigger delay still apply.

There’s only two parameters to adjust here:

Monitoring domain: The domain the alarm should listen to. Those are either Upload, Processing, Command or Controller.

Raise alarm on states: The states the chosen domain has to be in for the alarm to be raised. Note that the Critical state is available only for the Overall domain.

The alarm will be raised if the condition of the configured domain is in any of the configured states.

A few helpful further tips:

Actions

Actions determine what happens when an alarm is raised for a camera. Certain actions have the added benefit of allowing extending their configuration on a per-camera basis, without altering the base configuration of the alarm. This means that these actions can also be extended by power users, so that some of your end customers can influence additional behavior. This is especially important for notifications, where customers can add additional email addresses to receive alarm notifications for their cameras themselves, and define custom messages specifically tailored to the camera and alarm.

Notify By email

This action sends an email to a configurable list of recipients when an alarm is raised. It is also possible to configure the content of the mail.

Email subject: The subject of the email being sent. Note that for the base alarm configuration, this is best left blank. When blank, a subject containing the ID of the camera that raised the alarm will be generated. Since the base configuration is not on a per-camera basis, entering a custom subject means that the camera that raised the alarm is not identifiable in the subject.

Email title: The header printed into the emails body.

Email message: The main message contained in the emails body. This can only be configured in camera specific extensions, where you may want to customise the message for a certain camera. If not overriden, a default message will be generated based on the condition of the alarm, and containing the ID of the camera. Changing the message in a camera specific extension, however, can offer the opportunity to write less technical messages for your customers, or using a different language.

Notification Recipients: A list of email addresses that are to receive the notification. Note that all email addresses configured in the base alarm configuration will receive the email as configured in that configuration. Extending the action for a camera does not influence the content received by the email addresses configured in the alarm itself. Even if somebody were to add an email address in an extension that is already contained in the alarm configuration, that email address will only receive the notification as defined by the alarm configuration. This is to ensure that no lower level user can indirectly tamper with things they have no permission for.

Notify by SMS

This action sends an SMS notification to a configurable list of mobile phone numbers when the alarm is raised.

SMS title: The first, distinct line of the text message (required)

SMS Message: Define The text to be contained in the message after the title for a specific camera. This is only available when extending an alarm configuration. Otherwise a default message will be generated from the alarms properties.

Notification Recipients: A list of phone numbers that are to receive the message. Note that all numbers configured in the base configuration will receive the message as configured there. Only phone numbers listed in specific extensions will receive the message as configured by that extension.

Reboot router by SMS

This action sends up to two SMS to a mobile router with a short delay in between. A properly configured router that supports triggering hooks through SMS messages can be hard-rebooted this way, and the connected camera controller right along with it.

This action is a bit special as it only has an effect if it gets extended in a specific camera alarm configuration. This is due to the fact that the camera of each router will have its individual phone number, and setting any kind of useful default for that is impossible.

Router number: The phone number of the routers sim card. It must contain a country code, and may contain only numbers apart from the initial +. This field is only available when extending the config for a specific camera, but there is required.

Commands: Up to two messages will be sent with a small delay to each other. Here you can specify the text body of those two messages, which, for these purposes, will usually be a short keyword, mostly depending how you or your supplier configures their routers and the routers being used. In general, these should be configured in the base configuration and left untouched in any extensions, but you may have the odd package that requires a different command or set of commands.