Alarms: Core Concepts

Actively monitoring cameras and keeping on top of their conditions quickly gets tedious if you have a lot of them. This is where alarms come in. They allow automating triggering certain actions when certain conditions are met. Both the actions and the conditions are highly customizable to give you the flexibility required to produce actually helpful results, and not just a mess of automated noise that nobody wants to look at.

This page will explain the core concepts of how our alarms work. Without this knowledge, alarms may appear confusing. For help on how to use the interface to set up alarms for specific cameras, refer to the following articles:

configure new alarms for your partner account

configure alarms for a specific camera

Required user permissions

Alarms are a partner-level feature. This means that every partner is free to create their own set of alarms that is tailored to their specific needs and use cases. In order to manage alarms for a partner, you require admin or superuser level, and need to be authorised for all cameras of the partner (general camera permission). If you do not fulfill these requirements, this is probably the wrong page for you. If you are a power user, you may be interested in how to activate and configure alarms for a specific camera, if you are of lower level, any kind of alarm configuration is outside your domain.

The distinction between Alarms and Camera Alarms

There is one core concept you need to understand to work with alarms effectively. It takes a little getting used to, but is one of the main features that make alarms so versatile and powerful.

Think of an alarm in terms of regulation: If you’re operating a building, you may have certain regulations that dictate under which circumstances the fire alarm should sound. That’s important to have, but it’s not the regulation that will actually start ringing. No, the ringing is left to alarm bells mounted around the building.

In a similar vain, an Alarm configuration is a regulation, a behavioral template, that defines when an alarm should be ringing. However, it is a specific camera that will, so to speak, do the ringing. For this, the camera needs to know what regulations govern the ringing of its bells. In other words, an alarm needs to be added to a specific camera. Then that camera can start ringing alarm bells for that specific alarm.

We refer to this as a “Camera Alarm” as opposed to just an “Alarm”. They are created by adding a specific alarm to a specific camera.

The good thing about this is that it allows reusing alarm configurations for as many cameras as you’d like, and have only exactly those alarms active for any camera that you want. There are no pre-fabricated alarms active on your cameras that may or may not suit your needs and annoy you with notifications that you don’t want. Instead, partners are free to create their own custom libraries of alarms, and activate them for the cameras they need them for, and have different sets of alarms active on different sets of cameras.

Camera Alarm states

I’ve talked a lot about “alarm bells ringing” in that last paragraph. Truth is, we don’t have any bells. Rather, what happens when a camera alarm “goes off” is that its alarm state changes. Camera alarms can be in one of three states: OK, ALARM, or NO_DATA.

These should be fairly self-explanatory: OK means the alarm is not ringing for a certain camera, ALARM means it is ringing for a certain camera, and NO_DATA means that there is currently simply no way to determine whether the alarm should or should not be ringing for a certain camera.

Let me reiterate that an alarm in and of itself does not have a state. The combination of an alarm and a camera does. So, asking “is the missing image alarm in ALARM state?” doesn’t make sense. Questions that do make sense would be “is the missing image alarm in ALARM state for camera XYZ?”, or “What cameras are in ALARM state for the missing image alarm?”.

The anatomy of an Alarm

Now that we’ve talked a bit about the conceptual nature of an alarm, let’s look at how it is actually put together. There are four fundamental parts to the makeup of an alarm:

• A condition that is verified at regular, short intervals for each camera the alarm is added to, and that governs when the alarm state for that camera is OK and when it is ALARM.

• A set of actions, that should be executed for a camera when the state of that Camera Alarm is “ALARM”.

• A general configuration that mostly regulates the exact time at which actions should be executed, but also a few less consequential things like the alarms name and description.

• A pattern of camera peripherals that can be used to add the alarm to cameras with matching peripherals automatically.

In the following I will not be talking about the specific configuration options in detail. For that, please refer to this page: configure new alarms for your partner account

What is important here is to make sure you understand the concepts.

Alarm Condition

The alarm condition is what regulates the state of a camera alarm. The condition will be evaluated at regular, short intervals for each camera the alarm has been added to, and will determine the state for that specific camera alarm until the next evaluation.

If the condition is fulfilled on a camera, the camera alarm for that specific camera will enter (or stay in) ALARM state. If the condition is not fulfilled, it will enter (or stay in) OK state. If the evaluator finds that it does not have the necessary data to decide either way, the state will switch to NO_DATA.

Every alarm is governed by a single condition. Right now there are two different types of conditions, one that watches a cameras monitoring event and one that watches a cameras overall condition.

Going forward, we hope to add more types of conditions, enabling you to evaluate more aspects of a camera.

Alarm Actions

Alarm actions are the actual ringing of the alarm bells. Metaphorically of course, we don’t have any actual bells. In a base configuration, all actions of an alarm are executed for a specific camera as soon as the state of that camera alarm goes into ALARM.

Right now there are two generic type of actions available, notification via email or sms. More specialised alarm types may be available, but I won’t mention them all here. While an alarm can only have one condition, it can have multiple actions, up to one of each type.

One particularly useful aspect of actions is that their configuration can be extended for specific cameras, by users down to poweruser level. That is, lower tier users can add their own configuration to an action to suit their own needs, which will be executed in addition to the default configuration in the alarm. In other words, to take an email notification as an example, they can add their own email addresses to the list, and define their own subject and message text, but they cannot remove any recipients that are configured in the alarm itself, nor change the configuration of the message these recipients receive.

To learn more about the specific conditions, actions and their configuration, go here

General Configuration

The general configuration allows the adjustment of several parameters that are intrinsic to this alarm. This is a name and a description, which mostly serve that users can identify alarms quickly and determine what they are without having to look at the exact configuration. And then there’s a host of parameters that allow configuring when exactly the configured actions of the alarm should be executed, which takes a bit more explanation.

To understand what’s going on here you have to realise that the alarm state of a camera, and the actions being executed, are, while closely related, not the same thing. As mentioned before, alarms are evaluated at regular, short intervals for each camera they are activated for. The condition, as described, may change the state of that camera alarm at each evaluation. But whether or not you want the alarms actions to be executed each time this evaluation results in an ALARM state is a completely different matter.

Imagine you have an email notification action on an alarm, and you get that email several times an hour because you didn’t get around yet to fixing the cause. That would not be very helpful, as it would just lead to camera alarms getting turned off out of annoyance, and every once in a while you may forget to turn them back on, making them entirely useless.

A similar problem would exist if we would go the other extreme and just execute the actions once when the camera alarm state changes from OK to ALARM: You may get a notification, not get around to it immediately and forget about it. In that case there would not be any new notifications as long as the camera stays in alarm state.

In order to keep alarms as effective as possible while annoying you as little as possible, the various parameters in this section allow you some control about when and when not to execute an alarms actions, and how often. The exact function of these parameters are described here: Alarm Configuration

Default Camera Peripherals

The last part of an alarm configuration is a pattern of default camera peripherals, that can be used to automate alarm assignment. Creating a new alarm is not very productive if that alarm then has to be added manually to every camera. Nor is it very productive to activate the desired alarms on any new camera you create.

The alarm configuration therefore carries a pattern of camera peripherals, which you can adjust to dictate just what kind of camera this alarm is intended for. Once the pattern is set, it can be applied to all existing cameras, which means all cameras matching the pattern will add this alarm to themselves without further action being required. It also means that newly created cameras that match the pattern can add the alarm to themselves right away.

Peripherals were chosen for this because they are the best indication of a cameras capabilities and its expected behavior. For example, an alarm that works well on an ordinary camera might not produce satisfactory results for a panorama camera, or an alarm that works great on a camera plugged directly into the power grid might be overreacting on a camera that is being fed by solar cells. There are also certain condition configurations that only make sense for the one or other type of peripheral.

For reading up on how to exactly configure the pattern, please go here: Alarm Configuration

Camera Alarm Configuration

There has been much talk about the distinction between an alarm and a camera alarm, but not much about how that works exactly and what possibilities it opens. For a less conceptual explanation of the interface, please see here.

The basics should be fairly clear by now: When you add a specific alarm to a specific camera, a camera alarm is created that is actually evaluated, has an alarm state and can execute actions. There are two ways to add an alarm to a camera: Either through applying an alarms default camera peripherals (see above), or by manually adding the alarm to a camera on the camera configuration page ( not the alarm configuration page!).

The really neat thing about the camera alarm is that it also allows additional configuration that is quite independent from the alarm config.

One very useful thing is that a camera alarm can be disabled for a certain camera without removing it from the camera entirely. This is important in combination with the major feature of a Camera Alarm configuration, which is extending the alarms action configuration for this specific camera.

Let’s make an example to give you an idea of how useful this can be: Let’s say you have an alarm with an email notification action. In your alarm config, you have configured some email addresses for yourself and a couple of your technicians that should receive a notification when the alarm goes of.

But now along comes a customer, and they want to receive an email too when their camera is having trouble. So, you add them to the email list in your alarm config… and now they get an email for every camera this alarm goes off for! That’s obviously unacceptable. So what’s the alternative? Create a new alarm with that customer in the email list, that is only used on cameras for this specific customer? That would work, but be very far from a satisfactory solution.

No, what you can do in this case, is extend the action configuration in the Camera Alarm Configuration and add your customers email there, and any emails of people they might want to receive the notification too. And you can enter a custom message for the emails that list receives, for example in a different language, and configure some other things, and all of this will not touch the base configuration of your alarm, and the configuration will only be used for this specific camera. The email addresses registered in the alarm configuration will all still receive the mail as configured in the alarm config, even for this specific camera.

In fact, if your customer happens to have power user access, they can configure all of this by themselves. Users down to power user level have permission to extend alarm action configurations for any cameras they are authorised for. They cannot change the actual alarm configuration, nor disable or remove camera alarms, nor add new ones. But they can configure what they’d like to receive for this specific camera.