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.
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.
...
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 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.
...
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 cameas 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.
...
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.
...