Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 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: 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:

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

  • 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

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.

...