Monitoring your camera in the yellow portal

Owned by Benedict Häfeli
Last updated: Feb 15, 2022
9 min read

Overall camera condition

The yellow portal provides you with tools to more easily keep track of your cameras and whether they are working as intended or not.

In the dashboard, each camera has a condition indicator that quickly lets you see if everything with your camera is as it should be:



This indicator shows the overall state of the camera. An attempt by the yellow cloud to reduce the available data to something that can give you a quick impression of how your camera is doing.

The indicator is also visible in the camera list, where you can sort and filter for different states in order to get a quick overview over your fleet:



Severity

The possible states this indicator can have are as follows:

  • No Data: The system has received no data from the camera for some time, or ever, and therefore cannot evaluate its condition.

  • OK: The system has some data, and none of it indicates any problems with the operation.

  • Warning: There are some errors during operation. Images may still be arriving as scheduled, but all is not well.

  • Error: The camera is experiencing severe issues that prevent it from sending images. It is still sending data, however.

  • Critical: The camera unexpectedly stopped sending any kind of data. This most commonly hints at issues with power supply or network connectivity. This condition is only set if there has been no lifesign of the camera for at least three capture intervals.

Active and passive tracking

There are two different methods by which a cameras condition is evaluated: By actively tracking a cameras schedule, or by passively reacting to events received from the camera.

Passive tracking will only let you know if there were errors, like an attempted upload that failed or when an image couldn't be processed according to its configuration. Passive tracking will not let you know when a camera is not sending anything at all anymore, since it does not attempt to interpret the cameras schedule to check if an image should have been sent and if it actually arrived.

Active tracking on the other hand will read a cameras schedule and attempt to determine whether images that were supposed to arrive did in fact arrive. It is capable of noticing when an image didn't arrive that should have arrived, and is therefore the more powerful option. It does however come with a few preconditions, see below.

How to enable active tracking for your cameras

There is no option you have to set to enable active tracking for a camera. Active tracking will kick in automatically as soon as all conditions are met that make it applicable. These conditions are:

  • A camera needs to be in "operating" status. Any camera that is not marked as operating will not be actively tracked.

  • A camera needs credentials (a username and a password) defined. If these are not defined, the camera cannot receive any images anyway. Consequently, such cameras are not actively tracked.

  • A camera needs a schedule defined in the yellow portal. For all yellow webcams,  this is always true, as these cameras receive their internal schedule from our servers. If you are using a 3rd party IP-cam, however, we have no way of knowing the schedule with which you have configured them. In this case you need to define the same schedule in the yellow portal to enable active tracking. Active tracking will of course also kick in if the schedules in the camera and the portal do not match, but in this case the evaluation of the cameras condition will be wildly inacurate.

Camera conditions in detail

The overall condition indicator is a great way to get a general oversight. But when something is wrong, you may want to know more details about what is wrong exactly and why.

Clicking on an overall condition indicator will take you to that specific cameras condition page, which offers you a much more detailed breakdown:

What you see here is the assessment of the camera condition in several separate domains, and the cameras event log.

The event log and events in particular are documented in detail here.

For now, we'll just focus on the condition domains, which are the four cards you see at the top of the window. These are areas of functionality related to the camera, but not all of them relate to the physical camera.

These are the four domains that are separately tracked for a yellow webcam.

  • Image Upload

  • Image Processing

  • Command Channel

  • Camera Controller

In the case of a 3rd party IP camera, only Image Upload and Image Processing are available, as those cameras won't send any data to our servers.

Each domain again can be either No Data, OK, Warning or Error. In the case of the later two, they will display a message to let you know how they ended up in that state. Let me now explain these domains in a bit more detail:

Image Upload

This domain tracks the upload of images, i.e. their path from camera to their intended destination. In the case of IP-cameras, we can of course only track uploads that actually reach our servers, while for yellow webcams, uploads to 3rd party servers are tracked as well. For actively tracked cameras the system will verify if there is a successful upload for a scheduled image, and it will show error if there isn't. It will also show an error if an upload reaches our servers but for some reason couldn't be accepted or processed.

So in general, if this domain shows the error condition, something with your cameras connectivity, network- or endpoint configuration might be faulty.

Image Processing

Image processing tracks your images as they are processed, edited and distributed to their respective tables by our cloud services. This dommain will generally show a warning if a specific table configuration couldn't be applied to an image, or an error if an image couldn't be processed at all. The first case usually points towards an invalid table configuration (attempting to crop an image outside of its borders is a favourite here), while the later might hint at multiple faulty table configurations, corrupted images, a wrong image format or similar.

Command Channel

The command channel is the connection through which your yellow webcam receives server instructions like the cameras configuration or its schedule, but also direct orders like capture-, focus- and heating commands. It is also used by the camera itself to send a regular heartbeat and events to our servers. As a result, if the command channel is error, your event log may not be up to date, and your camera will not be able to receive any portal commands or configuration changes. Unfortunately, this includes the reboot command. Errors in the command channel almost always come about due to the camera losing internet connectivity. There may however be situations in which the command channel shows error, but images are still being uploaded according to schedule. In that case, there may be a firewall issue preventing the camera from communicating over port 8883.

This domain is not available for 3rd party IP cameras, as they don't communicate with our services directly.

Camera Controller

The camera controller domain finally gives you information about what's going on on your yellow webcams controller. It sends data through the command channel, so if your command channel shows Error, the camera controller will show No Data by default.

This domain will show Warning if there are errors during minor operations, like setting a cameras configuration before taking an image. It will show error in case of major problems, like the camera failing to capture an image. Warnings can often be remedied by changing a cameras configuration, be that in the portal, or on the camera itself (A frequent source of warnings is for example if the camera is configured to control aperture by itself, so the controller won't be able to set the configured aperture). In the case of errors during image capture it is usually a good approach to wait for another image interval, or capture an image manually to see if the error recurs, and if it does, reboot the controller.

This domain is not available for 3rd party IP cameras, as they don't communicate with our services directly.



The event log

In the event log, you can look at what's going on in some real detail. Most things, from setting a configuration, over capturing and uploading an image to processing an image with a certain table configuration produces events, that will themselves have a severity level of OK, Warning or Error. At least for a yellow webcam, 3rd party IP cameras are limited to events generated by our servers, i.e. the upload and image processing domains.

The event log provides you with a chronological view of events recently received for your camera. The default display range is one hour, but you can extend this if you need information from further back, for example if you want to look at how a problem started that you just noticed.

The event log can also be sorted and filtered in a number of ways. First, you can of course filter it for certain severities, letting you quickly find for example all errors in the displayed period. Next it can be filtered for event types, if you for example wish to see only all events relating to image capture. Since each event type is subject to a specific domain, you can also do this by clicking on the severity indicator of a given domain. It will automatically adjust the event type filter to only display event types from this domain. Finally, you can filter for event chains, which might need a bit more explaining. You can read about them further down.



One thing to keep in mind about the event log is that it does not refresh by itself. It would get very confusing to try to look at it if new events were constantly added on top. To load in events that may have arrived after you opened the log, you can hit the refresh button in the upper right corner of the screen. This will not clear you filter settings.

What are events?

Events, as the name implies, are something that happened. In this case, something related to your camera that happened in any of the four domains. For actively tracked cameras, there can even be events outside those domains that signify that another event that was expected to happen didn't happen.

All events have a type, which describes the thing that happened. To read more about specific event types, how to interpret them and the data they carry, please refer to the dedicated events page.

Events that are of severity Warning or Error also carry a message explaining what went wrong.

All also events carry additional data, which you can see by expanding events by clicking on their severity indicator. This data represents configurations that were valid at the time an event happened. For example, if somebody changed a processing configuration for a table, and this now produces errors, you can go to the last processing event of that table that was OK, and it can show you the configuration as it was at that time, helping you to identify what change might have lead to the errors.

What are event chains?

Many events relate to an image. Be that the capturing of an image, the upload of an image, the processing of an image, or even to the fact that the image isn't there. That is, the events refer to a specific image. That also means that a successfully captured, uploaded and processed image leaves a trail of events describing its path. This association between events and a specific image is the event chain, which is identified by the id of the image that created the chain. Each event that forms part of a chain will display that id under the event type if expanded:

You can click on this event chain to set the filter to display only events in this chain, making it easier to trace the path of a certain image through the system. You can also enter an image id into the event chain filter field manually, but this is generally not recommended.

Can I track conditions and events and send alarms by email?

This feature is currently in closed beta and will be coming soon!

What's next?

If you wonder about what certain events mean or how they come about, take a look at our events page.

Combined with the information on this page, you should now have most of the tools to not only easily recognise that something went wrong, but also when, how and why.