...
Anchor | ||||
---|---|---|---|---|
|
domain | Camera Controller |
meaning | The camera attempted to capture an image. |
severities | OK: The capture succeeded and the image went on to be uploaded. Warning: The capture succeeded and the image went on to be uploaded, but not the entire configuration for the camera could be set. Error: The image could not be captured, usually due to some error involving the attached camera itself. |
data | The camera configuration the image was supposed to be captured with. |
applies for | Only Yellow Webcams |
Anchor | ||||
---|---|---|---|---|
|
domain | Camera Controller |
meaning | A catch-all event for various operations of the camera controller like startup and shutdown, focusing or starting the heater. |
severities | OK: The operation in question succeeded. Error: The operation in question failed. |
data | The exact operation the event refers to. |
applies for | Only Yellow Webcams |
Anchor | ||||
---|---|---|---|---|
|
domain | Image Upload |
meaning | A camera of any type uploaded an image to the yellow gateway, or a yellow webcam uploaded an image to a 3rd party server. |
severities | OK: The image was successfully uploaded. If it was uploaded to the yellow gateway, this means that it will shortly continue to image processing. In case of an upload to a 3rd party server, this event concludes the event chain. Note that a successful upload via FTP does not necessarily mean that the upload was complete. It is notoriously difficult to tell whether an ftp client has uploaded the whole file or only parts of it. Error: The image upload failed to commence or to complete. Yellow webcams may attempt a re-upload at a later time, typically at the next reboot. This will produce further UploadEvents in the same event chain. Uploads to 3rd party servers are not retried. |
data | The endpoint of the upload. |
applies for | All cameras |
Anchor | ||||
---|---|---|---|---|
|
domain | Image Processing |
meaning | The processing configuration of one table has been applied to the image, and the image was stored successfully. Consequently, there should always be one ImageProcessingEvent per table per image. |
severities | OK: The configuration could be applied without issues and the image was stored. Warning: The configuration could be applied and the image stored, but there were some irregularities. This is most often the case if you configured a redirect to a 3rd party server, and the upload to that server failed. Error: The image configuration could not be applied and the image was not stored. This does not mean that the image is entirely lost. Another attempt at processing the image will be made in a few minutes, to a maximum of 3 attempts that will generate further ImageProcessingEvents in the same event chain. If the reason for a failed image is a faulty configuration, however (cropping outside the image borders is a favorite), these subsequent attempts are doomed to fail unless you fix the processing configuration in question. |
data | The name of the table the image was processed for, as well as the complete processing configuration for that table at the time the image was processed. |
applies for | All cameras |
Anchor | ||||
---|---|---|---|---|
|
domain | Command Channel |
meaning | A Yellow Webcam sends a heartbeat every minute to keep the system apprised of its overall status. This event type signifies that this heartbeat has stopped during the last couple of minutes, or that it has returned after having stopped for some time. |
severities | OK: The heartbeat of the camera was missing, but has now returned. Error: The heartbeat has been absent for a couple of minutes. The camera will currently not be able to receive settings or commands, though it may still be sending images. If the situation endures, this event is regenerated every hour. |
data | The exact time the last heartbeat was received, in UTC. |
applies for | Only Yellow Webcams |
Anchor | ||||
---|---|---|---|---|
|
domain | General |
meaning | An image that should have been received according to the cameras schedule did not arrive. |
severities | Error: What it says on the tin. If there is any indication of the image in the event log (like failed uploads or capture), this event will be linked to the same chain. But if neither the image nor any related events are present, this event will not have an event chain. MissingImageEvents are generated for every image that should be there, but isn't. |
data | The schedule of the camera as it was at the time the event was generated, the exact time when the image should have been captured according to that schedule, as well as the time the last image by this camera was successfully submitted and processed. |
applies for | Any actively tracked cameras. |
Anchor | ||||
---|---|---|---|---|
|
domain | General |
meaning | A camera is "missing in action". In other words, the system knows it was working, but now seems completely absent. The cause for this is most frequently a severed network or power connection. |
severities | OK: The camera was missing, but has now resumed communication. Error: The camera stopped communicating for at least 3 full image intervals according to its schedule. For 3rd-party cameras, this simply means that there have been no uploads. For a yellow webcam, it means there have been no uploads, no heartbeats, and no events from the camera. A CameraMIA error is therefore usually preceded by 3 MissingImageEvents and no other events at all. If the situation endures, this event is regenerated every hour. |
data | The time the last lifesign of the camera was received. |
applies for | Any actively tracked cameras. |