Actions and Conditions

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.

There are various types of conditions and actions to allow you to tailor an alarms behaviour to your needs. 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 below 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

ImageCaptureEvents are only produced by yellow cameras, i.e. cameras with a webcam controller. Third-party cameras do not produce them. Listening to ImageCaptureEvents of severity ERROR can be a good way to determine if your Yellow Camera has issues with image capture, which may hint at problems with the hardware or the connected camera, but it will not tell you whether a camera is offline or without power (as there are no ImageCaptureEvents produced in that case). Also note that the potential number of such events in a given period is very much dependent on the schedule of the camera.
ImageUploadEvents are produced for all cameras, but are not an ideal way of monitoring a cameras performance, since they will only inform you whether an upload succeeded or not. If no upload has even been attempted, no ImageUploadEvents will be produced.
ImageProcessingEvents are not just produced for every camera, they are produced for every table. As such, listening to these events may inform you about potential misconfigurations in a table, but not really about the state of the camera.
MissingImageEvents are produced for all actively monitored cameras, and are sensitive to the cameras schedule. Listening to these is generally the best way to determine whether a camera is delivering images or not, although they will not give you as much information on why they aren’t delivering as some other events might.
MissingHeartbeatEvents are only produced for yellow cameras with a webcam-controller peripheral. They can inform you when a camera goes offline, but keep in mind that these events are only produced once per hour. They are also produced according to different rules for cameras with a solar peripheral.
CameraMIAEvents are produced for all cameras with active monitoring, and are generally a good indication that a camera is offline. Keep in mind however that they are only produced once per hour.
PanoramaUploadComplete and PanoramaStitchingEvents are only produced for cameras with a panorama peripheral. Listening to PanoramaUploadCompleteEvents with severity ERROR can be a good way to keep an eye on how reliably your panocams are performing.

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: Monitoring your camera in the yellow portal | [inlineExtension]Camera 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, or Overall, which is formed of the summary of these four.

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:

The overall domain is a general summary of a cameras overall functionality. It will be Error if the camera is unable to receive images. It is the only domain that can have the “Critical” state, which means that a camera has dropped of the net completely.
Only cameras with the webcam-controller peripheral support the command and controller domains. Listening to these domains on an IP-camera sending by FTP will have absolutely no effect.

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.